jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Cache-Control: no-cache and no-store
Date Mon, 09 Jul 2012 15:29:39 GMT
On 9 July 2012 06:45, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> Hello Sebb,
> I understand no-store differently,
> For me it means do not store on disk but you CAN store it on volatile
> storage, so in our case, we should store it in cache.

Possibly.

> For me current implémentation is correct

Not sure we are correct now.
We no longer store responses at all for "no-cache".
This means they cannot be revalidated.

AIUI, if the revalidate says that the no-cache response is still up to
date, a browser can use it.
However the browser must not use the cached entry without checking
first; in other words, it should ignore the expires date.

So I think the check for no-cache should be done as part of the
useExpires conditional (as originally proposed by Philippe, and
wrongly rejected by me). If no-cache is present, store null in the
expires field; this will stop the entry from being directly returned.

> as we say That we don't interpret
> other attributes for example must-revalidate.

That was for simplicity in the initial implementation.
We could do so later.

> Regards
> Philippe
>
> On Monday, July 9, 2012, sebb wrote:
>
>> I misunderstood how the "no-cache" attribute is supposed to work.
>>
>> According to
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
>>
>> the browser CAN store responses marked as "no-cache", however the
>> browser MUST revalidate the response.
>> Without the attribute, then the entry can be re-used without
>> revalidation provided that it has not expired.
>>
>> The "no-store" attribute is the one that is intended to prevent
>> storage of the response in cache.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message