Re: backward compatibility of non-cachable headers

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.

--Shel

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