Subject: Re: does no-store request invalidate? [i23]

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Feb 2008 18:35:27 -0800

I think I agree, but the question still remains -- does this need to  
be clarified in the text?

My .02 - I think the text is pretty clear already (but not explicit).  
If we could find a low-impact way to make it more obvious that would  
be great; I'd be more wary of adding too much text, though, on the  
grounds that Jeff mentioned; if we start explaining how every possible  
combination of protocol elements acts, it becomes difficult to stop.

E.g., would it help to change

> If sent in a request, a cache MUST NOT store any part of either this  
> request or any response to it.

to

> If sent in a request, a cache MUST NOT store any part of the  
> associated response.

?

What does it may to store any part of the request, anyway?

On 28/10/2007, at 6:35 PM, Henrik Nordstrom wrote:

> IIRC this was discussed before and the conclusion was in itself no- 
> store
> do not invalidate. There may be other aspects of the response which
> invalidate the cache entry, i.e. a new ETag being returned or
> non-indempotent method being used.
>
> Regards
> Henrik
>
> On fre, 2007-10-26 at 22:05 +0200, Werner Baumann wrote:
>> Scenario:
>> A caching proxy that serves not one, but many clients (the most  
>> common
>> case).
>>
>> Case a)
>> 1. Client X requests resource A.
>> 2. The proxy gets resource A from the server, stores it in the  
>> cache and
>> delivers it to client X.
>> 3. Some time later client Y requests resource A. The proxy checks
>> whether the cached entity is up-to-date and serves the cached entity.
>> Let's assume the proxy checked well and the entity is up-to-date.
>>
>> Case b)
>> The same case with client Z, which likes "no-store".
>> 1. Client X requests resource A.
>> 2. The proxy gets resource A from the server, stores it in the  
>> cache and
>> delivers it to client X.
>> 3. Client Z requests resource A with "no-store". The proxy serves  
>> this
>> request and does *not* change the cached entity A, nor any of the
>> meta-data about resource A.
>> 4. Some time later client Y requests resource A.
>> What do do?
>>
>> Either the cached resource A is Schrödinger's Cat, or the proxy may
>> serve the cached entity just like in case a, and the cached entity is
>> valid. After all, the cached entity in case a and case b are  
>> exactly the
>> same.
>>
>> If a client does a request with the "no-store"-directive, this  
>> request
>> and the response are out of the scope of caching, and MUST NOT  
>> influence
>> the cache in any way.
>>
>> On the other hand, if the proxy would delete the cached entity, the
>> danger of a denial of service attack is real. This must not be by
>> intention. Anybody may write some HTTP-Client, and may by mistake  
>> think
>> it a good idea, to use the "no-store"-directive.
>>
>> Werner

--
Mark Nottingham     http://www.mnot.net/

---

From: David Morris <[email-masked]>
Date: Mon, 4 Feb 2008 21:37:10 -0800 (PST)

> What does it may to store any part of the request, anyway?

Doesn't matter what it might mean, if a cache is foolish enough to store
part of the request, it could be an opportunity to compromise sensitive
information.

The original wording is explicit and should remain because the change
allows the request to be stored in a cache.

I don't have the bandwidth at the moment to check, but the same should be
true if the response contains do not cache ... neither the request nor the
response may be cached.

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 05 Feb 2008 15:08:34 +0100

> true if the response contains do not cache ... neither the request nor the

It's not. no-cache still allows caches to store the response/request.

Response directive no-cache is pretty much the same as max-age=0,
must-revalidate.

Request directive no-cache just says that a cache may not be used to
satisfy this request. It says nothing about how the response is to be
handled. Wording is a bit dim on this in the definition of no-cache
where only the response directive semantics is considered, but is
clarified later on in "Cache Revalidation and Reload Controls"

no-store on the other hand says that neither the request ot it's
response may be permanently stored in a cache, or that the cache should
at least make best effort to permanently erase any data carried in the
request and response as soon as possible after completion. no-store is
explicitly not limited to responses as also the request may carry
sensitive information, i.e. as part of a PUT/POST request. But it gets a
little wierd talking about caches in this context. What is really meant
all processing agents (not just caches) MUST NOT permanently store the
carried request or response entity, not limited to just caches.. But
there is no good term for this so "cache" is used as the closest
matching term.

Storing of the request may occur as part of request forwarding. Quite
noticeably if for example scanning PUT request for viruses. This isn't
really a cache, but the no-store directive still applies. There is also
a request history cache in most user-agents where the directive should
apply.

It's somewhat unclear to me if a no-store request directive also implies
no-cache, or if the request may still be satisfied with a priorly cached
entity. But I guess from the description of no-store that it may still
be satisfied by a cached entity unless combined with no-cache as it only
talks about storing information from this request/response for
security/privacy reasons, not how the request may be satisfied.

Regards
Henrik