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

Re: backward compatibility of non-cachable headers

From: Shel Kaphan <sjk@amazon.com>
Date: Sat, 17 Feb 1996 09:34:17 -0800
Message-Id: <199602171734.JAA13665@bert.amazon.com>
To: koen@win.tue.nl (Koen Holtman)
Cc: http-caching@pa.dec.com, state@xent.w3.org
Koen Holtman writes:
 > Shel Kaphan:
 > >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.  

I agree -- that's not the focus of my comment.  I just wanted to point
out that given the reality of that situation, there's an unsolved security
problem with cookies.   (Lou, is Netscape still paying a bounty to
people who notice security problems?)  

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

Stay tuned.  At the meeting of the caching subgroup there was a good
deal of interest in this, but not in general, just for specified resources.

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

Expires won't do the right thing if the origin server ever fails to
return a set-cookie header in a 304 response, because if there was a
set-cookie header cached from before, it would be returned to the 
next requestor.

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

I think you need the expires even in 1.1, so that future
requests for this resource will be passed through to the origin, where
they can get a new cookie.

Received on Saturday, 17 February 1996 17:57:08 UTC

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