- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 9 Jan 1996 17:57:17 +0100 (MET)
- To: mogul@pa.dec.com (Jeffrey Mogul)
- Cc: fielding@avron.ics.uci.edu, http-caching@pa.dec.com
Jeffrey Mogul: >While Koen Holtman asserts that this: > An HTTP/1.1 server SHOULD provide a fresh-until time with every > cachable entity, but if it does not, the cache must assume a value of > zero. > >"is a very bad thing" (why?), I said I agreed with Roy on this, and I also agree with his explanation on _why_ it is a bad thing. I'm not sure I can explain my objections any more clearly than Roy already did, but here is a try: Your default value would force service authors to include a Fresh-until: <some number> header in 99% of all HTTP/1.1 responses. We have no guarantee that they will indeed do this. In fact, the recent statistic about the use of Expires headers suggests that many will not. If a significant faction does not, or is too late in doing it, proxy maintainers will start ignoring the default of zero specified in the protocol because they need to get at least the same performance they got when caching HTTP/1.0 traffic. Thus, we will end up in a situation in which you can not longer trust proxies to conform to the protocol they claim to conform to. Very bad. I can't guarantee the above zero default collapse scenario _will_ happen, but I see no justification for taking such a risk. > in the next breath he agrees that there >ought to be some finite value here. I proposed "zero", he proposed >"7 days", I proposed the "7 days" as a maximum age before verification. Caches would be free to check more often, and I expect them to do so on resources without Fresh-until headers that were recently modified. > and I think we can both agree that the other one's proposal >is too extreme :-). I'm happy to discuss the particular value, or >recommended range of values, but I think it would be a mistake to leave >it completely unconstrained. I agree it would be a mistake (though not a huge mistake) to leave the value unconstrained. If the upper bound for a heuristically computed lifetime is left unconstrained, service authors that decide to start providing Fresh-until (max-age) headers with existing resources that have already been around for some time could never be sure that their new values ever overrule the heuristics of gigabyte caches. You could never say `I fixed it: in 7 days, users behind the proxy of gigacache.net won't see `happy xmas' on a single one of our 5000 pages anymore'. If service authors are not able to make such definite claims (to management, for example) about improvements after the introduction of Fresh-until (max-age) headers, they will be discouraged from introducing these headers. >-Jeff Koen.
Received on Tuesday, 9 January 1996 17:18:43 UTC