Re: "Cache-control: no-cache", "Cache-control: private", and , extensibility

On Mon, 19 Feb 1996, Shel Kaphan wrote:

> Jeff writes:
>  > confess that I am at a loss to think of an example where it
>  > is unacceptable to store a particular field of a response
>  > that is otherwise public, but perhaps I am simply being
>  > unimaginative.
>  > 
> 
> Set-cookie.

I guess I share Jeff's difficulty conjuring up a case where it
would be meaningful to cache a response w/o associated headers.

For example, if this response needed Set-cookie, why wouldn't every
other use of the same response also need some Set-cookie associated
with it? While I suspect I can write a scenario where a Set-cookie
would tag along with an arbitrary response where the resource might
be retrieved in another context w/o the need for the Set-cookie, my
sense is that this would be a non-real world fabricated situation.

Hence, perhaps we can ignore the case and make it all or nothing.
I would accept this as being a useful case, if there was a mechanism
for the cache/proxy to request verification of authorization to provide
the resource to a user and on the verification response, a new not to
be cached set-cookied would be included. But AFAIK this is a mode
of verification / validation not provided.

>  > any response to it."  If sent in a response, it means "do not store any
>  > part of either this response or the request that elicited it."
>  > This applies to both single-user and shared caches.  Caches should
>  > obey it but we explicitly caution against depending on it as a
>  > privacy mechanism.
>  > 
> 
> Sounds like it might be useful.

I agree .. this would I believe deal with the concern the Major Bank I 
mentioned in the F2F meeting had with caching of responses and even
presenting the response via the history mechanism.

Dave Morris

Received on Tuesday, 20 February 1996 08:30:01 UTC