Re: backward compatibility of non-cachable headers

Shel writes:

> I am still confused about Roy's intent regarding max-age in responses.
> I'm now quoting from an old spec version (00a, 8/27/95), so forgive me
> if it has changed since then.  My other copy is at work.

Burn that copy -- you should never reference an old copy because it will
just lead to confusion.

>   ``When the "max-age" directive is present in a cached response
>   message, a caching intermediary must refresh the message if it is
>   older than the age value given (in seconds) at the time of a new
>   request for that resource.  The behavior should be equivalent to what
>   would occur if the request had included the max-age directive.''

Or, from draft 01:

   When the "max-age" directive is present in a request message, an
   application must forward the request toward the origin server if it
   has no cached copy, or refresh its cached copy if it is older than
   the age value given (in seconds) prior to returning a response. A
   cached copy's age is determined by the cached message's Date header
   field, or the equivalent as stored by the cache manager.

   [Note -- Koen has already proposed a more reliable method of determining
    the cached copy's age]

   In most cases, a cached copy can be refreshed by forwarding a
   conditional GET request toward the origin server with the stored
   message's Last-Modified value in the If-Modified-Since field. The
   Unless header field may be used to add further restrictions to the
   modification test on the server. If a 304 (not modified) response
   is received, the cache should replace the cached message's Date
   with that of the 304 response and send this refreshed message as
   the response. Any other response should be forwarded directly to
   the requestor and, depending on the response code and the
   discretion of the cache manager, may replace the message in the
   cache.

   When the "max-age" directive is present in a cached response
   message, an application must refresh the message if it is older
   than the age value given (in seconds) at the time of a new request
   for that resource. The behavior should be equivalent to what would
   occur if the request had included the max-age directive. If both
   the new request and the cached message have max-age specified, then
   the lesser of the two values must be used. A max-age value of zero
   (0) forces a cache to perform a refresh (If-Modified-Since) on
   every request. The max-age directive on a response implies that the
   server believes it to be cachable.

> Does this mean that max-age=n in a response should affect subsequent
> requests for the resource?

Yes, that is exactly what it means by "a new request for that resource."

>                             The problem is that the reference to "the
> request" in the final sentence is unclear:  does it refer to (1) the
> request for which the response contains cache-control: max-age=n?  Or
> does it refer to (2) "a new request" for that resource?

(2).  I suppose we should add "new" for that sentence to go along with
all the other times it is mentioned in that paragragh, but there is
no other reasonable interpretation of that feature.

> If interpretation (1) is used, then except for the phrase "at the time
> of a new request", this paragraph appears to mean that a response
> containing cache-control:max-age=n will only update caches if the
> cache's entry is at least n seconds old.  This is clearly nonsense, so
> interpretation (1) must be wrong.

Obviously.

> If interpretation (2) is used, then if a response contains
> cache-control:max-age=n, *subsequent* requests for that resource will
> behave as if they contained cache-control:max-age=n.  Thus the "clock
> begins ticking" on the cached resource at the time it is sent by the
> origin server. In other words, after Date: + n seconds, any new
> requests for the resource cause the cache to "refresh" (i.e. validate)
> that resource. If this interpretation is correct, then including
> cache-control:max-age=n in a response is exactly equivalent to
> including Expires: <now + n seconds> in the response.  Since this
> functionality appears to be redundant, I am forced to conclude that
> this interpretation, too, must not be what Roy intended.

Why?  I've said several times before that the redundancy is NECESSARY
because people did not want to calculate the expiration time from a
full HTTP-Date and because clock skew made Expires unreliable for
short periods.  Expires will still be used because of older caches,
but can be ignored by recipients that understand Cache-control.
That whole discussion took place on the WG mailing list last summer.

Furthermore, allowing the same semantics to be declared by the client
on a request provides an improvement over the existing use of

    If-Modified-Since: date(<time-now-at-client> - <max-age>)

to do the same functionality, but without the lossage due to clock skew.

In summary, max-age does what the spec says it does, and provides
IDENTICAL functionality on both request and response, which explains
why I didn't change the name.


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

Received on Tuesday, 20 February 1996 16:53:14 UTC