Ivelin Ivanov wrote: >>The point is what you think "dynamic pages" are. I see two scenarios: >> >>1. real dynamic pages, e.g. built with request parameters, and changing >>everytime. In this case the Expires should never be set; > > I will try to give a few examples, hoping they sound adequate to you: > > a) Site search. Search results are not likely to change at least until the > content changes. > If the URL (for GET) or the POST parameters is the same then why bother the > search engine? > The probability of repetitive key phrases on a site is probably not > negligible, considering that either:
OK. I'm with you here. AFAIK, however, no proxy is going to cache a content requested with POST, so this might work only for GETs. > b) Authentication. Sophisticated app servers implement caching algorithms > which > - do not allow subsequent authentication requests with invalid credentials > for a certain period of time > - do not perform subsequent db round trips for valid authentication for a > certain period of time. This scares me a bit on the security side. Also, I don't think (and I sure expect) that proxies will cache 4xx responses. > c) Varios applications have heavy dynamic pages which render significant > amount of data squashing db, wire and CPU. Examples are reports, charts, > etc. This is the perfect scenario for this solution, and exactly what I had in mind: this content is perfectly cacheable, so it makes sense to use a proxy in front of Cocoon. Now, the more I think of it, the more I see how having a configuration setting that tells the *internal* caching system a way to override resources given Validity might help a lot in many situations (including your a) and b) points). I'm way too much behind in catching up with Cocoon internals to mess with the internal cache stuff (and way too short in time), however, since I made this configuration setting available in the ObjectModel, it should be fairly easy to modify the cache so that it takes into account this value, giving up (hence saving time) checking each resource Validity before deciding how to serve the page (from cache or rebuilding it). Maybe someone can volunteer, I remember Carsten labeling this change as minor and trivial (hint, hint... :-)). Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
