cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT]Cache/proxy friendly HTTP headers
Date Mon, 14 Jan 2002 15:33:20 GMT

Gianugo Rabellino wrote:
> 
> 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?
> 

Ok, yes, caching and expires a different things. You can set expires
without caching anything. So a NonCachingPipeline can also set an expires
date.

The second thing you propose that - if a caching pipeline is used - the
cache itself takes the expires date given in the sitemap to validate
the cached content, should be very easy to implement. I guess that
this would come to four lines java code. Sounds this easy enough? :)

Carsten


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

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


Mime
View raw message