part 1 section 4.1.2 - authority form

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

part 1 section 4.1.2 - authority form

Amos Jeffries-2
I have just run up against how Firefox are sending Host: in proxied
HTTPS requests.

  CONNECT example.com:443 HTTP/1.1
  Host: example.com

Part 2 on CONNECT appears to document this as wrong, but uses port 80
which is a little bit ambiguous given that CONNECT are usually used for 443.
  Am I right in assuming that it means the port is always required on
CONNECT request Host: headers? (despite the obvious redundancy).


While looking it up I also came across a bit of a contradiction in part
1 section "4.1.2 request target".

It has a one liner on the use of authority:

   The "authority form" is only used by the CONNECT request method

the following paragraph contains a MUST which contradicts that statement:

   the authority component MUST be transmitted in a Host header field


I'm thinking the wording there needs a small tweak to bring them into line:

  The "authority form" is only used by the CONNECT request method and
Host: header.


AYJ

Reply | Threaded
Open this post in threaded view
|

Re: part 1 section 4.1.2 - authority form

Daniel Stenberg
On Tue, 16 Aug 2011, Amos Jeffries wrote:

> Part 2 on CONNECT appears to document this as wrong, but uses port 80 which
> is a little bit ambiguous given that CONNECT are usually used for 443. Am I
> right in assuming that it means the port is always required on CONNECT
> request Host: headers? (despite the obvious redundancy).

Many years ago we had curl include the port number unconditionally in Host:
headers, only to switch it off again since there were too many proxies/servers
out there that didn't like Host: headers with the default port given.

In short: when doing HTTPS (CONNECT) curl doesn't include port 443 in the
Host: header.

When doing HTTP, curl doesn't include port 80 in the Host: header.

--

  / daniel.haxx.se

Reply | Threaded
Open this post in threaded view
|

RE: part 1 section 4.1.2 - authority form

Eric Lawrence-4
FWIW, this is going to get much more relevant as WebSockets will make the practice of CONNECT'ing to non-443 ports much more common.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Stenberg
Sent: Tuesday, August 16, 2011 4:06 AM
To: Amos Jeffries
Cc: HTTP Working Group
Subject: Re: part 1 section 4.1.2 - authority form

On Tue, 16 Aug 2011, Amos Jeffries wrote:

> Part 2 on CONNECT appears to document this as wrong, but uses port 80
> which is a little bit ambiguous given that CONNECT are usually used
> for 443. Am I right in assuming that it means the port is always
> required on CONNECT request Host: headers? (despite the obvious redundancy).

Many years ago we had curl include the port number unconditionally in Host:
headers, only to switch it off again since there were too many proxies/servers out there that didn't like Host: headers with the default port given.

In short: when doing HTTPS (CONNECT) curl doesn't include port 443 in the
Host: header.

When doing HTTP, curl doesn't include port 80 in the Host: header.

--

  / daniel.haxx.se