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

VERIFIED FIXED in mozilla0.9.1

Status

()

defect
--
major
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: bugzilla, Assigned: darin.moz)

Tracking

({regression})

Trunk
mozilla0.9.1
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

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:
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: benc → bbaetz

Comment 2

18 years ago
+nsbeta1.

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

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 
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.
(Assignee)

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.
Status: NEW → ASSIGNED
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
   connection)."

"4. Extensibility

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

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.
(Assignee)

Updated

18 years ago
Blocks: 82658

Comment 10

18 years ago
Gerdinand:

Lets put this in a new bug.
(Assignee)

Comment 11

18 years ago
-> mozilla 0.9.1 (per approval from selmer@netscape.com)
Target Milestone: mozilla0.9.2 → mozilla0.9.1
r=bbaetz
(Assignee)

Updated

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

Updated

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

Comment 14

18 years ago
fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
a= asa@mozilla.org for 0.9.1 checkin (on behalf of drivers)
(Reporter)

Comment 16

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