RE: Host header issue

> -----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
>

Received on Sunday, 5 September 1999 20:23:13 UTC