- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 09 Jan 96 18:56:24 PST
- To: drtr1@cus.cam.ac.uk (David Robinson)
- Cc: http-caching@pa.dec.com
Suggestion; that there should be general bias towards servers providing descriptive rather than proscriptive information, i.e. headers should carry information about the resource rather than commands on what the client should do with the resource. I think I generally agree with you, although I'm not sure why you are suggesting this so perhaps we are using the same terms to mean different things. I'd prefer to use slightly different words, to be more precise: The protocol design should use *declarative* rather than *procedural* techniques whenever possible, since that tends to give the implementations more flexibility. But even if we agree here, what this actually means is a matter of interpretation. For example, I view the Fresh-until: value as purely declarative, saying that "you can safely assume that this response I am giving you is not going to change significantly for that many seconds". On the other hand, something like "Cache-control: reload" is apparently procedural, but I suspect that we cannot do without a few such features. Anyway, my particular point is that any statement that 'the cache must assume a [default] value of...' is very bad. The cache may well have other information about the resource; this statement forbids the cache to make use of this information. [Example; knowledge based on the particular server software.] By equating a lack of a Fresh-Until header with Fresh-Until: 0 or Fresh-Until: 7days you remove the option of the server indicating 'I have no information to give you about the fresh-until time of this resource'. This is bad both because of the usefullness of this option, Can you give a scenario where this is different from "Fresh-until: forever"? And would you be satisfied if (as I proposed the other day) the protocol included an explicit way to say "I have no information to give you about the fresh-until time of this resource"? but also because this is what HTTP/1.0 servers currently do. Interoperability with HTTP/1.0 should be a high priority. I most certainly addressed this issue in my proposal, requiring caches to use a heuristic to choose a fresh-until value for responses that come from HTTP/1.0 servers. I left the heuristic undefined for now, because I'm not sure what HTTP/1.0 caches actually do. In fact, the combined effect of my proposal is to tend towards lenience, since I suspect that if an HTTP/1.1 server sends a response without Fresh-until:, which is proxied through an HTTP/1.0 cache, and then received by an HTTP/1.1 cache, the latter would believe that it has received a value from an HTTP/1.0 origin server and should NOT assume a value of zero. By all means state 'in the absence of a fresh-until time, the cache may assume a default of 7days' -- the period of time should be chosen to be in accord with the defaults in use by that currently existing caches. Is this what HTTP/1.0 caches do: keep things for 7 days? Or does the practice vary? Any experts out there? -Jeff
Received on Wednesday, 10 January 1996 03:03:23 UTC