Re: HTTP/1.1 Issue: max-age in responses not defined

After some good comments from Jeff, I am changing my proposed change.

The first three paragraphs of section 14.9.3 of RFC 2068:

   The expiration time of an entity may be specified by the origin
   server using the Expires header (see section 14.21). Alternatively,
   it may be specified using the max-age directive in a response.

   If a response includes both an Expires header and a max-age
   directive, the max-age directive overrides the Expires header, even
   if the Expires header is more restrictive. This rule allows an origin
   server to provide, for a given response, a longer expiration time to
   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
   useful if certain HTTP/1.0 caches improperly calculate ages or
   expiration times, perhaps due to desynchronized clocks.

     Note: most older caches, not compliant with this specification, do
     not implement any Cache-Control directives.  An origin server
     wishing to use a Cache-Control directive that restricts, but does
     not prevent, caching by an HTTP/1.1-compliant cache may exploit the
     requirement that the max-age directive overrides the Expires
     header, and the fact that non-HTTP/1.1-compliant caches do not
     observe the max-age directive.

should be replaced with

   The expiration time of an entity may be specified by the origin server
   using the Expires header (see section 14.21). Alternatively, it may be
   specified using the "max-age" directive in a response. When the "max-age"
   directive is present in a cached response, the response is stale if its
   current age is greater than the age value given (in seconds)
   at the time of a new request for that resource.  The "max-age" directive
   on a response implies that the response is cachable (i.e., "public")
   unless some other, more restrictive cache directive is also present.

   If a response includes both an Expires header and a max-age
   directive, the max-age directive overrides the Expires header, even
   if the Expires header is more restrictive. This rule allows an origin
   server to provide, for a given response, a longer expiration time to
   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
   useful if certain HTTP/1.0 caches improperly calculate ages or
   expiration times, perhaps due to desynchronized clocks.

   Many HTTP/1.0 cache implementations will treat an Expires value that
   is less than or equal to the response Date value as being equivalent
   to the Cache-Control response directive "no-cache".  If an HTTP/1.1
   cache receives such a response, and the response does not include a
   Cache-Control header field, it SHOULD consider the response to be
   non-cachable in order to retain compatibility with HTTP/1.0 servers.

     Note: An origin server wishing to use a relatively new HTTP cache
     control feature, such as the "private" directive, on a network
     that includes older caches which do not understand that feature,
     will need to combine the new feature with an old Expires value
     in order to prevent the older caches from caching the response.

and then add as a separate paragraph at the end of section 14.9.3:

   If both the new request and the cached entry include "max-age"
   directives, then the lesser of the two values is used for
   determining the freshness of the cached entry for that request.

and fix the cross-ref in Section 13.2.4.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-1715
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 26 March 1997 16:46:33 UTC