- From: Koen Holtman <koen@win.tue.nl>
- Date: Sat, 17 Feb 1996 18:19:11 +0100 (MET)
- To: sjk@amazon.com (Shel Kaphan)
- Cc: http-caching@pa.dec.com, state@xent.w3.org
Shel Kaphan: >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. I believe that under HTTP/1.0, if the 304 (Not Modified) response includes a Set-Cookie header, then caches must replace the old Set-Cookie header with the new one. Whether 1.0 proxy caches actually do this is another issue. I don't know. If they don't, this means trouble. >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. Yes, this is a potential problem. We have been through this issue of caches not complying to the Expires header definition before, and I would really like to avoid doing it again. The conclusion half a year ago was that 1) this would probably not prove to be a problem, because this practice is not very common (though figures on how many existing caches loosen the Expires rules are not known), that 2) the http-wg does not want to deal with this issue by putting warnings about the dangers of loosening in the spec documents, and that 3) the http-wg does not want to legalize loosening the rules on returning expired documents by adding an extra header to HTTP that allows caches to tell servers that they could loosen restrictions for any responses sent by the server. (I disagree with 2, but this seemed to be the general opinion.) > 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. Expires will control this. The problem is not inside HTTP 1.0, it is in whether proxy operators comply to the 1.0 definitions. If they don't, you can always use the bad old state-info-in-the-URL techniques. Another compatibility issue I have been thinking about: What if we define that Cache-Control always overrides Expires in 1.1, even if Expires gives a shorter lifetime? I believe this would be a good thing for backwards compatibility: the service author could use Expires to forbid caching by 1.0 caches if in cases where things are so subtle that only 1.1 caches can cache (parts of) the response. In the cookie case, we would get a response with the headers Expires: Thu, 01 Jan 1980 00:00:00 GMT Cache-control: no-cache="set-cookie"; max-age=100000 Set-Cookie: session-id=4314 >--Shel Koen.
Received on Saturday, 17 February 1996 17:39:41 UTC