httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: absoluteURIs suck
Date Sat, 21 Feb 1998 04:06:43 GMT
>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

Such a concern was less significant than the probability that you might
be sending the absoluteURI request to an old proxy (that doesn't send Host
but will forward it if present) and the possibility that name-based
vhosts would fail due to inadequate implementation.  Much of the weird
wording in the spec is due to several IESG biggies "opinion" of what
was sufficient to ensure implementation versus my own pleading to
ensure deployment.

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

That is one of the cases where the IESG insisted on something implementers
would be forced to implement rather than on something "sufficient".
The compromise I insisted on was that always sending Host would be
dependent on the exact version number (HTTP/1.1) rather than >=1.1.
That way, the requirement can be removed when it is no longer necessary,
which is about the same time that it will be possible to send a full URI
in a non-proxy request (a long long time from now).

>Apache 1.2 and 1.3 are broken as far as forward compatibility with this
>hypothetical HTTP spec as well.  Consider: 
>No NameVirtualHost in the config.  I consider the only correct way to
>implement this config is that *all requests* appearing at will
>be served by that virtual host.  Right now if a request appears there with
>an absolute URI with a hostname that isn't listed *we will reject it*.
>This means we're not forward compatible with some lame HTTP version that
>doesn't exist but is threatened to exist. 
>Contrast this with the behaviour on a Host: header that we don't
>recognize... we just don't care about it, we serve what has been
>configured (a default server, or the ip-vhost).

Either the server is configured to deal with the global namespace, or
it ignores the global namespace assuming that every request it receives
is intended for it.  The requirements in HTTP/1.1 force the server to
recognize its own namespace as part of the global absoluteURI namespace,
thereby giving us "training wheels" for the day in which we always use
the global namespace.  In contrast, the deployment strategy of Host is
not moving toward the global namespace, and thus whether or not we actually
check the Host value for non-vhosts is a decision left to the implementers.

These training wheels have little usefulness on their own, but they do
make it easier to deploy real wheels eventually (just as persistent
connections is actually a training wheel for multiplexed connections).


View raw message