httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Compression via content negotiation
Date Thu, 03 Dec 1998 00:22:12 GMT
>> Yep, and that part isn't going to change.  There must always be a
>> distinction within our httpd namespace between URLs that are negotiation
>> handles and those that are not.  Failure to maintain this distinction
>> completely screws over both caching and authoring of resource
>> representations.
>I'm not so sure that's a good idea. RIGHT NOW a site using MS's server
>can be configured to transparently encode html files. Static, dynamic,
>and lazy compression can all be configured. Current versions of both IE
>and Navigator work correctly with MS's server. Compression can be
>applied even to urls that explicitly exist, not just negotiation

Of course it can.  HTTP/1.1 allows compression at three different
levels -- media type, content encoding, and transfer encoding.  The first
two are properties of the requested resource and the third is something
that can be added on the fly regardless of the resource.  A resource is
a conceptual identity that is realized by the origin server (Apache)
establishing a mapping from a name (URI) to a set of representations
(documents), where the representation may be a file or generated on
the fly.  If the requested URI corresponds to a file, then the resource
that the user requested is the direct mapping to that file and nothing
else, and thus we cannot add a content-encoding to it just because you
might want to save a few bits.  We could add a transfer-encoding if the
request chain is capable of handling it, but nobody implements that yet
and it would be hell to add to Apache 1.3.x (hence, it is a 2.0 issue).

In short, if you want optional compression, use a request URI that
allows optional compression.  We aren't going to change this algorithm
because caching gets screwed and performance sucks whenever server-side
negotiation is used.  MS's server is either disabling caching on those
responses or allowing compressed content to be served to clueless clients,
neither of which are acceptable options for Apache.


View raw message