82388 - Proxy: SSL PROXY (tunnel) should use "Hosts:"

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Chris Hiner]

User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; rv:0.9+) Gecko/20010523
BuildID:    2001052308

While trying to connect to any https site through my Apache 1.3.12 proxy, I get
a bad request error message from Apache:
Your browser sent a request that this server could not understand.
client sent HTTP/1.1 request without hostname (see RFC2068 section 9, and 14.23)

This used to work correctly with 0.9 on Linux.

This looks related to the landing for bug 76866.

Comparing tcpdumps of the connection, 2001052308 only sends:
CONNECT digitalid.verisign.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; rv:0.9+) Gecko/20010523

Whereas 0.9 sends Host:, User-Agent:, Pragma:, Cache-Control:, a few Accept*,
Keep-Alive:, and Connection:.

RFC2616 14.23 says:
A client MUST include a Host header field in all HTTP/1.1 request messages.

Workaround: Use the debug networking preference to set the http version to 1.0.

Comment 1

[Bradley Baetz (:bbaetz)]

darin, this is probably yours.

We don't send the host header, and the examples in the CONNECT RFC do use it
(RFC 2817, section 5.2). RFC2616, section 9, says: "The Host request-header
field (section 14.23) MUST accompany all HTTP/1.1 requests."

Squid doesn't care, probably because its an HTTP/1.0 proxy.

Also see bug 82658.

Taking QA per discussion with benc.

Comment 2

[benc]

+nsbeta1.

If its supposed to be there, it better be there.

Comment 3

[Darin Fisher]

why is the host header necessary?  the request line includes the host.  is the
spec explicit about requiring this?

Comment 4

[Bradley Baetz (:bbaetz)]

Yep. The spec is explicit, and doesn't even give the server the option to 'be 
liberal in what it accepts', because of the requirement to return a 400 error.

I think that this is a minor bug in wording of the RFC, because:

- RFC2616 doesn't go into any sort of detail about the authority form. Section 
5.1 only has the Host: header as a MUST for abs_path requests.

- A literal reading of section 5.2 implies that, since the request isn't an 
absoluteURI according to the grammar, rule 1 doesn't apply. Rule 2 tells us to 
look at the host header, which isn't present. Rule 3 then requires the 400 
response.

However, section 9 is unambiguous - all HTTP/1.1 requests MUST send a Host 
header, without exception, so the spec is clear.

If someone can point me at another HTTP/1.1 proxy server, then I'll test on 
that.

Comment 5

[Darin Fisher]

RFC 2616 does not discuss SSL tunneling or the semantics of the CONNECT method.
I understand RFC 2616's requirement that a Host header be sent in every HTTP/1.1
request, but it really baffles me why this would be required for a CONNECT
request.  But whatever, I suppose it wouldn't hurt to just send it.

I think this is of minor importance unless you can show me a proxy server for
which this causes problems.

Comment 6

[Bradley Baetz (:bbaetz)]

From the original bug report, apache shows this problem (although I haven't
actually verified this)

rfc2616 mentions connect as a subsection of section 9, which has the MUST for
sending a Host: header. I can't think of a reason why you'd want to do this, but
since its about 2 lines of code, and would presumably make apache work again....

Comment 7

[benc]

After a long discussion with bbaetz, I say put Host: in.

This would allow support of virtual proxy hosting, sounds a bit essoteric, but
we see products (like Apache and Borderware <via the ftp host: bug>).

Here's some quotes from the CONNECT document that also support this interpretation:

"This document focuses on the differences and additions to HTTP/1.x; refer to
the HTTP/1.x specifications for a full specification of HTTP/1.x."

"In order to make this extension be backward
   compatible, the handshake must be in the same format as HTTP/1.x
   requests, so that proxies without support for this feature can still
   cleanly determine the request as impossible for them to service, and
   give proper error responses (rather than e.g. get hung on the
   connection)."

"4. Extensibility

   The tunneling handshake is freely extensible using the HTTP/1.x
   headers"

Comment 8

[Gerdinand]

I am behind a Microsoft Proxy Server 2.0 and with all the nightly builds after
0.9 was released, I get : 

"HTTP Error 400 
400 Bad Request

Due to malformed syntax, the request could not be understood by the server. The
client should not repeat the request without modifications."

when I try to connect to any secure site. So I would say this is a very
important issue. The 'workaround',(Setting the HTTP version to 1.0), also does
not work for me. It seems as if the browser goes into a loop of resolving and
connecting to the host site.

Comment 9

[Darin Fisher]

Attachment: fixes this bug as well as bug 82658

Comment 10

[benc]

Gerdinand:

Lets put this in a new bug.

Comment 11

[Darin Fisher]

-> mozilla 0.9.1 (per approval from [e-mail])

Comment 12

[Bradley Baetz (:bbaetz)]

r=bbaetz

Comment 13

[Doug Turner (:dougt)]

sr= me

Comment 14

[Darin Fisher]

fix checked in

Comment 15

[Asa Dotzler [:asa]]

a= [e-mail] for 0.9.1 checkin (on behalf of drivers)

Comment 16

[Chris Hiner]

Works for me now on Linux 2001053008 with http1.1.  Thanks.

Comment 17

[Bradley Baetz (:bbaetz)]

VERIFIED linux 12 Jun trunk build.