- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 30 Jan 2013 22:48:51 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
On Wed, Jan 30, 2013 at 11:03:06PM +1300, Amos Jeffries wrote: > On 30/01/2013 10:34 p.m., 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 > > > > Indeed. +1 on all the above. +1 for me too. Looking up the header and concatenating it with the URI to permit string matching is quite inefficient and we already have to do it due to end-user demand. Willy
Received on Wednesday, 30 January 2013 21:52:30 UTC