On 12/9/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> The existing filter needs to modify the ETag field value (and
> any other entity-dependent values that we can think of) or be
> removed as a feature. Weak etags are not a solution -- being able
> to make range requests of large cached representations requires a
> strong etag, and it really isn't hard to provide one. It is better
> to not deflate the response at all than to interfere with caching.
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.
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.
However, I disagree with Roy in that we most certainly *do* treat the
ETag values as opaque - Subversion has its own ETag values - Roy's
position only works if you assume the core is assigning the ETag value
which has a set format - not a third-party module. IMO, any valid
solution that we deploy must work *independently* of what any module
may set ETag to. It is perfectly valid for a 3rd-party module to
include "-gzip" at the end of their ETag. For example, if you had a
file called "foo-gzip" in revision 10, SVN would assign the ETag
"10//foo-gzip". (And, I could construct a conflict where httpd would
hork the ETag incorrectly for any arbitrary value.) -- justin
