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 Sat, 09 Dec 2006 17:36:54 GMT

On 12/09/2006 03:23 PM, Justin Erenkrantz wrote:
> On 12/9/06, Ruediger Pluem <> wrote:

>> Would the following patch address all your points for a CE mod_deflate
>> filter?
> No - this patch breaks conditional GETs which is what I'm against.

Ok, to be honest my question was more directed to Roy than to you, to
understand Roys ideas and plans from a patch level perspective. I
was pretty sure that you would not like it as you have expressed it clearly

> See the problem here is that you have to teach ap_meets_conditions()
> about this.  An ETag of "1234-gzip" needs to also satisfy a
> conditional request when the ETag when ap_meets_conditions() is run is
> "1234".  In other words, ap_meets_conditions() also needs to strip
> "-gzip" if it is present before it does the ETag comparison.  But, the
> issue is that there is no real way for us to implement this without a
> butt-ugly hack.

Thanks for giving the pointer to ap_meets_conditions. So content compressed
by mod_deflate would not stand conditional requests based on ETags any longer.
That would be bad. Would it help if we simply unset the ETag in mod_deflate?
mod_filter does this in these situations or does this have any other nasty
side effects?

So what I understand from the current discussion is that

1. Using TE instead of CE would be RFC compliant and would relief us of
   much problems except the one that none of the major browsers can handle
   it and thus would effectively make mod_deflate useless.

2. There are two different points of view in the CE case:
   Roy and Henrik say that a strong ETag arriving at mod_deflate must
   be replaced with a different strong ETag within mod_deflate (e.g
   by adding -gzip to it), because as mod_deflate is doing CE the entities
   before and after mod_deflate are different and require different ETags.
   Justin OTH says that it is sufficient to convert a strong ETag into a
   weak one, right?



View raw message