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