Andr� Malo wrote:
* Chris Elving <[EMAIL PROTECTED]> wrote:
As far as I understand it, mod_deflate's practice of returning Content-encoding: gzip but using Transfer-encoding: gzip semantics (e.g. conditionally compressing a resource and using the same ETag for both the compressed and non-compressed forms of that resource) is potentially poisonous to proxies that handle Range.
Oh well. The ETag is probably a problem. In the first step we could omit it from the response. Opinions?
the way apache internally handles the ETag header seems to have a few issues when filters are involved (which I once outlined for the list). in the above scenario, compressed and non-compressed resources could probably use the same ETag, just marked as weak both times. however, we lack a "weakening" API at the moment.
so, if ETag + compression is going to cause a problem, then it's probably best to remove it like mod_include (in 2.1) currently does.
since the hackathon is so close, if people are willing to re-examine the possibility of moving ap_meets_conditions and other entity logic to its own filter, I'll be there :)
--Geoff
