odin-lang
core/net split_url incorrectly parses URLs with URLs in query parameters
When parsing an URL like https://example.com/callback?redirect=https://other.com/loginusing core/net#split_url it returns '/login' as the path of the URL when it should be returning /callback. It seems in core/net/url.odin, the split_url method does a last_index to figure out the scheme but that returns the incorrect position in this case. I assume last_index was chosen for a reason but I'm not sure why. I think it either needs to just use normal index or it needs to split off the query parameters before looking for the scheme using last_index.
I realize even using index instead of last_index will not work as /callback?redirect=https://other.com/login will still be parsed incorrectly. A scheme can not contain a '?' so maybe the later check for '?' can be brought forward and only allow the scheme if the '?' is after the '://'. The correct thing to do would be to verify the scheme against the spec though.
I see, that's a bit lazy, indeed. Thanks for the report. I'll do a from scratch implementation soon that's RFC-compliant. The errata to that I'm aware of all deal with specific schemes like mailto, file, telnet, et al.
Turns out that all that was needed was to change last_index to index, no need to do a full rewrite.
As far as ftp://user:pass@host:port/, this can be handled as follow-up processing on host to extract user, pass and port if applicable.
split_url allows you to not have a scheme (it doesn't consider it an error) so an URL like example.com/page is still parsed, but if something looks like a scheme in a query parameter then that URL will be parsed incorrectly, ex: example.com/callback?redirect=https://other.com/login. The : and / are reserved characters but are not required to be percent encoded when in a query parameter as those characters do not have a reserved purpose in that position. So I think either that case needs to be handled or the method must always require the URL to have a scheme.
http://github.com/laytan/odin-http currently uses split_url to parse paths like /index.html?param=1, thus odin-http relies on the fact that the method doesn't require a scheme or even a host. So there might have to be a separate procedure to parse paths with query parameters if split_url enforces the scheme. That might be a good idea anyway for performance reasons if you know the that the given "URL" never has a scheme or host.