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

Jeff writes:
 > Shel writes:
	...
 > 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:

And, for the record, I buy his arguments for why we should do it the
way he suggests, enough not to object.  I do want to remind people
then, that set-cookie, if it gets into the spec, will have to be
accompanied by cache-control: no-cache="set-cookie".  (NOT
private="set-cookie") (BTW, Roy, what's with the double quotes there?)

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

You asked Roy, but I'll also comment: possibly this language needs a
little adjustment, but it is clear what the difference between
"no-cache" and "private" should be.  No-cache means the response
should never be stored in *any* cache, even the end-user's.  This also
*implies* that the response is only useful for one user/recipient.  The
particular response may never be served by any cache, period, so if
the same user asks again for this resource, even that user's private
cache can't give them the "no-cache" document.  Private means that the
result is only appropriate to a particular user.  But it may be useful
to cache it locally for that one user, so when that user asks for the
document again, the cache can give it to them without going to the
next server.

 > 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.
 > 
That's certainly how I understood it.

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

That's not how I see it.  I see "private" as offering certain kinds of
applications the opportunity to have pages cached even when those
pages are not for public consumption.  True, the great benefit of
caching is in public, shared caches, but from the individual user's
point of view, caching locally can make an application faster.
"No-cache" is for situations when the origin server knows that it is
pointless to cache a document, since a new request for it would yield
a different result.

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

Set-cookie.


 > 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.
 > 
Right - it's the intermediate proxies that have to pay attention to it!

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

I think that's how it is now, and agree it should stay that way,
although that seems like a somewhat convoluted way to say it.


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

Sounds like it might be useful.
	...

--Shel

Received on Tuesday, 20 February 1996 03:42:22 UTC