Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 3137 invoked by uid 6000); 1 Dec 1998 23:34:07 -0000 Received: (qmail 3130 invoked from network); 1 Dec 1998 23:34:05 -0000 Received: from twinlark.arctic.org (204.62.130.91) by taz.hyperreal.org with SMTP; 1 Dec 1998 23:34:05 -0000 Received: (qmail 27578 invoked by uid 500); 1 Dec 1998 23:33:59 -0000 Date: Tue, 1 Dec 1998 15:33:59 -0800 (PST) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: Compression via content negotiation In-Reply-To: Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org 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 mozilla.org. 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, blah.zip, 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.) Dean