- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 12 Apr 1996 01:54:55 +0200 (MET DST)
- To: mogul@pa.dec.com (Jeffrey Mogul)
- Cc: fielding@avron.ics.uci.edu, http-caching@pa.dec.com
Some observations after todays phone conference of the editorial group: On Last-Modified: It seems we agreed that the use of last-modified for cache validation should be phased out. Most people would not like proxies to rely on the Last-Modified value when combining ranges, because of the 1.0 servers around. There did not seem to be much support for Roy's idea to require that 1.1 servers make the last-modified date a `strong' validator that is guaranteed to be different for different entities, even if the entity bound to the resource is updated twice in one second. On terminology: we may need to introduce the concept of a `weak validator' because we need to talk about last-modified being `weak' in the 1.1 document. If we need to, we have to invent a better term than `weak validator'. On weak opaque validators: it is clear that Roy thinks these are evil, and must never be in HTTP. Others do not want to discount the possibility that weak validators could significantly improve future HTTP performance for some future applications. On weak opaque validators in 1.1: Jeff argues that, though he cannot invent a `killer app' for them now, we should introduce weak validators in 1.1 (even if they may never be generated by 1.1 origin servers), because if we don't, we may not be able to introduce them later, or only with great pain. If this were not true, if we _could_ introduce them later painlessly, then we could make weak opaque validators a `not in 1.1' issue. What about this: if we leave weak opaque validators out of 1.1, we can add them in 1.2, if we decide we need them, by adding a Cval-Not-For-Ranges = "Cval-Not-For-Ranges" ":" cval-info header. The `weak' cval-info values in such a header would just be ignored by 1.1 caches relaying these responses, because these caches ignore headers with unknown names. As long as the response also contains a Last-Modified header, no performance will be lost in these 1.1 caches. If 1.2 clients include weak cval-info values from Cval-Not-For-Ranges headers in If-Valid/If-Invalid headers of requests sent through 1.1 caches, the 1.1 caches will not break: they will pass the request on towards the origin server because the cached response did not include a Cval header with a matching validator. So adding weak opaque validators in 1.2 seems to be painless. Could it really be this simple? Or is there a hole in my reasoning above? Koen.
Received on Friday, 12 April 1996 00:11:01 UTC