Re: Do we kill the "Host:" header in HTTP/2 ?

from a proxy POV, it's very useful, nay vital that we can tell the 
difference between a request that a client thinks it is sending to a 
proxy, vs a request the client thinks it is sending to a server.

Personally I would be very happy to drop the host part of the URI, and 
keep the host header, but have another flag somewhere that identifies 
the request as one being made to a proxy.

Especially for authentication purposes, the 2 need to be distinguished.

In fact for authentication, I would extend it to allow for the 
definition of the target of the auth.  If you have a request going 
through a chain, and several links require auth from the client, there's 
currently no way to do it safely.

Adrien


------ Original Message ------
From: "Eliezer Croitoru" <eliezer@ngtech.co.il>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 31/01/2013 7:49:57 a.m.
Subject: Re: Do we kill the "Host:" header in HTTP/2 ?
>On 1/30/2013 11:34 AM, Roland Zink wrote:
>>On 30.01.2013 10:31, Poul-Henning Kamp wrote:
>>>Content-Type: text/plain; charset=ISO-8859-1
>>>--------
>>>In message
>>><CAP+FsNf73hw8YDgiLoPCv-CgSGXuKv-7pG9Hqc5H7NGYS7Zr3A@mail.gmail.com>,
>>>Roberto Peon write
>>>s:
>>>
>>>>I'm saying that we're not currently talking about killing the host
>>>>header.
>>>>Are you suggesting that it should be killed?
>>>My inclination is that it should, and the text in RFC2616 seems to 
>>>hint
>>>that others have tagged its existence as a mistake already long time 
>>>ago.
>>>
>>>I also don't spot any obvious down sides if we remove it.
>>>
>>>Given that the conversion rules for {abs} <--> {rel+Host} has already
>>>been laid down firmly many years ago, it will not raise any isses
>>>for HTTP/1 <--> HTTP/2 conversion.
>>>
>>>It unifies an aspect of the "proxy-version" and the "server-version"
>>>of the protocol, that can't but help make clients code simpler.
>>>
>>>And it would make HTTP/2 a speed improvement over HTTP/1 since all 
>>>the
>>>"routing" information load-balancers need, will be collected in
>>>one place and up front.
>>>
>>>And, not the least: It is certainly easier to explain clearly.
>>>
>>+1
>>
>+1 for all the above.
>
>-- Eliezer Croitoru
>
>

Received on Wednesday, 30 January 2013 21:31:45 UTC