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

VERIFIED FIXED in mozilla0.9.1



18 years ago
18 years ago


(Reporter: bugzilla, Assigned: darin.moz)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: r=bbaetz, sr=dougt, a=selmer, URL)


(1 attachment)



18 years ago
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:
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.
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.
Assignee: neeti → darin
Severity: normal → major
Ever confirmed: true
QA Contact: benc → bbaetz

Comment 2

18 years ago

If its supposed to be there, it better be there.
Keywords: nsbeta1

Comment 3

18 years ago
why is the host header necessary?  the request line includes the host.  is the
spec explicit about requiring this?
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 

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 

Comment 5

18 years ago
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.
Target Milestone: --- → mozilla0.9.2
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

18 years ago
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

"4. Extensibility

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

Keywords: regression
Summary: https connect not sending Host: header to proxy → Proxy: SSL PROXY (tunnel) should use "Hosts:"

Comment 8

18 years ago
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.


18 years ago
Blocks: 82658

Comment 10

18 years ago

Lets put this in a new bug.

Comment 11

18 years ago
-> mozilla 0.9.1 (per approval from
Target Milestone: mozilla0.9.2 → mozilla0.9.1


18 years ago
Whiteboard: r=bbaetz, sr=?, a=selmer
sr= me


18 years ago
Whiteboard: r=bbaetz, sr=?, a=selmer → r=bbaetz, sr=dougt, a=selmer

Comment 14

18 years ago
fix checked in
Last Resolved: 18 years ago
Resolution: --- → FIXED
a= for 0.9.1 checkin (on behalf of drivers)

Comment 16

18 years ago
Works for me now on Linux 2001053008 with http1.1.  Thanks.
VERIFIED linux 12 Jun trunk build.
You need to log in before you can comment on or make changes to this bug.