Last year I commented on how mod_deflate breaks the cache validation model. Essentially the problem has been addressing two issues:
- Apache bug #39727, RFC 2616 requires unique strong entity tags for every entity. Presumably this means after Content-Encoding (but not Transfer-Encoding). The fix was for deflate to add “-gzip” to the ETag.
- Apache bug #45023 concerns Apache not being able to recognise the transformed ETag (with the -gzip) as the same entity, and hence not sending 304s when it should have.
So in January 2008, a change was committed to fix #39727, which introduced #45023. Now in April this year, it was reversed to fix #45023. I agree with the priorities here; no caching is much worse for web performance.
As Roy Fielding pointed out the correct way to deal with this issue is to stop abusing Content-Encoding for performance-compression and start using Transfer-Encoding; pity browsers and HTTP servers haven’t got there yet.
6 thoughts on “Apache 304 and mod_deflate revisited”
Hey there, late to the party, January 2013, but the issue persists.
Apache 2.4 deflate + etag = NO 304 response.
Did you find a workaround? Assume not, I have scoured the net for past 2 hours and have come up empty handed.
Shame, gzip + 304 combo is a serious nice-to-have…
Could this be solved using Last-Modified instead of ETag? Or would that still make caches store the uncompressed content before GZIP is applied?
Yes, you can use “FileETag None” (or better “DeflateAlterETag NoChange” if your apache is new enough) to disable Etag (always, or only in GZIP problematic cases)