Jonathan wrote:
Been brainstorming a little while about modifying HTTP requests combined with a high speed cache in front of a dynamic source of data, such as Zope.
Idea: Put a proxying cache with content negotiation, rewriting of requests etc. in front of Zope. First time a page is requested (client requests it from the proxy which knows where to get it because it's configuration files tell it how to handle a request) it is cached. The next request is served directly from the cache. As soon as a page changes it is fetched from Zope and cached again.
The problem is: what is a page? For instance, if you got to http://www.zope.org/, you'll get a different page than me. Why? Because my page is personalized. However, the HTTP header Etags could help by giving each version of a page a unique id.
It would also allow you to use any mix of static and dynamic content, because pages that stay the same are served directly from the cache and Zope is never hit to serve that page. Allows to use Zope as a content management tool too.
The win these days is in smarter caching which is more finely-grained than at the page level.
So what's your view? I know that a request can be modified behind the scenes based on the data the client supplies - request, filetype, language, browser type, IP address etc. It's also possible to cache the files requested, but I am not sure how the cache would communicate with Zope and vice versa.
The HTTP protocol offers some hooks to cache a file for a limited time only if I am not mistaken, but the ideal solution in my view would be a button in Zope called 'Publish' which would send a message to the cache resulting in the removal of that particular page...
I _think_ that Squid has a protocol like this to allow caches to send messages to each other. --Paul