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

The biggest downside is that we'll have to mention the host in an
effectively non-compressible field on every request.

Also, on a number of requests, the host: header differs from the host which
is contained in the URL, and server implementations are not heavily
weighted towards one behaviour or another. It is by far easiest when this
happens to just pass it through and let the server continue to do whatever
it did before...

-=R


On Wed, Jan 30, 2013 at 1:31 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>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.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>