Bug 35122

Ive seen this code before, but I didn't understood why we can't accept the scope_id.

Anyone?

According to the svn log this code was added by Jeff Trawick 4 years ago, so he
would be the only one to know for sure. 

After looking at more of the code my best guess is that scope ids are not
allowed in the Host: header because they are not allowed in the vhost
configuration (in get_addresses(): if (scope_id) { return "Scope ids are not
supported"; }). And they are probably not allowed in the vhost configuration
because the semantics are not obvious and/or nobody wanted to implement them.

However, that's IMHO no good reason to reject a scope id in the Host: header
with a 400 Bad Request message indicating a client error (if anything it's a
server error, so 501 Not Implemented would be more appropriate). Simply ignoring
the scope id should be acceptable as an easy fix, although not completely
correct. The correct solution (I think) would be to allow scoped addresses in
the vhost configuration and store the scope together with the IP address. Then
get the scope from the sockets of incoming requests and compare that to the
stored scope, as if it was part of the IP address (which it is, kind of).

I assumed that scope id in the IPv6 literal address notation is interesting only
to the machine where it was used, and was used to select an interface to use on
the outbound, or identify an interface on the outbound.  It is not part of the
IPv6 header after all.  So a client may indeed specify a scope id on a connect()
but it doesn't make since in a Host since the client's view of the scope isn't
interesting on the server (the server may indeed get a different scope in
sin6_scope_id when the client address is reported from accept() or getpeername()).

Based on this discussion I'm willing to assume that this understanding was
naive/incomplete/completely-ignorant/etc.  Do you have a pointer to a good
description?

I'm sorry, it looks like you are right. I browsed through the RFCs: 2616
references 2396 when it comes to the Host: header which doesn't allow literal
IPv6 addresses at all, so it's probably not relevant. Then there is 4007 (pretty
new) which more or less forbids scope ids in the Host: header:

|                Hence, the format MUST be used only within a
| node and MUST NOT be sent on the wire unless every node that
| interprets the format agrees on the semantics.
 -- RFC 4007, section 11.2

I also checked some more browsers and the only one accepting scoped IPv6 address
besides the different Gecko derivatives seems to be Konqueror (at least on my
system): Konqueror does not include the scope id in the Host: header. However
Konqueror also does not include the port number if it's the default port while
Gecko seems to copy the host verbatim from the address bar.

Conclusion (and to correct my earlier statement): In principle it is not correct
of the browser to include the scope id into the Host: header. However, I still
believe that it would not hurt to simply ignore it in the server. Especially
since other likely malformed formats are already ignored, and also because it is
similar to the handling of a port number (accept, but ignore and override with
the actual port of the socket when matching) in the Host: header.

See also:
 https://bugzilla.mozilla.org/show_bug.cgi?id=464162

Now, this problem on Firefox is fixed on Trunk.

Firefox 3.5 contains fix of this problem.
(fixed at 1.9.1 branch or later)

Seems to be a bug only in a "be liberal in what you accept" sense.  Changing this would add complexity and scope for something more serious.