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

On Mon, 4 Feb 2008, Mark Nottingham wrote:

>
> 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?

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.

>
>
>
> 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/
>

Received on Tuesday, 5 February 2008 05:37:26 UTC