On 12/9/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
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?
AIUI, many caches do not allow the response to be cached at all if it doesn't have an ETag. This is why it was brought up that not doing deflate at all might be better in some cases than removing the ETag.
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.
Right.
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?
In the ideal world, I think a weak ETag would be the 'right' thing - however, the current spec doesn't allow conditional GETs to work with weak ETags. Therefore, to allow conditional GETs, mod_deflate can only produce strong ETags. However, to make conditional GETs work and to create a different ETag, the transformation has to be reversible - which I believe may become a sticking point. (BTW, I disagree with Roy and Henrik that the transformation that mod_deflate is applying changes the actual meaning of the content; but that's largely an irrelevant and academic point for this list.) HTH. -- justin
