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

You are right -- I disagree with you.  For example, what are the known
headers for HTTP/1.1 for which this is true?  If you say anything other
than "I don't know", then you are wrong.  The reason is because there is
no standard for HTTP/1.1, and even a proposed standard changes.
We don't know yet, for instance, that "Cookie" and "Set-Cookie" will be
in the final standard.

Another reason for avoiding special exceptions is that Cache-Control
can be implemented in HTTP/1.0 right now -- there is no reason for
applications to wait.  Unlike some other features, this one does not
break anything in 1.0.  The same goes for proxies removing the Connection
header -- it is known to be unsafe for any existing proxy not to remove it.

Finally, making exceptions leads to non-interoperable implementations,
because programmers are poor exception handlers.

...

It is current practice.  I know that doesn't help much, but the fact
is that Cookies and HTTP/1.0 don't mix.

It is very important to me that HTTP remain as clean as possible in
terms of how it takes abstract requirements and translates them into
the syntax.  The reason for this is simple: we have been planning the
move to a binary, multiplexed protocol ever since October `94 (WWW2).
Part of that is an efficient encoding of HTTP/1.x syntax, and that
encoding is more efficient when there are fewer exceptions.

Note, however, that none of this prevents a cache from doing more than
the protocol requires to prevent uncachable data from being cached.


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

p.s. That reminds me of another thing.  I meant to remove the exception
     from the Public header, but forgot in the November rush.