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