httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <>
Subject mod_gzip and incorrect ETag response (Bug #39727)
Date Mon, 27 Aug 2007 12:29:36 GMT
Just wondering if there is any plans on addressing Bug #39727, incorrect
ETag on gzip:ed content (mod_deflate).

Been pretty silent for a long while now, and the current implementation
is a clear violation of RFC2616 and makes a mess of any shared cache
trying to cache responses from mod_deflate enabled Apache servers (same
problem also in mod_gzip btw..)

For details about the problem this is causing see RFC2616 section 13.6,
pay specific attention to the section talking about the use of
If-None-Match and the implications of this when a server responds with
the same ETag for the two different variants of the same resource.

There is already a couple of proposed solutions, but no concensus on
which is the bettter or if any of them is the proper way of addressing
the issue.

The problem touches
- ETag generation
- Module interface
- Conditionals processing when there is modules altering the content

Squid currently have a kind of workaround in place for the Apache
problem, but relies on being able to detect broken Apache servers by the
precense of Apache in the Server: header, which isn't fool prof by any


View raw message