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

> It's too bad that the draft spec doesn't mention extensibility, but
> we seem to at least agree that extensibility is important.  I think
> the spec should mention extensibility here.

Ummm, yes, but I usually take that for granted since it is one
of the most important design principles behind all of HTTP.
In other words, any design which is not extensible should not
be introduced to the protocol.  I can't undo some of the random hacks
of the past, but at least I can try to make the future better.

> We need to clarify some other things, too.
> 
> Here are two paragraphs from draft-ietf-http-v11-spec-01.txt
>     
>    The "private" directive indicates that parts of the response 
>    message are intended for a single user and must not be cached 
>    except within a private (non-shared) cache controlled by the user 
>    agent. If no list of field names is given, then the entire message 
>    is private; otherwise, only the information within the header 
>    fields identified by the list of names is private and the remainder 
>    of the message is believed to be cachable by any application. This 
>    allows an origin server to state that the specified parts of the 
>    message are intended for only one user and are not a valid response 
>    for requests by other agents. The "private" directive is only 
>    applicable to responses and must not be generated by clients.
> 
> and
> 
>    The "no-cache" directive on a response message indicates that parts 
>    of the message must never be cached. If no list of field names is 
>    given, then the entire message must not be cached; otherwise, only 
>    the information within the header fields identified by the list of 
>    names must not be cached and the remainder of the message is 
>    believed to be cachable. This allows an origin server to state that 
>    the specified parts of the message are intended for only one 
>    recipient and must not be stored unless the user explicitly 
>    requests it through a separate action.
> 
> I've been staring at these for a while, trying to figure out what
> they mean (and in particular, why they are both there).  I.e.,
> under "private" one finds:
> 
>    This allows an origin server to state that the specified parts of
>    the message are intended for only one user ...
> 
> while under "no-cache" one finds:
> 
>    This allows an origin server to state that the specified parts of
>    the message are intended for only one recipient
> 
> Roy, does "recipient" mean the same thing as "user", and if not,
> what do they each mean?

Well, it should probably be user in both places, since there are
multiple recipients in a response chain.

> I'm also confused about what this means:
>    the specified parts of the message [...] must not be stored unless
>    the user explicitly requests it through a separate action.
> 
> Which user requests it?  When?  How?

The user agent's user via a Save As... dialog.

> Anyway, it seems like the main difference between "private"
> and "no-cache" is that "private" allows caching in a user agent's
> single-user cache, whereas "no-cache" does not.

Yep.  We discussed this on the WG mailing list last summer -- Lou
needed a directive to prevent the user agent from using its own cache,
and yet most authenticated data can be cached privately but not
publically.

> I can't tell if Roy intended a distinction between "private" and
> "no-cache" responses in that private means "OK to store" and
> no-cache means "not OK to store", or whether that was just a
> different expression of the same thing.

Private means (essentially) OK to store, and no-cache means its
not OK to store within a cache [but without disabling Save As...].
I added the extra wording to prevent people confusing it with a weak
security measure.

> If this is indeed what Roy intended, then the added constraint
> implied by "no-cache" seems to be a security/privacy mechanism,
> and a relatively weak one at that (it protects against someone
> breaking into the cache, but not against eavesdropping.)  I

Ummm, I guess the addition didn't help.  :)

> 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.
>
> So how about this proposal:
> 
> (1) "Cache-control: private" remains as in Roy's draft, but with
> a mention of extensibility explicitly included.  Single-user-agent caches
> are effectively allowed to ignore this directive.
> 
> (2) "Cache-control: no-cache" is defined to mean exactly the same
> thing as "Cache-control: private", but with no exception for
> user-agent caches.
> 
> (3) We add "Cache-control: no-store", which applies to the entire
> message and may be sent either in a response or in a request.  If sent
> in a request, it means "do not store any part of either this request or
> 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.

Given the possibility of eavesdropping, that isn't useful.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 20 February 1996 19:55:55 UTC