- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 3 Feb 2011 16:46:45 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Alex Rousskov <rousskov@measurement-factory.com>
Current text: """ no-store The no-store response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. """ Proposal: """ no-store The no-store response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. Note that if a request containing this directive is satisfied from a cache, it does not apply to the already stored response. """ On 18/10/2010, at 3:07 PM, Mark Nottingham wrote: > Now #249: > http://trac.tools.ietf.org/wg/httpbis/trac/ticket/249 > > > On 18/10/2010, at 10:53 AM, 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/ > > > > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 3 February 2011 05:47:17 UTC