On Wed, 22 Sep 2010 17:47:57 -0600, Alex Rousskov <rouss...@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 m...@yahoo-inc.com >>
