"Expires:" vs. "Cache-control: max-age"

Jeffrey Mogul writes:
 > Shel writes:
 > 
	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.
 > 
 > I don't think Roy's meaning was unclear, because Roy views
 > "Cache-control: max-age" as a replacement for "Expires:"
 > (but we cannot eliminate Expires: from HTTP/1.x, for compatibility
 > reasons).
 > 

The main reason I came to the conclusion I did is that, some months
ago, Roy was quite insistent that max-age in responses was providing a
different piece of functionality than Expires does.   I couldn't see
it then, and I don't now.  I don't mind if they mean the same thing
but stated in a different way, but I'd at least like to know if that
is the case.

Something useful about the existence of max-age is that, if we
carefully define it, it could avoid the confusion with browser history
mechanisms that has rendered Expires nearly unusable for many applications.

 > However, I don't quite buy Roy's rationale.  First of all, I am
 > almost ready to agree with Koen that giving an origin server the
 > ability to set different expirations based on the protocol version
 > of the cache, while kludgey, might be exactly what we need to be
 > able to work around the existing misconfigured caches.

... and history mechanisms ...

  In other
 > words, "Cache-control: max-age=X" is a good thing to have, but
 > for reasons in addition to what Roy has said.
 > 

I agree with that conclusion, and everything else you said, but I
don't feel very strongly about "fresh-life" vs. "max-age".  Actually,
"fresh-life" reminds me rather too much of "life-style".

--Shel

Received on Tuesday, 20 February 1996 00:18:35 UTC