Closed Bug 501584 Opened 11 years ago Closed 4 years ago
Firefox sends along ipv6 encapsulated addresses when connecting to v4 hosts specified in V6 format
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:126.96.36.199) Gecko/2009060215 Firefox/3.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:188.8.131.52) Gecko/2009060215 Firefox/3.0.11 When connecting using ipv6 format to an ip4-based host specified as http://[::ffff:xxxx:xxxx]/, firefox sends along that string (brackets inclusive) as a host header. While this should in theory be a straight IP connection, because no DNS was used it should result in a blank host: header being sent, the effect is that non-ipv6 aware apache servers will see this as a malformed header. Per RFC 2616: "If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value." Note carefully, that the connection occurs over v4, not v6, in this case, the server should not need any v6 awareness. On a related note, Mozilla also sends a host header with the IP address in standard v4 connections, which is also against the spec, but doesn't cause this particular breakage. Reproducible: Always Steps to Reproduce: 1. Attempt to visit a namevirtualhost by ip, running any 1.3 version of apache. (For example, http://[::ffff:4809:6582]/). Actual Results: Apache gives me a malformed host header answer (error 400), probably due to interpretation of the colons in the IP address as a port specification. Expected Results: Mozilla should have sent an empty header. The blog link above sums it up pretty conclusively. Note that apache could handle this better/worse (i.e. more strictly, more permissively) too, as technically speaking, host: 184.108.40.206 is in violation of the standards as well. Apache could also just ignore the malformed host header and serve the page as if none was specified. Of course, this isn't the venue for those ssuggestions.
Firefox 3.5 has a fix for this.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 464162
Is this really duplicate of bug 464162 ? Patch of bug 464162 only deletes SCOPE ID from host header.
Please check with Firefox 3.5 @ http://www.mozilla.com if I was incorrect I'll reopen.
this is not the same bug.
Status: RESOLVED → UNCONFIRMED
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Resolution: DUPLICATE → ---
'host' production also includes ipv4 address per RFC 2396. http://tools.ietf.org/html/rfc2396#section-3.2.2 IPv6 address literals were added by RFC 2732, So It's reasonable to assume that some v4 only hosts may fail to parse IPv6 address literals in the Host header field, IMO.
RFC2396 and 2732 specifically relates to uris, not host headers. As I'm rereading all of RFC2616 section 14.23, they say several things: 14.23 Host The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. I read "naming authority" above as DNS (or NIS, WINS, /etc/hosts, etc). In my mind this also means, 'if you didn't do a lookup, i.e. with gethostbyname, etc...there shouldn't be anything in the host header' Further (as in the original report): If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. I can think of no other case of an HTTP URI which will not include an internet host name, other than IP addresses. It seems as this section was written to address specifically the case of literals. Out of scope question: would you suggest filing this as an apache 1.3 bug as well? While it's ipv6 related, it involves no v6 code.
the host header needs to contain whatever host information we have from the origin so that the server can reconstruct the origin and demux as necessary.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago → 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.