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 14:12:15 GMT

On Friday, May 16, 2003, at 01:00 PM, Carsten Ziegeler wrote:

> Hi Jeremy,

Thanks for your response, Carsten.

>> On Thursday, May 15, 2003, at 09:39 PM, Jeremy Quinn wrote:
>>
>>>
>>> On Thursday, May 15, 2003, at 04:40 PM, Vadim Gritsenko wrote:
>>>
>>>> Jeremy Quinn wrote:
>>>>> If I put this in my pipeline (to reduce server load):
>>>>>
>>>>>     <map:parameter name="expires" value="access plus 120 minutes"/>
>>>>>
>>>>> then whenever:
>>>>>
>>>>>     1) the content has changed
>>>>>     2) I hit reload and the server sends a full 200 response
>>>>>
>>>>> changes in the source used by the file generator are ignored.
>>>>>
>>>>> If I remove that statement and trash the cache, no problem occurs.
>>
>> <snip/>
>>
>>>> I doubt that FileGenerator is resposible for this bug. Look into
>>>> caching pipeline implementation.
>>
>>> I looked into
>>> o.a.c.components.pipeline.impl.AbstractCachingProcessingPipeline.
>>
>> I am beginning to think that the behaviour of the 'expires' handling 
>> in
>> this class is not quite right.
>>
>> My understanding of the dynamics of HTTP Request/Response messages is
>> not good enough to be sure though, can anyone put me right here?
>>
>> What appears to happen in the code is that IF there is an 'expires'
>> parameter set on a Pipeline, then it will NEVER refresh, regardless of
>> the validity-state of the initial generated source.
>>
>> Why?
>>
>> Because the code compares the current-time to the current-time PLUS 
>> the
>> time-clause in the Pipeline's 'expires' parameter, which will ALWAYS 
>> be
>> in the future (in my case, +2 hours).
>>
>> Is this the intended behaviour?
>>
>> It was my understanding that the Pipeline's 'expires' parameter was
>> intended to be an instruction to the Browser to cache the page
>> internally for that period of time and not bother to go back to the
>> Server during that period.
>>
>> What fails here is when the user explicitly tells the Browser to
>> Reload, because they intend to override any internal caching.
>>
>> I am not sure under what circumstances a Browser sends 'freshness' 
>> data
>> to the Server in it's request header, but it seems to me that the
>> Pipeline should be comparing data from the Request with the
>> current-time, not the Response (which in this case is static).
>>
>> 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?

My belief was that it permanently disables it.

On closer examination, I am not so sure now ....

Whereas I though the current time was being compared to the Response 
Object, now I think it is actually being compared to the response 
retrieved from the Cache.

So, you are right, it is only disabled for the time period specified in 
the Pipeline expire.

> I think the first one would be a bug and the second one would be the
> intended behaviour (though I'm not sure).

Yes, it appears to be intended behaviour.
But is it the desired one? :)
WRT disallowing the use of Browser Reload as an override?

But I do not know if there is a way to tell the difference between the 
following Requests:

   Forced-Reload of Browser-cached page
   First-time visit to a page
   Poorly implemented Browser not sending the right caching headers

> You mention a wrong comparison above, can you please give the line
> number?

I was wrong, I think.

retrieve response: 476
retrieve expires:  492
comparison:        500

Sorry if I am wasting your time.

regards Jeremy


Mime
View raw message