New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix parsing of IPv6 Addresses in vibe.inet.url #2308
Conversation
The But besides the question whether any kind of relative URL should be supported by |
While I agree that the
The actual issue with that is that when provided with such a URL the parser gets the parameters wrong without failing, e.g. in case of
see: https://run.dlang.io/is/pCfsqr It is true that this behavior could be detected by checking a posteriori wether e.g. Therefore a sound approach could be to introduce a check which forbids the invalid The first approach seems safer while the second one is probably simpler to introduce since it allows for a corner case whithout requiring additional checks such as string traversing, looking for |
The problem is that "localhost:8080" may actually be a valid URL, depending on how the "localhost" schema is defined. There are a number of schemas that don't have the "//" to denote the start of the hiearchical part of the URL. As for actual IPv4 addresses, it would make sense to disallow "127.0.0.1:8080", as the schema must start with an alphabetical character. But in any case, only "//[::1]:8080/" can be a valid URL - "[::1]:8080/" is just invalid AFAICS. |
I've added a check which doesn't allow schemas starting with non-alphabetic characters. This should also detect |
Makes sense, I'll merge that for now. Would be nice to have something like #2311 on top to support parsing relative (and maybe also fuzzy) URLs. |
The current implementation of
URL.parse
fails when provided with an IPv6 Address. Using the latest master branch:The program gives the following result:
The code responsible for this is in
url.d
when the parser looks for the index of the first:
occurrence. The presence of:
inside IPv6 addresses is not taken into account, causing a failure when trying to convert the expected port toushort
.The proposed fix consider both cases by setting the index accordingly.
Edit: this can also be seen here: https://run.dlang.io/is/SxRV9e