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

I don't see it as orthogonal ... no-store means no-store ... my reading
is still that it can't be satisfied from the cache (i'm assuming that
the cache entry was stored as the result of a request w/o no-store).

If you can't cache the result, you can't use the cache to provide the
result. It may be that the data being protected is the association
between this request and the response. Or what ever. I think the
cache should be ignored for a no-store request and of course if the
no-store first appears on the response, the new response would not
be cached, even if it would logically invalidate existing content.

On Mon, 18 Oct 2010, Mark Nottingham wrote:

> Right, but that's largely orthogonal to the question below; whether
> no-store in a request implies that a previously stored response needs to
> be invalidated.
> 
> Cheers,
> 
> 
> On 18/10/2010, at 11:05 AM, David Morris wrote:
> 
> > 
> > I interpret NOSTORE as a stricter restriction than NOCACHE.
> > If it can't be stored, it can't be used in a subsequent
> > response.
> > 
> > If I recall the discussion from 10 years ago correctly, the
> > intent was to reduce the posibility that private information
> > could leak via even temporary storage.
> > 
> > Dave Morris
> > 
> > On Mon, 18 Oct 2010, Mark Nottingham wrote:
> > 
> >> Thoughts re: the below?
> >> 
> >> My inclination is to clarify "any response to it" so that a cache can
> >> use the same cached response to serve multiple requests with no-store in
> >> them (or not).
> >> 
> >> Cheers,
> >> 
> >> 
> >> Begin forwarded message:
> >> 
> >>> From: Alex Rousskov <rousskov@measurement-factory.com>
> >>> Date: 23 September 2010 9:47:57 AM AEST
> >>> To: Mark Nottingham <mnot@yahoo-inc.com>
> >>> Cc: Squid Developers <squid-dev@squid-cache.org>
> >>> Subject: Re: Does no-store in request imply no-cache?
> >>> 
> >>> 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.
> >>> 
> >>> 
> >>>> 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   http://www.mnot.net/
> >> 
> >> 
> >> 
> >> 
> > 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
>

Received on Monday, 18 October 2010 00:22:41 UTC