patch: fix numeric ipv6 address handling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all :) there were two problems preventing the use of numeric ipv6 literals: 1. splitting the authority in hostname and port the attached patch fixes the handling of numeric ipv6 addresses entered into the url bar. a_Url_hostname got the colons delimiting the 8 groups of hexadecimal digits of an ipv6 address confused with a port number. 2. joining hostname and port for the Host: header a_Http_make_query_str used to build the Host: header by concatenating the url->hostname with the port number in case it's not the default port. Unfortunately this breaks with numeric ipv6 addresses since an ipv6 literal has to be enclosed with square brackets when used in urls and Host: header fields (according to my experiments and my interpretation of rfc 2616 section 14.23 ("Host header") and 3.2.2 ("http URL")). I would therefore suggest to use the original authority string obtained from the url. Patch is attached. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI6AEJoPmwNWhsaZYRAkg1AKCMHotNlq93MMe2A4d/mcki3w8ScwCgqUWY 94TggAK4U7NNwLrXC+RPsq8= =Ajfy -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Justus Winter wrote:
Hey all :)
there were two problems preventing the use of numeric ipv6 literals:
1. splitting the authority in hostname and port [...] 2. joining hostname and port for the Host: header Any comments? Any chances of getting those two in for the release? I do consider ipv6 support somewhat important these days... ;)
Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI896CoPmwNWhsaZYRAj/cAKCSkIWOj2HpIMnaJPfLGEczSe+SpQCeNINO 1pqXTIFLO41SZi/4XLBCWsA= =BbKT -----END PGP SIGNATURE-----
On Tue, Oct 14, 2008 at 01:49:22AM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Justus Winter wrote:
Hey all :)
there were two problems preventing the use of numeric ipv6 literals:
1. splitting the authority in hostname and port [...] 2. joining hostname and port for the Host: header Any comments? Any chances of getting those two in for the release? I do consider ipv6 support somewhat important these days... ;)
It will go after the release. Changing the query string in this moment gives me shudders! :-o -- Cheers Jorge.-
On Sun, Oct 05, 2008 at 01:49:29AM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all :)
there were two problems preventing the use of numeric ipv6 literals:
1. splitting the authority in hostname and port
the attached patch fixes the handling of numeric ipv6 addresses entered into the url bar. a_Url_hostname got the colons delimiting the 8 groups of hexadecimal digits of an ipv6 address confused with a port number.
Committed to CVS (not in the already made release).
2. joining hostname and port for the Host: header
a_Http_make_query_str used to build the Host: header by concatenating the url->hostname with the port number in case it's not the default port. Unfortunately this breaks with numeric ipv6 addresses since an ipv6 literal has to be enclosed with square brackets when used in urls and Host: header fields (according to my experiments and my interpretation of rfc 2616 section 14.23 ("Host header") and 3.2.2 ("http URL")).
I would therefore suggest to use the original authority string obtained from the url. Patch is attached.
AFAIR, the "remove default port" part was added because some sites answer 404 when receiving it. I'd prefer a patch that handles IPv6 like you suggest, and IPv4 as now. -- Cheers Jorge.-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote:
2. joining hostname and port for the Host: header
a_Http_make_query_str used to build the Host: header by concatenating the url->hostname with the port number in case it's not the default port. Unfortunately this breaks with numeric ipv6 addresses since an ipv6 literal has to be enclosed with square brackets when used in urls and Host: header fields (according to my experiments and my interpretation of rfc 2616 section 14.23 ("Host header") and 3.2.2 ("http URL")).
I would therefore suggest to use the original authority string obtained from the url. Patch is attached.
AFAIR, the "remove default port" part was added because some sites answer 404 when receiving it. Yes, that's what your comment says. But my proposal does not break those cases in general.
The current behavior is to construct the authority string for the host header using the parsed hostname and the port number in case it differs from 80. I proposed to use the authority part from the url the user entered. This may break some sites _if_ the user explicitly entered ":80" in the url. Btw, I just checked firefox and it seems to do it this way. Entering "http://localhost:80" in firefox url bar yields the following request: root@thinkbox:/var/tmp# nc -l -p 80 GET / HTTP/1.1 Host: localhost:80 [...]
I'd prefer a patch that handles IPv6 like you suggest, and IPv4 as now. While this is certainly doable, I can't see anything gained by assembling the authority string besides stripping the default port in case the user explicitly entered it.
Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj0r1oACgkQoPmwNWhsaZYwrACdGJanS3yoXudr/Dir/3q9jR2U w2wAoJJiFj6E5zGmO+ILNTcLzhxIfyJR =uX/b -----END PGP SIGNATURE-----
On Tue, Oct 14, 2008 at 04:40:27PM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jorge Arellano Cid wrote:
2. joining hostname and port for the Host: header
a_Http_make_query_str used to build the Host: header by concatenating the url->hostname with the port number in case it's not the default port. Unfortunately this breaks with numeric ipv6 addresses since an ipv6 literal has to be enclosed with square brackets when used in urls and Host: header fields (according to my experiments and my interpretation of rfc 2616 section 14.23 ("Host header") and 3.2.2 ("http URL")).
I would therefore suggest to use the original authority string obtained from the url. Patch is attached.
AFAIR, the "remove default port" part was added because some sites answer 404 when receiving it. Yes, that's what your comment says. But my proposal does not break those cases in general.
The current behavior is to construct the authority string for the host header using the parsed hostname and the port number in case it differs from 80.
I proposed to use the authority part from the url the user entered. This may break some sites _if_ the user explicitly entered ":80" in the url.
That's the point.
Btw, I just checked firefox and it seems to do it this way.
Entering "http://localhost:80" in firefox url bar yields the following request:
root@thinkbox:/var/tmp# nc -l -p 80 GET / HTTP/1.1 Host: localhost:80 [...]
Good. If FF does it currently, then it should be less of a problem. I'll commit as it is and let's see what happens. -- Cheers Jorge.-
participants (2)
-
4winter＠informatik.uni-hamburg.de -
jcid＠dillo.org