cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject Re: [RT]Cache/proxy friendly HTTP headers
Date Fri, 11 Jan 2002 14:38:21 GMT
Carsten Ziegeler wrote:

>>
>>What I'm thinking about is a sort of mod_expires functionality clone:
> 
> In fact this is something which can speed up cocoon.
> 
> Now this proposal has something to do with caching. We already have the
> pipeline components: the stream pipeline and the event pipeline which
> can be configured to cache or to not cache.
> 
[...]

> So, one possibility to achieve the thing you propose is configuring the
> expires also in the cocoon.xconf, for example:
> <pipelines>
>   <pipeline name="caching-and-expires-after-1-day">
>     <stream-pipeline src="CachingStreamPipeline">
>       <expires after="1 day"/>
>     </stream-pipeline>
>     <event-pipeline src="CachingEventPipeline"/>
>   </pipeline>
> </pipelines>
> 
> This would of course end up in a configuration nightmare. Another
> possibility would be to make such a stream pipeline configurable in
> the pipelines section of the sitemap:
> 
> <map:pipeline name="caching">
>    <map:parameter name="expires" value="after 1 day"/>
> 
>    ....
> </map:pipeline>


> What do think about this?


I like the idea of driving expires through the cache: this is the most 
flexible approach, but we need to come up with a flexible, robust and 
user-friendly syntax. First of all I think that we should decide where 
and how we want users to specify (and maybe override) caching and 
expires headers.

But first let's see if we all agree on this: caching and expires are a 
bit different. Caching is there to check if a resource *has changed* and 
act accordingly. Expires headers are there to *state* if and how a 
resource *will change* so in the end they might drive (override) the 
cache itself. See the difference? So we can say that, if an expires 
directive is present the cache should honor it: if it's not yet expired 
then the cache should avoid even checking the resources and send right 
away the final result, together with an appropriate Expires header. This 
way we have two speed improvements:

1. with reverse proxies and/or good browsers a *lot* few hits on the 
Cocoon webapp;

2. with dumb clients that don't honor Expires headers we will serve 
content right from the cache, without even checking resources.

Makes sense? Also, I don't know much about the internal cache design and 
implementation: would this be hard to implement?

Ciao,

-- 
Gianugo Rabellino




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message