cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [VOTE] Adding "Expires" headers to pipelines
Date Mon, 27 May 2002 07:28:04 GMT
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... :-)).


Gianugo Rabellino

To unsubscribe, e-mail:
For additional commands, email:

View raw message