cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: invalid caching problem
Date Sat, 17 May 2003 10:16:56 GMT

On Saturday, May 17, 2003, at 05:27 AM, Miles Elam wrote:

> Jeremy Quinn wrote:
>> 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)
> <snip />
>> 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?)
> I just poked around in the code and can't find where a problem would 
> occur (I don't have my dev server up right now so I can't check it 
> right away).  Are you sure that you are using a caching pipeline?

The default pipeline in my sitemap is:

<map:pipes default="caching">

> A non-caching pipeline will not send a timestamp for 
> non-readers...ever.  The timestamp is keyed to the cached object.  No 
> cached object == no last modified timestamp.  These are the relevant 
> functions to my knowledge:
> starting at line 461


> starting at line 214


> "validatePipeline" checks the expiration on the CachedResponse.  If 
> the resource hasn't expired, no subsequent CacheValidity checks are 
> made.  This is the primer for the "process" method.

Is it not true that 'expires' only exists on the cached object when the 
expiry parameter has been specified in the pipeline?

So under that circumstance, the browser is never going to return to the 
server during that period, to be given a 304?

> "checkIfModified" calls HttpEnvironment's "isResponseModified".  It is 
> the latter that sets the Last-Modified HTTP header.  As you can see, 
> the test for a reader happens in "process".  For dynamic (pipeline) 
> content, "checkIfModified" is called from within "processXMLPipeline" 
> if and only if there is a CachedResponse object handy.

I have never seen a 'Last-Modified' HTTP header being output by Cocoon 
on dynamic pipelines .....

> And this is where I am confused.  In your tests, the expiration is 
> affecting the freshness of the response.  This implies that you are in 
> a caching pipeline.

I believe so

> However, the lack of a last mod timestamp should only happen if you 
> are using a non-caching pipeline or if it's the very first access on 
> the resource.  (If there is no cached response, there can be no 
> timestamp associated with that response.)


> There are basically four behaviors for pipelines (I'm lumping Caching 
> and CachingPoint together here):

have not appreciated the difference between these two (Caching and 

> 1) Non-caching/non-expiring
>  - No CachedResponse object is generated
>  - Never sets a Last-Modified nor an Expires header
>  - Pipelines are always executed


> 2) Non-caching/expiring
>  - No CachedResponse object is generated
>  - Never sets a Last-Modified header
>  - Sets an Expires header
>  - Pipelines are always executed

never tried this combination

> 3) Caching/non-expiring
>  - CachedResponse object is generated
>  - Sets Last-Modified header on second and subsequent accesses.  
> (Needs a cached value to work)
>  - Never sets an Expires header
>  - Pipelines are only executed when CacheValidity checks fail

I see all of this happening, except for the Last-Modified header

> 4) Caching/expiring
>  - CachedResponse object is generated
>  - Sets an Expires header
>  - Sets Last-Modified header on second (and subsequent) accesses.
>  - Pipelines are only executed when both (a) resource expiry timeout 
> has elapsed and (b) CacheValidity checks fail

Again, I never saw the Last-Modified header, so even though pipelines 
are not executed on second and subsequent accesses, the data is always 
sent (ie. 200 Response).

> Someone correct me if I'm wrong as I'm learning as I go.  Anyone's 
> insights into this are more than welcome.

thanks for your feedback

regards Jeremy

View raw message