cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: invalid caching problem
Date Sat, 17 May 2003 09:50:57 GMT

On Friday, May 16, 2003, at 11:57 PM, Gianugo Rabellino wrote:

> 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.

OK, never played with mod_expires

> 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).

Vadim has already -1'd this change, so it appears to be unpopular to 
allow this to be overridden

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

We are doing this asap.

>> 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...

That would be good. I have never seen a 304 on my site .....

>> 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?

It was a non-realistic test situation.
Yes, the G-T-S configuration was identical.
So no worries!

Thanks for your feedback.

regards Jeremy


Mime
View raw message