W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 2000

Re: Cache-Control

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 14 Aug 2000 11:24:18 -0700
Message-Id: <200008141824.LAA01504@wera.pa.dec.com>
To: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
Cc: <http-wg@cuckoo.hpl.hp.com>
   My question is what should a proxy/user-agent do if it receives
   the request:

	cache-control: private, public, max-age=180, s-maxage=120

I'm going to assume that the word "request" in your email is
a mistake, and that you meant "response".  Three of the four
directives you listed are undefined for requests.  With
that in mind:

The answer is different for a (shared) proxy and for a (non-shared)
user-agent.

A user-agent (presumably with a "non-shared cache") should
ignore the "private" and "s-maxage" directives, and so
this is equivalent *FOR A NON-SHARED CACHE* to

	Cache-Control: max-age=180

A shared proxy cache, on the other hand, has no sensible
way to interpret this header field, because RFC2616 says:

   public
      Indicates that the response MAY be cached by any cache, even if it
      would normally be non-cacheable or cacheable only within a non-
      shared cache. (See also Authorization, section 14.8, for
      additional details.)

   private
      Indicates that all or part of the response message is intended for
      a single user and MUST NOT be cached by a shared cache. This
      allows an origin server to state that the specified parts of the
      response are intended for only one user and are not a valid
      response for requests by other users. A private (non-shared) cache
      MAY cache the response.

Given that the "private" directive in your example does NOT list
any specific parts of the response, it therefore must refer to
the entire response.  But this means that the "public" and
"private" directives are conflicting, and so the server that
sent the response has a bug.

As a general rule, I would recommend that if a received
response appears to be buggy, it is stupid to cache it.
(Another way to look at this: if the server implementor
appears to have misunderstood the HTTP caching specification,
then a cache implementor ought to protect the user from
that implementor's mistake.)  Don't cache responses if
they cannot unambiguously be cached with "semantic transparency"
(see RFC2616).

-Jeff
Received on Monday, 14 August 2000 19:26:07 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:38 EDT