In my attempts to create the most Digg resilient website, I decided there was only one thing for it, full page-based caching on the server.

My first foray into this was trying to implement Zend’s Zend_Cache_Frontend_Page.

However, I found a few show-stopping bugs in this, when involving browser-based cache HTTP status (304 Not Modified), and for http redirects. The problem is, the frontend caches the page whatever the HTTP status is sent. For instance, notifying to the browser:

header('HTTP/1.1 304 Not Modified');
exit;

If this was run while the cache was invalidated, the cache would store a blank page. Any requests after this would serve HTTP/1.1 200 OK with a blank page.

It seems that the cache should ideally only cache the page on HTTP status 200 OK, otherwise the example above, and any other status’ (stati?) will be cached.

So I had a look into fixing the bug. It turns out, as far as I know, there is no way to retrieve the sent HTTP status (headers_list doesn’t appear to return it). A fix would have to involve an addition to the PHP binary.

Alternatively, there would have to be another way to invoke the HTTP status, whilst storing it in a PHP variable for future lookup.

Having said that, Zend_Cache is a very nice and easy to use system for caching data through abstracted backends. Page caching is only one of their frontends.