apache

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.

The deflate output filter in Apache breaks Apache’s handling of the HTTP cache validation model. It won’t send an HTTP 304 status if mod_deflate is actively filtering the response, even if the Etag and Last-Modified allow it to. I asked, and apparently this is a known issue. I might have to wait until after exams before making a patch for this one.

In its current state, this introduces a tradeoff for large, uncompressed static files (like CSS and Javascript):

gzip stuff, and you improve site performance the first time someone visits, but it never gets any faster.
allow Apache to send 304 statuses, let the user have a slow load on their first visit, but celebrate as they hit their cache thereafter

The second option looks more attractive.

Tag: apache

Apache 304 and mod_deflate revisited

Apache 304s and mod_deflate