> -----Original Message-----
> From: Albert-Lunde@nwu.edu [mailto:Albert-Lunde@nwu.edu]
> Sent: Saturday, September 04, 1999 9:52 PM
> To: Josh Cohen (Exchange)
> Cc: http-wg@hplb.hpl.hp.com
> Subject: Re: Host header issue
>
>
> 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
I agree with this..
> 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.
>
Yes, obviously a 1.0 server will choke all over the place if you
include an absoluteURI. However, including both a host header
and an absoluteURI will choke the server as well.
If your talking to a 1.0 server, there simply is no way you
can expect it to understand an absoluteURI.
In the 1.1 case, it can understand both an absolute URI as well
as the Host: header case.
So, I dont see this as a compatible "transistion".
If we perceive the "transistion" to be toward absoluteURIs,
then we should not discourage their use. This is
effectively what we have done. The http/1.1 spec teaches
us that there is no good reason to use absoulteURIs
since we MUST include a host header as well. (Even
when we know that the server and proxy are 1.1 compliant
and understand absoluteURIs).
I guess what I'm complaining about is that the spec shouldnt
require a server to bounce a request if there is an absoluteURI
but no Host: header, especially when it can understand the
implied host: header value.
I think its especially frustrating since it violates one of
the basic tenents of protocol design which is be conservative
in what you send, but liberal in what you accept.
I think we should remove this MUST from server implementation.
> 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
>