- From: Albert Lunde <Albert-Lunde@nwu.edu>
- Date: Sat, 04 Sep 1999 23:51:43 CDT
- To: joshco@exchange.microsoft.com
- Cc: http-wg@hplb.hpl.hp.com
> In going over some implementation stuff here, I ran into > an issue that I apparently misread in the spec. > > According to the spec, the host: header is always required > in HTTP/1.1. In my mind, I always perceived that to mean > that it was required as long as a relativeURI was used > in the request. Looking closely at the spec, I see > that is not the case. [...] > Can anyone explain what the justification was for requiring > the host: header even when their is a perfectly good > host indication in the absoluteURI? HTTP/1.1 was deliberately specified the way that it is as a transition measure. RFC 2616 says in section 5.1.2: "To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies." Note that if you have a client send an absolute URL to anything but a proxy, it's not HTTP/1.1. But this could allow writing, say, an HTTP/2.0 spec that used absolute URLs everywhere. (Though the complexity of writing HTTP/1.1 may push that further into the future, and recent talk leans more towards a binary wire protocol.) The Host: header was introduced because it allowed use of name based virtual hosting without breaking old servers. It could be ignored by servers that did not understand it, whereas shifting clients to using absolute URLs would have caused old HTTP/1.0 servers to return "Forbidden" errors all over the place. So you can look at this potentially as a two phase transition, each step of which is compatible with one version prior. -- Albert Lunde Albert-Lunde@nwu.edu
Received on Saturday, 4 September 1999 21:55:29 UTC