httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: absoluteURIs suck
Date Fri, 20 Feb 1998 01:41:23 GMT

On Fri, 20 Feb 1998, Anand Kumria wrote:

> On Wed, 18 Feb 1998, Dean Gaudet wrote:
> > I really don't understand the lameness regarding absoluteURIs in HTTP/1.1. 
> > Suppose HTTP/1.2 comes out and dictates that absoluteURIs must be used for
> > all requests (this is hinted at in RFC2068).  In order to interoperate
> > with HTTP/1.1 servers all HTTP/1.2 clients will have to also include Host:
> > headers.  This is a waste of bandwidth having to include the hostname
> > twice. 
> And it will be because of Apache. This is basically the same issue I was
> trying to point out to you in PR#1454 - if you follow the processing
> strategy outlined in the RFC and ignore the precense of Host: fields then
> client implementors won't have to do this.

No, Apache follows the spec.  Until and unless a later revision of
HTTP/1.1 relaxes the two or three places that RFC2068 says a client MUST
send a host header apache will require it.

> > It could be fixed by relaxing HTTP/1.1 and requiring that the client MUST
> > send either an absoluteURI or a relativeURI with a Host: header. 
> Indeed following "Be liberal in what you accept" would be useful. The
> rational (I beieve) for closing 1454 was that "Apache relaxes the
> requirement for a Host: header for versions greater than HTTP/1.1"

"Be liberal in what you accept" has absolutely no relevance here.  A
client is not an HTTP/1.1 client unless it follows that MUST include Host: 
header rule.  No such clients exist, because Apache enforces the rule (as
required) and any client author would be stupid to not interoperate with

> Marc (Slemko) notes that some other HTTP server ignore the Host: header
> (for 1.1 requests) and some others don't. Sounds like a spec ambiguity,
> perhaps Roy Fielding would care to comment on the intent of the WG at the
> time?

No, those servers are broken.  There is no ambiguity in the spec, it
spells this out twice.


View raw message