Does no-store in request imply no-cache?
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.
Re: Does no-store in request imply no-cache?
On Wed, Sep 22, 2010 at 8:27 PM, Alex Rousskov rouss...@measurement-factory.com 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. Hi, No; IMVHO it means that it can be stored in RAM, but not swapped out to a cache_dir. no-store = no-cache is a conservative (but valid) approximation. -- /kinkie
Re: Does no-store in request imply no-cache?
On 09/22/2010 02:46 PM, Kinkie wrote: On Wed, Sep 22, 2010 at 8:27 PM, Alex Rousskov rouss...@measurement-factory.com 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. Hi, No; IMVHO it means that it can be stored in RAM, but not swapped out to a cache_dir. Looks like my question was not clear. Let me try to rephrase: Assume Squid received a regular request and cached (does not matter where) the corresponding response. That request and that response had no Cache-Control headers. Everything is fine and ordinary. Now comes a second request for that cached object. The request has a Cache-Control: no-store header. Can Squid satisfy that no-store request from the cache? Thank you, Alex.
Re: Does no-store in request imply no-cache?
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. However, I imagine most people would interpret it as implying no-cache; you're still conformant if you do. 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
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 m...@yahoo-inc.com
Re: Does no-store in request imply no-cache?
On 23/09/2010, at 9:47 AM, Alex Rousskov wrote: 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. Sort of, but not really. I agree this could be worded better; we'll work on it. 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. Agreed. This has been discussed in the WG before (can't remember the ref); basically, it boiled down to each request being independent; you don't want requests affecting other ones (beyond anything, it's a security issue if you allow clients to purge your cache indescriminantly). -- Mark Nottingham m...@yahoo-inc.com
Re: Does no-store in request imply no-cache?
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
