3 Apache mod_cache gotchas

If you want to avoid the learning curve of Squid and Varnish or the cost of a dedicated caching & proxying appliance, using Apache with mod_cache may seem like a good, simple and cheap solution. Rest assured, it can be -to some extent- but here are 3 gotchas I learned the hard way:

  1. mod_cache ignores Cache-control if Expires is in the past (which it shouldn’t according to RFC2616), so you might have to unset the Expires-header.
  2. mod_cache by default caches cookies! Let me repeat; cookies are cached! That might be a huge security-disaster waiting to happen; sessionid’s (that provide access for logged-on users) are generally stored in cookies. If a logged on user that request an uncached page, then that user’s cookie will get cached and sent to other users that request the same page. Do disable this by adding “CacheIgnoreHeaders Set-Cookie” to your config
  3. mod_cache by default treats all browsers like the one that triggered the caching of the object. In the field that approach can cause problems with e.g. CSS-files that are stored gzipped (because the first browser requested with header “Accept-Encoding: gzip, deflate”). If a browser that does not support gzipped content requests the same file, the CSS will be unreadable and thus not applied. The solution; make sure the “backend webserver” sends the “Vary: Accept-Encoding” header in the response (esp. for CSS-files). This will tell mod_cache to take different Accept-Encodings into account, storing and sending different versions of the same CSS-file.

6 thoughts on “3 Apache mod_cache gotchas”

  1. About #3, should it be enough to add “Header append Vary: Accept-Encoding” into the VirtualHost block? I thought this would would enable “Accept-Encoding” variation on every request on this site, but I still have the problem with the cache returning the wrong encoding type.

    Reply
    • That _should_ work I thinks, if I’m not mistaking that indeed is what we did as well, but I should check our config. Is the problem with responses for all browsers?

      Reply
  2. Is ignoring the set-cookie header enough to prevent session-poisoning since the “cookie” header will be present in subsequent requests?

    Reply
    • preventing set-cookie makes sure the cached pages that are sent as in the HTTP-response don’t set a session cookie from an earlier session.
      if the current session contains a (correct) cookie in the HTTP-request, it will just remain present in each subsequent request, but as it is a correct current session cookie, it is not unsafe.

      Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.