Re: Still trying to make sense of HTTP caching model

Don't get me wrong.

In the abstract, I don't care whether the protocol sends Expires or 
max-age. But we have Expires. So I wouldn't want to add a new header or 
parameter that completely duplicates its functionality.  I wouldn't 
mind *replacing* Expires with max-age, but because of backwards 
compatibility, that doesn't seem to be an option.

John says:
] A final word on this last point.  The HTTP protocol can presumably
] legally define any header to have any semantics.  But we need to keep
] in mind that most Expires headers (and most Cache-Control headers
] in the future) are set by server maintainers.  The fraction of server
] maintainers who ever have or ever will read the protocol is
] negligible.

This is a good point -- or at least one I didn't understand at all. I 
didn't think of Expires as a persistent document property.  I.e.,  I 
wasn't thinking that the admin would set an Expires time, but that the 
server would compute one based on how long an admin said a particular 
resource should be cached. (I.e., the person putting a page on the 
server would specify "max-age", but the server would compute and send 
"Expires".) I think your view is that Expires is set based on some 
intrinsic property of the page, such as that it is this month's price 
list, and is no good after the end of the month; max-age is set based 
on an estimate of the volatility of the page -- such as that it changes 
an average of  twice a day, so the cache should check every hour to see 
if a new copy is available. This makes sense to me.

Previously one of my big objections to max-age was that we'd have to 
spec what to do if both were present.  Now your excellent point helps 
me see how to do this.

If a response arrives with max-age=A and Expires: T, then the cache 
should set the "validate-after" field to
	min(T, CurrentTime()+A)
I.e., it can serve the document from the cache either until it expires, 
or until the maximum age passes. If Expires is missing and max-age is 
present, then T would be assumed to be in the far future.

Paul

Received on Thursday, 7 September 1995 09:44:59 UTC