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

> Roy managed to confuse me with:
>    Max-age needs to override expires simply because we don't want
>    servers to have to calculate the HTTP-date in expires if they
>    understand max-age.

Ooops, did I say that? I meant "we don't want caches to ...".  Sorry.

> until I decided that "calculate" means "format" and "understand"
> means "able to generate" if "servers" mean "origin servers",
> but if "servers" mean "proxy servers" then the translations are
> "parse" and "accept".

Ummm, no. I just screwed up.

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

The reasons for it are less important than the flexibility it gives
to new applications that we have not even thought about yet (i.e., I agree).

> Second, given the number of HTTP/1.0 caches out there, and given
> that if these caches do not see Expires:, they pick an expiration
> time heuristically (with a relatively large upper bound), I think
> HTTP/1.1 servers with significant expiration constraints are going
> to have to send explicit Expires: headers.

Absolutely true (or at least until such older applications no longer exist).
In any case, a full date in Expires is useful if the document itself
has an absolute date after which the information contained within it
will not be accurate.

> I would like to propose this as our consensus:
> 
> 	(1) Origin servers may send either or both of
> 		Expires:
> 	and
> 		Cache-control: max-age=N
> 	on responses
> 
> 	(2) If both are sent, an HTTP/1.1 implementation SHOULD
> 	obey the Cache-control: max-age=N directive.

add " and may ignore the Expires field value".

> 	(2b) but HTTP/1.0 implementations will ignore it, so servers
> 	SHOULD NOT depend on a cache obeying that directive.

Okay.

> I think we also might want to change the last sentence of Roy's
> paragraph from
>     The behavior should be equivalent to what
>     would occur if the request had included the max-age directive.
> to
>     The behavior should be equivalent to what would occur if this
>     response had an Expires: field specifying the same number of
>     seconds since its Date: field, but overrides other Expires:
>     value.

That can be said in addition (not a replacement) to the above.

> Separately, I would like to suggest that there is no good reason
> (not even tradition, since we don't have one here) to use the
> same "max-age" token in both requests and replies.  It just seems
> to confuse people.  How about using
> 	Cache-control: fresh-life=NNN
> on responses, and
> 	Cache-control: max-age=NNN
> on requests?

YUCK!  They are identical in semantics; they should remain identical in
the syntax.  This is particularly true given the addition of Age:.


 ...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 17:54:40 UTC