Accelerated HTTP Caching Manager doesn't work out-of-the-box as this thread reported, but the thread had no conclusion: http://mail.zope.org/pipermail/zope/2003-April/134800.html http://mail.zope.org/pipermail/zope/2003-April/135059.html http://mail.zope.org/pipermail/zope/2003-April/135101.html I'm running into the same problem now, also with Apache as the caching reverse proxy, so I was wondering if there was any progress? Here are some of my thoughts; It seems reasonable that without a Last-Modified or Etag header in the response, that a client (and surrogate/ http accelerator) will not have any validators (e.g., If-Modified-Since or If-Match corresponding to last modified and etag headers, respectively) in the request headers. It's probably right that dynamic code doesn't return a Last-Modified header; instead, the RFC includes an Etag header, which is hash of the content, which is much easier to use for dynamic code. The Etag header returned by Zope, however, looks very suspicous; it is empty. This could perhaps be fooling the caching machinery? Perhaps the Etag header should just always be a hash of the content? (Another system worth looking at: http://www.jpcache.com/) Bye, -- Bjorn