Subject: RE: Host header issue

From: "Josh Cohen (Exchange)" <[email-masked]>
Date: Sun, 5 Sep 1999 20:18:39 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, September 04, 1999 9:52 PM
> To: Josh Cohen (Exchange)
> Cc: [email-masked]
> 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                      [email-masked]
>

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 6 Sep 1999 13:14:56 PDT

The reasoning for the MUST requirement for the Host header
was to leave absolutely no ambiguity for whether/when it
was required, and to ensure that there sufficient servers
that required it to force individuals to upgrade their clients
if they had clients that didn't send it.

Adding this requirement was imposed by the IESG; I don't
think it was originally the consensus of the HTTP working
group to do so.

The arguments you've given against the requirement are
primarily ones of 'general design principles'. If you
were to develop or deploy a server that did not follow
this guideline, you'd have a non-compliant server that
was interoperable with all compliant clients, in addition
to being interoperable with some non-compliant clients.
That's good implementation advice in general, but there
are occasionally reasons to violate general design principles.

You might be able to convince the IESG to drop the requirement
in the case where an absolute URI is supplied, but it's
my guess that the answer will depend on how successful the
original attempt to change user behavior through requirements
on server compliance has been. Are there sufficient 
compliant HTTP servers around that users have upgraded
their clients? My impression is 'no'.

Larry