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. Nic

    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
    1. frank Post author

      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. Gregg Leventhal

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

    Reply
    1. frank Post author

      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 Reply

Your email address will not be published. Required fields are marked *