Mauro Tortonesi <[EMAIL PROTECTED]> writes: >> > what about the patch for src/url.c? >> >> It looks fine, but I'm not sure I understand why it's necessary to >> install full IP address understanding at the URL parsing level. > > please, take a look at RFC 2732. it is just 6 pages long and it is > an IETF standard that defines the right way in which URLs should be > parsed.
OK. >> Can you show me an example of a URL that failed to parse? > > the problem was not with false negatives, but with false positives > instead. URLs like: > > http://[2001.23]/ > ftp://[dead:beef:dead:beef:dead:beef:dead:beef:dead:beef:dead:beef:dead:beef:..2] > were considered valid IPv6 addresses. this is clearly wrong and not > RFC 2732 compliant. Ah, now I see what you mean. I don't quite agree with the idea of URL parsing code containing knowledge of IPv6 (or any other!) addresses, but since rfc2732 accepted it, I guess I'll go with it. Please mail the patch to wget-patches; I'll apply it. If you have patches for Wget's configure.in to work with Autoconf 2.5x, I'll gladly accept those, too. > moreover, the code was not efficient, as the loop was not stopped > when an invalid char was encontered. You have got to be joking -- AFAIR the loop was simply looking for ']', which is much more efficient than full parsing of the address which you implement! Either way, the URLs with "[...]" addresses are still extremely rare, so performance is not affected either way.
