Mauro Tortonesi <[EMAIL PROTECTED]> writes:
> here is my rfc2732 patch for wget. here is a brief summary of the
> changes i've made:
[...]
Thanks for the patch. I'm about to apply this, with several (minor)
changes:
* I modified the functions to not require a zero-terminated string,
but to accept an END argument instead. That game url_parse doesn't
need to play games with terminating the string and then restoring
the old char.
* I changed boolean to int in accordance with (most of) the rest of
Wget.
* I removed the `assert' you added in case of overflow. I don't have
anything against asserts, but they should be used to test internal
logic of the code, not to verify user input! I hate programs that
coredump on me for giving them input they don't like.
If you want to check for overflow, do so, but then have the function
return an error.
Also, there's an issue I'm not sure how to handle. If Wget is not
compiled with IPv6 support, it accepts the IPv6 addresses, but then
barfs. For example:
$ ./wget 'http://[this-address-sucks]/'
http://[this-address-sucks]/: Invalid IPv6 numeric address.
So far so good. But:
$ ./wget 'http://[3ffe:501:9999:ffff::123.4.5.6]/'
--22:20:04-- http://[3ffe:501:9999:ffff::123.4.5.6]/
=> `index.html'
Resolving 3ffe:501:9999:ffff::123.4.5.6... failed: Host not found.
And even:
$ ./wget 'http://[::127.0.0.1]/'
--22:16:26-- http://[::127.0.0.1]/
=> `index.html'
Resolving ::127.0.0.1... failed: Host not found.
I'm starting to think that Wget should reject all "[...]" addresses
when IPv6 is not compiled in because they, being valid IPv6 addresses,
have no chance of ever working. What do you think?
