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 Fri, 16 May 2003 18:41:45 GMT

On Friday, May 16, 2003, at 01:14 PM, Gianugo Rabellino wrote:

> Carsten Ziegeler wrote:
>>>
>>> SUMMARY:
>>>
>>> Using <map:parameter name="expires" value="access plus 120 
>>> minutes"/> in a Pipeline, permanently disables validity checking on 
>>> that Pipeline.
>>>
>> does ir really permanently disables the checking or does it only 
>> disable
>> the checking for 120 minutes after the first access?
>> I think the first one would be a bug and the second one would be the
>> intended behaviour (though I'm not sure).
>
> 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

> Given that this behaviour is exposed only with FileGenerator (i.e. 
> changing an XSLT works as Jeremy want - which is BTW not the correct 
> intended behaviour: the idea is that the pipeline should be the same), 
> I'm wondering whether changing the XSLT timestamp changes also the 
> transformer key, hence changing the overall key value so that the 
> cached entry is not found anymore and no expires value is found.

not sure about that yet ....

> I have little time today to investigate on the code, but I'll do my 
> best to track this down and help you out.


I did a set of tests (below) to see the different HTTP Request and 
Response headers, when using expiring and non-expiring Pipelines.

Tests: (just request/response & cache-relevant headers)

non expiring pipeline:

   hit link when not seen:
	
     REQUEST GET /test
	
     RESPONSE 200
		
   hit link after seen:
	
     REQUEST: GET /test
	
     RESPONSE: 200
	
   hit link after change:
	
     REQUEST: GET /test
	
     RESPONSE: 200
	change seen
	
   reload after change:
	
     REQUEST: GET /test
     Cache-Control: max-age=0

     RESPONSE: 200
	change seen

expiring pipeline:

   hit link when not seen:
	
     REQUEST: GET /index
	
     RESPONSE: 200
     Expires: Fri, 16 May 2003 19:55:29 GMT
     Cache-Control: max-age=7200, public
	
   hit link after seen:
	
     REQUEST GET /index

     does not hit server
			
   hit link after change:
	
     REQUEST: GET /test
	
     does not hit server
     change not seen

   reload after change:
	
     REQUEST GET /index
     Cache-Control: max-age=0

     RESPONSE: 200
     change not seen


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

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

3) When _Mozilla_ does a Reload, it sends a "Cache-Control: max-age=0" 
header. I do not know how standard this is and/or if it should be used 
to modify Cocoon's caching behaviour.


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 =:}


Thanks for your help

regards Jeremy


Mime
View raw message