Re: Does no-store in request imply no-cache?

On Wed, 22 Sep 2010 17:47:57 -0600, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 09/22/2010 05:05 PM, Mark Nottingham wrote:
>
>> Strictly, as a request directive it means "you can't store the
>> response to this request" -- it says nothing about whether or not you
>> can satisfy the request from a cache.
>
> Hi Mark,
>
> Let's assume the above is correct and Squid satisfied the no-store
> request from the cache. Should Squid purge the cached response
afterwards?
>
> If Squid does not purge, the next regular request will get the same
> cached response as the no-store request got, kind of violating the "MUST

> NOT store any response to it" no-store requirement.
>
> If Squid purges, it is kind of silly because earlier requests could have

> gotten the same "sensitive" information before the no-store request came

> and declared the already cached information "sensitive".
>
> Thank you,
>
> Alex.

I take it as meaning only that any new copy received must not be saved or
used to update/replace existing copies.

Assuming no-cache is updating the existing copy (removal).

client A, B, C in sequence with B using no-store fetch the same thing.
 client C would be getting same response as client A, no problem.
 client B could have used no-cache+no-store if it wanted new content not
shared with C.

Amos

>> See also:
>>
http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-11#section-3.2.1
>>
>>
>> On 23/09/2010, at 4:27 AM, Alex Rousskov wrote:
>>
>>> Hello,
>>>
>>> One interpretation of RFC 2616 allows the proxy to serve hits
when
>>> the request contains "Cache-Control: no-store". Do you think such an
>>> interpretation is valid?
>>>
>>> no-store
>>> The purpose of the no-store directive is to prevent the
>>> inadvertent release or retention of sensitive information (for
>>> example, on backup tapes). The no-store directive applies to
the
>>> entire message, and MAY be sent either in a response or in a
>>> request. If sent in a request, a cache MUST NOT store any part
of
>>> either this request or any response to it.
>>>
>>> Thank you,
>>>
>>> Alex.
>>
>> --
>> Mark Nottingham mnot_at_yahoo-inc.com
>>
Received on Thu Sep 23 2010 - 00:23:10 MDT