W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: backward compatibility of non-cachable headers

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Thu, 15 Feb 1996 17:24:21 -0800
To: Shel Kaphan <sjk@amazon.com>
Cc: http-caching@pa.dec.com, state@xent.w3.org
Message-Id: <9602151724.aa24797@paris.ics.uci.edu>
> 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. 

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.

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

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.
Received on Friday, 16 February 1996 02:07:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC