httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <>
Subject Re: Wrong etag sent with mod_deflate
Date Sat, 09 Dec 2006 14:23:51 GMT
On 12/9/06, Ruediger Pluem <> 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

View raw message