Re: Cookies and caching

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Wed, 24 Jan 2001 22:42:46 +0100

Have said this multiple times before: The statement is very much
outdated and predates any RFC's on the subject. The only place where the
specification looks like this is in Netscape's original document.

RFC2109 says that a origin server must use Cache-Control to mark the
header (or document) uncacheable.

   If the cookie is intended for use by a single user, the Set-cookie
   header should not be cached. A Set-cookie header that is intended to
   be shared by multiple users may be cached.

   The origin server should send the following additional HTTP/1.1
   response headers, depending on circumstances:

   * To suppress caching of the Set-Cookie header: Cache-control: no-
     cache="set-cookie".

   and one of the following:

   * To suppress caching of a private document in shared caches: Cache-
     control: private.

   * To allow caching of a document and require that it be validated
     before returning it to the client: Cache-control: must-revalidate.

   * To allow caching of a document, but to require that proxy caches
     (not user agent caches) validate it before returning it to the
     client: Cache-control: proxy-revalidate.

   * To allow caching of a document and request that it be validated
     before returning it to the client (by "pre-expiring" it):
     Cache-control: max-age=0. Not all caches will revalidate the
     document in every case.

   HTTP/1.1 servers must send Expires: old-date (where old-date is a
   date long in the past) on responses containing Set-Cookie response
   headers unless they know for certain (by out of band means) that
   there are no downsteam HTTP/1.0 proxies. HTTP/1.1 servers may send

and later on

   One reason for separating state information from both a URL and
   document content is to facilitate the scaling that caching permits.
   To support cookies, a caching proxy must obey these rules already in
   the HTTP specification:
[...]

   * Cache the Set-Cookie subject to the control of the usual header,
     Cache-control: no-cache="set-cookie". (The Set-Cookie header
     should usually not be cached.)

/Henrik

Duane Wessels wrote:
 
> 12.19 How does Squid deal with Cookies?
>
> The presence of Cookies headers in requests does not affect whether
> or not an HTTP reply can be cached. Similarly, the presense of
> Set-Cookie headers in replies does not affect whether the reply
> can be cached.
>
> The proper way to deal with Set-Cookie reply headers, according to
> RFC 2109 is to cache the whole object, EXCEPT the Set-Cookie header
> lines.
>
> With Squid-1.1, we can not filter out specific HTTP headers, so
> Squid-1.1 does not cache any response which contains a Set-Cookie
> header.
>
> With Squid-2, however, we can filter out specific HTTP headers.
> But instead of filtering them on the receiving-side, we filter them
> on the sending-side. Thus, Squid-2 does cache replies with Set-Cookie
> headers, but it filters out the Set-Cookie header itself for cache
> hits.
Received on Wed Jan 24 2001 - 15:29:56 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:25 MST