Zend_Cache_Frontend_Page - FAIL
Posted by on the 6th April 2008 @ 3:14pm
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.
0 comments
Andy Thompson
19th April 2008 @ 10:53pm
I've posted a bug report on Zend's Issue Tracker.
http://framework.zend.com/issues/browse/ZF-376
We've come up with a workaround which will allow the developer to cancel the cache functions. This can be run as:
header('Location: /page.html');
$cache->cancel();
exit;