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

Shel writes:
    In http 1.1, Roy has proposed some features for the new cache-control
    directive that allow servers to selectively disable caching on
    specific headers.  This would be, for example:
	    cache-control: no-cache="set-cookie"
    
    Roy may disagree with me on this (so take it with a grain of salt) but
    I see this as being primarily an extension mechanism, so that future
    revisions of the protocol that may introduce new, non-cachable headers can
    interoperate with older servers and clients and still control the
    caching of the headers.  That's fine, and seems like a smart move.

Actually, although Roy disagrees with you about special exceptions,
Roy *does* see this as an extension mechanism, or at least he did
a few weeks ago when he sent this:
    The [private] directive allows these semantics to be described in
    HTTP without pre-knowledge of the names of the header fields, and
    thus provides for extensibility in ways that are not possible with
    HTTP/1.0.

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.

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?

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?

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.

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.

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

I admit that this doesn't allow the origin server to say "you
can treat most of this response as public, but you cannot even
store this header", but as I said, I can't think of a compelling
example to motivate that.

-Jeff

Received on Tuesday, 20 February 1996 00:03:49 UTC