- From: Shel Kaphan <sjk@amazon.com>
- Date: Sun, 19 May 1996 15:52:38 -0700 (PDT)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I'd like to suggest that the second paragraph of 16.2.2 (Limitations on the effect of Expiration Times) be moved to 16.11 (History Lists), and that a short cross reference to 16.11 be put in 16.2.2 instead. I'd also like to see the "should" in the third sentence of that paragraph be in upper case so that it is clear this is intended in the formal sense. Then, I think 16.11 needs one more paragraph to explain the reason behind the suggestions about history lists, because this is something that has proven to be a stumbling block for browser implementers in the past, and if they continue to make mistakes with this, it may render much of the new cache-control stuff moot for many applications. Perhaps something like this: "Furthermore, if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it important that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms." --------------------------- In 16.9 (Invalidation after Updates and Deletions), last sentence, it should be made clear which resource is to be invalidated if Content-Location and/or Location are present as well as the request-URI. Regarding invalidation, it would also be nice to put in a little caveat to the effect that that a single logical site that operates across multiple hosts may work improperly if the URLs are not partitioned carefully across these hosts (because operations on one host cannot invalidate cache entries from another host), and also that there is a similar problem if the communication path from client to origin server varies with time during a user's interaction with that origin server, and they end up going through multiple non-communicating caches. I would also like to see references to 16.9 in sections 18.15 (Content-location) and 18.27 (Location), since invalidation is an important part of the logic for handling both of these headers. --------------------------- 18.5 (Age) and 16.2.4 should explicitly reference each other, and 16.2.4 should be a little more explicit about what goes into the Age header that is transmitted by an intermediate cache. Furthermore, I think the discussion needs a sentence or two of motivation about the problem that Age is intended to resolve, as to why it is insufficiently addressed by simply doing a computation based on Date. More later, probably. --Shel Kaphan sjk@amazon.com
Received on Sunday, 19 May 1996 15:53:39 UTC