Re: Still trying to make sense of HTTP caching model

I said:
] 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.

But this would be silly. (I can only be so obnoxious because I'm 
commenting on what *I* wrote.) We can keep the protocol simpler, and 
cache implementors' lives simpler, by having the server do the 
computation above.

Server writers should make it easy to administer their servers.  If 
that means that they present a UI with a form that has an input box 
labeled "Max-Age" and they compute Expires headers from it, because 
that's the best way for server admins to think about it, that's great.

Personally, I think I would ask for two things in my server admin UI: 
when the document expires, because the info is no longer valid, and how 
frequently they think it will change.

There is one slight twist on this, however: even if GET only needs 
Expires, PUT and POST need Expires *and* 
max-cache-lifetime-between-validates, so that the person 
adding/modifiying the page can specify these things. But here, they are 
in the request, not in the response.

Paul

Received on Thursday, 7 September 1995 09:58:31 UTC