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.


(Core :: Networking: HTTP, defect)

Windows 2000
Not set





(Reporter: mozillabugs, Unassigned)




User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/2009060215 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: 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: 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.
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 @ if I was incorrect I'll reopen.
this is not the same bug.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Resolution: DUPLICATE → ---
'host' production also includes ipv4 address per RFC 2396.
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.
Closed: 11 years ago4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.