Subject: Host header issue

From: "Josh Cohen (Exchange)" <[email-masked]>
Date: Sat, 4 Sep 1999 17:39:25 -0700

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.

It seems to me that if you have an absolute URI, the host
header is redundant.  If I remember correctly, from the wg
meetings in the long past, the host header was added because
absolute URIs werent used to origin servers.
Now that HTTP/1.1 allows the use of absolute URIs, doesnt
it seem wise to remove the requirement of the host: header when
they are used?

It certainly makes things simpler if Im build a new client/server
system to just use absolute URIs consistently.

Can anyone explain what the justification was for requiring
the host: header even when their is a perfectly good
host indication in the absoluteURI?

Frankly, I can't beleive I didn't raise this sooner, I always
assumed this was the case.   I only ran into it in a debate
here with a colleague.

---

From: [email-masked] (Albert Lunde)
Date: Sat, 04 Sep 1999 23:51:43 CDT

> in the request.   Looking closely at the spec, I see
[...]
> 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                      [email-masked]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 04 Sep 1999 23:32:44 -0700

>host indication in the absoluteURI?

So that an old proxy will forward the Host field, and to satisfy an
IESG request.

....Roy

---

From: Wilbur Streett <[email-masked]>
Date: Thu, 09 Sep 1999 08:51:07 -0400

At 08:13 AM 9/8/99 -0700, you wrote:
>Not only did this waste IP addresses (getting to be a scarce resource), 
>it caused MAJOR headaches among major ISP's doing Web hosting (think about 
>the problems caused by adding the 257'th host to a web server on a class 
>C net (or whatever you call the CIDR equivalent these days).

Oh, so the problem with the IP address space is the reason that the design
doesn't make sense.  That makes perfect sense!

>So certain (more than one) IESG/IAB members insisted this get fixed in
>such a way that it COULD NOT UNDER ANY CIRCUMSTANCES be gotten wrong in all
>software going forward.  There was no confidence in people getting
>it right otherwise.

People?  I thought that this was technology?

>At least one of these people said 'I don't care if HTTP/1.1 has anything
>else', as a way to show the vehemence of the problem.

In other words, fix our problems in other areas with a screwy design.

Typical "design by committee" stuff.

Now everything's clear.

Wilbur

     --------------------------------------------
        Putting A Human Face On Technology ;-)
     --------------------------------------------
  Literally!  http://www.monmouth.com/~wstreett/FaceIT/

---

From: John Stracke <[email-masked]>
Date: Thu, 09 Sep 1999 13:57:57 -0400

> People?  I thought that this was technology?

So how do you build technology? At eCal, we get people to do it.  :-)

Seriously, though.  Engineering is more than coming up with the best
technology; it's also coming up with something that can be built by real people
with real, human failings.  Protocols that are too complex for the people who
need to implement them will lose out to simpler protocols, if only because the
implementations of the complex protocols will be buggy and late.

--
/===============================================================\
|John Stracke    |http://www.ecal.com|My opinions are my own.   |
|Chief Scientist |==============================================|
|eCal Corp.      |The problem with any unwritten law is that you|
[email-masked]|don't know where to go to erase it.           |
\===============================================================/

---

From: [email-masked] (Jim Gettys)
Date: Wed, 8 Sep 1999 08:13:21 -0700

Here's the story, folks (short history lesson):

The lack of host information meant that IP addresses has had to be assigned
for all virtual host web sites.

Ergo, the requirement to report buggy clients with an error.

And note Roy's remark about proxies...

Might there be some further optimization possible?  Maybe.
But we sweat blood over them words, as I remember.  And they were written
to enable transitioning to absolute URI's in a V1.2, as I also remember
(we had a problem that would have made that hard at one point, that did
get fixed).

If you insist on riding this horse, you should start by refreshing your 
mind with all the discussion on the topic, and of exactly how the spec 
words got to where they are. The issues were more subtle than they
first appeared, as I remember the discussion (and I don't remember all
the subtleties).
			- Jim