httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@c2.net>
Subject Re: Compression via content negotiation
Date Tue, 01 Dec 1998 19:29:34 GMT
On Mon, 30 Nov 1998, Paul Ausbeck wrote:
> PR 3447 describes a shortcoming in how apache handles content
> negotiation and compression. What's the chance of getting the patch
> suggested there or something like it into 1.3.4?

I've already proposed a fix for the bug in PR 3447.

> I have looked at some of the issues involved and I think that the four
> most important outstanding issues are:
> 
> 1) Apache currently does not place Vary response-headers on content
> negotiated responses. This could mess up some installations where agents
> that handle compression and agents that do not both use a common proxy
> cache.

This is a surprise. Apache is designed to add valid Vary headers onto all
content-negotiated headers. There is abug when the negotiation happens
between a resource with a particular attribute and one without any value
for that attribute, and I've proposed a fix. For all other cases (i.e.
negotiating between variants with different values for a particular
dimension of negotiation) then a valid Vary header should be added. Can
you give an example of a case where it does not?

> 2) It may be useful to add some compression specific configuration
> options.

I prefer the generic dirctives we have now to add a mapping for any
arbitrary compression method.

> 3) A better negotiation algorithm than proposed in PR 3447 may exist.

Negotiation aglorithms are very complex to get right. The current one
implemented in mod_negotiation is quite simplistic, and basically looks at
one dimension of negotiation at a time. One aim I had when I rewrote
mod_negotiation was to allow for different negotiation algorithms. It
would not be different to add new ones: for example, one based on the RVSP
"network algorithm" would make sense in some situations (it basically
multiplies the q factors for all dimensions to get an overall q for a
variant, thus taking equal account of language, content-type, charset and
encoding). But even that is not valid for all situations.

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

Paul
--
Paul Sutton, C2Net Europe                    http://www.eu.c2.net/~paul/
Editor, Apache Week .. the latest Apache news http://www.apacheweek.com/


Mime
View raw message