- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Wed, 30 Jan 2013 13:51:47 -0800
- To: "Adrien W. de Croy" <adrien@qbik.com>
- Cc: Eliezer Croitoru <eliezer@ngtech.co.il>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, John C Klensin <john-ietf@jck.com>
On Wed, Jan 30, 2013 at 1:31 PM, Adrien W. de Croy <adrien@qbik.com> wrote: > > 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. > So, I remember vividly the meeting at which the Host: header discussion occurred, and I have heard John Klensin rant about this many times since (he was the APPs AD at the time), so my context on this is probably a bit odd. At the time, we added the host header to help stave off the consumption of independent IP addresses for web sites that were being served off the same servers and physical infrastructure. Pretty much everyone at the time thought the *right* idea was to move to full URLs. We were reluctant to do so because of installed base and, because this could be a "breaking change", the consequences of revising the version number. The questions about the HTTP WG minutes on the topic (kicked off by Harald Alvestrand) start here: http://www.hpl.hp.com/personal/ange/archives/archives-96/http-wg-archive/0687.html and they are quite amusing to read now. We had no idea how early we were in the popularity curve of HTTP or how dominant it would become, but it was clear even then that the protocol would be very, very common on the network. In retrospect, it is clear that we shouldn't have looked at the current installed base--we should have looked at what we expected eventual use would be. That makes "the earlier the better" clear. For HTTP 2.0, where we can make non-backward compatible changes, I personally think the right thing to do is to drop the Host: header (that version shift is what we were waiting for 17 years ago, after all). If there are things folks are getting from side-effects of the Host header (e.g. proxy targeting), we put them into the bin of potential requirements for HTTP 2.0 *and create mechanisms to meet those needs*. I think Adrien's proposal for extensions to the host header makes clear that the need isn't perfectly met by the host header in any case, so mapping out the real aim and meeting that seems like the best notion to me. Just my two cents, Ted
Received on Wednesday, 30 January 2013 21:52:15 UTC