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