backward compatibility of non-cachable headers

Something that worries me came up as a byproduct of a discussion
between Roy and me in the state subgroup.  Maybe, hopefully, I'm wrong.


Some background:

The set-cookie header is inherently not cachable.  It wouldn't make
sense, and wouldn't be secure.  The storage and management of cookies
in user agents is something other than caching per se.

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.

However, it is possible to pre-define the known headers in 1.1 as to
whether they are cachable or not.  So there's some question about
whether this mechanism ought to be used to control the known headers
at the time the extensions mechanism is introduced. 
In any case, that's all just background...


The problem:

The problem that I became aware of as a result of talking about this
is that older caches might cache non-cachable headers such as
set-cookie.  Caches can store documents that are "pre-expired", and
return those documents after doing a conditional GET to validate them.
If a cache operator has loosened the rules on returning expired
documents (which I am given to understand does sometimes happen), and
if the cache has stored a document with associated set-cookie headers,
then there could be a real security issue -- people could get other
people's cookies.  There is to the best of my knowledge nothing in 1.0
equivalent to ``cache-control: no-cache="set-cookie"'' that
would let servers control this.

Is this a real problem, or have I missed something?

--Shel

Received on Thursday, 15 February 1996 23:05:59 UTC