- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Tue, 20 Feb 1996 08:11:46 -0800
- To: Shel Kaphan <sjk@amazon.com>
- Cc: http-caching@pa.dec.com, state@xent.w3.org
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