httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Compression via content negotiation
Date Tue, 01 Dec 1998 23:33:59 GMT

On Tue, 1 Dec 1998, Paul Sutton wrote:

> > 4) It may be better to handle compression via a separate compression
> > specific mechanism similar to Microsoft's Internet Information Server or
> > the apache compression project at In a compression specific
> > scheme, compression can be applied to a non-ambiguous url. For example,
> > a request for foo.html returns the equivalent of foo.html.gz. In the
> > proposal of PR3447, given a request for foo.html, if foo.html exists it
> > would be returned even if foo.html.gz also existed. Only a request for
> > foo would get foo.html.gz. Of course, this could be changed...
> Yes, this is a problem with language negotiation also. There should be an
> option to force negotiation even if the directly referenced filename
> exists. However this itself may cause problems, for example, if the user
> really did want that variant rather than server-based negotiation.

Why is this a problem?  Didn't we just add the "default-handler" or
something?  Just name the file foo.html.def rather than foo.html, and add
a "AddHandler default .def" (check the code I may have this wrong). 
There's no need to add more code.  This way you also get the advantage of
having some semblance of speed for those files for which there is zero
negotiation possible (i.e. foo.jpg,, yeehaw.mp3, whatever).

I didn't see either of you mention TE.  And I haven't seen Roy pipe up
yet... last time this came up on the mozilla group the only conclusion
that I saw which was obvious is that with just RFC2049 you cannot do
transparent compression.  You need the draft update to HTTP/1.1 and the TE
header.  Accept-Encoding is just broken when you consider bugs in existing
clients.  Or something along those lines.  (And I'm also about 8 months
out of date on this, so I could be wrong.) 


View raw message