Re: backward compatibility of non-cachable headers

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