W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: backward compatibility of non-cachable headers

From: Shel Kaphan <sjk@amazon.com>
Date: Sun, 18 Feb 1996 00:32:42 -0800
Message-Id: <199602180832.AAA15887@bert.amazon.com>
To: koen@win.tue.nl (Koen Holtman)
Cc: http-caching@pa.dec.com, state@xent.w3.org
Koen Holtman writes:
 > 
 > [...]
 > > >  Expires: Thu, 01 Jan 1980 00:00:00 GMT
 > > >  Cache-control: no-cache="set-cookie"; max-age=100000
 > > >  Set-Cookie: session-id=4314
 > 
 > >I think you need the expires even in 1.1, so that future
 > >requests for this resource will be passed through to the origin, where
 > >they can get a new cookie.
 > 
 > Oops, you are right, I should have said max-age=0 above.
 > 

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.

  ``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.''

Does this mean that max-age=n in a response should affect subsequent
requests for the 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?

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.

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.

Therefore, until Roy explains what he meant by the above quoted
paragraph, I don't think we can talk clearly about using
cache-control: max-age=n in responses with a shared understanding
of what is supposed to happen.

As always, if I'm just being dense, you'll have to forgive me (or
not).  But if I find this part of the proposed spec confusing, so will
other people.

--Shel
Received on Sunday, 18 February 1996 09:01:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC