cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject Re: invalid caching problem
Date Fri, 16 May 2003 22:57:18 GMT
Jeremy Quinn wrote:

>> You're definitely right: the idea of expires is instructing on one 
>> side browsers and (reverse) proxies not to request resources in a 
>> given timeframe *AND* Cocoon to explicitely ignore the cache 
>> validation process and consider an entry fresh as long as the 
>> specified time has not expired.
> 
> OK, this is happening
> See below:
> 
>> This is a feature then, but it could well be implemented in a bugged 
>> way :-), and I take full responsabilty for that. However, the code is 
>> a no brainer: given the cache key, the cache entry is looked up and 
>> its configured expires evauated against the current time, so as long 
>> as the cache key doesn't change there will be no checks.
> 
> 
> Which currently prevents a forced-reload from the client

Pretty much on purpose, just like httpd mod_expires does. It would be 
pretty easy, actually, to spot a forced reload, which is triggered by a 
"Cache-Control: max-age=0" header, but I'm not sure that it makes really 
sense: the whole idea is letting the user specify an override (like "I 
know better than the caching algorithm or the browser when this resource 
has to be refreshed") over both caching algos and browser requests. But 
yes, it might make sense to add this too (even if for 99% of request 
this would turn out into unnecessary parsing of HTTP headers).

My suggestion, however, is to use expires only on production, as part of 
the release cycle optimization.

> I notice several things here:
> 
> 1) There are never any 'date' headers in the Response, so you never get 
> a 'conditional-GET' from the Browser and consequentially never send a 
> 304 response, meaning we always send the page. (This just isn't 
> implemented yet, right?)

Yes, probably it might be the case to consider merging the lates 304 
patch from Miles with the expires code. Something to work on...

> 2) You cannot force-reload during the expiry period of an expiring 
> Pipeline.

Again, on purpose. :-) But this can be changed.

> Incidentally, when I had two separate Pipelines (one expiring, one 
> non-expiring) and they both used the same source, the non-expiring 
> Pipeline would pick up the expires parameter from the expiring Pipeline 
> (once it was cached).
> 
> This was very strange =:}

This is actually worrisome and shouldn't happen: first thing that comes 
to my mind is that those pipelines actually generate the same caching 
key, which IIUC should happen only if the two pipelines are identical in 
the G-T-S configuration. Can you send the relevant pipelines so that I 
can try it on my setup?

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com


Mime
View raw message