httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: Wrong etag sent with mod_deflate
Date Sun, 10 Dec 2006 12:30:55 GMT

On 12/10/2006 12:51 PM, Ruediger Pluem wrote:

> Anyway I guess one reason why we call ap_meets_conditions that early is that
> we want to avoid running through the whole filter chain for a response
> that has not been modified. OTH I fear that we are not in a position at this
> point of time to clearly decide what variant of this resource we really have
> been asked for (mod_deflate decides on this later depending on the request headers
> e.g. Accept-Encoding and some other things) and thus to decide if it has been
> modified or not.

Plus things could be even worse than with the default handler. Let's assume that
we have a content handler outside of httpd (cgi script, something on a Tomcat) which
sets its own ETag and also handles conditional requests. Lets assume further
that checking the ETag supplied in a conditional request is a very cheap operation
compared to generating the content.
That would mean once we add mod_deflate into the output chain and have it modify the
ETag, every conditional request for a compressed variant of the resource would
cause the backend to regenerate the whole content as it would not be able to check on
the mod_deflate modified ETag :-(.
I guess the only way to get out of this is to use TE instead of CE in this case.

Question: How does a client signal that it can handle TE: gzip? Also via Accept-Encoding:
Or is there another header for this?



View raw message