- From: Brian Gaines <gaines@cpsc.ucalgary.ca>
- Date: Sun, 7 Jan 1996 11:19:46 -0700
- To: http-caching@pa.dec.com
>BTW, "cachable" in HTTP means that the response may be reused as the response >for an equivalent future request -- it does not mean just "may be stored". > Roy, you cannot simply assert this, and it doesn't make sense to define it that way either (because a specialist use of a technical term defined in one place will often be forgotten in using the body of the spec). Browsers generally use the same cache for the history list as for reuse, AND seem to use the same HTTP control mechanisms for both (which is not to say that they SHOULD do so). The specification needs to distinguish the uses of caching, say: reuse-cache for all reuse that is transparent to the user, i.e. where the user is not explicitly accessing the cache history-cache for a cache explicitly accessed by the user Cache alone can be used for brevity where the context is explicit. I'm assuming that no distinction is generally necessary between reuse-caching at the browser and that at a proxy server. It seems clear from the discussion on the caching list that the history-cache needs its own control mechanisms (as in http://www.amazon.com/expires-report.html) It is also clear that the designers of major browsers have NOT made the distinction between reuse-caching and history-caching that you are making. The use of the same code to implement both is leading to confusion about the separate logic of operation of each. This makes it particularly important that the specs carefully distinguish the functions of caches from their implementation, and that the protocols for reuse-caching and history- caching are clearly separated. One can see why the reuse-cache and history-cache of a browser are treated the same. For GET/POST with no side-effects they can be identical. However, if there are side effects there is a major difference between reviewing history and obtaining the latest version. Implementation-wise there will be benefits to using the same mechanism where possible. However, the protocol spec need not take this into account and can distinguish the two forms of caching and their control. b. Dr Brian R Gaines Knowledge Science Institute University of Calgary gaines@cpsc.ucalgary.ca Calgary, Alberta, Canada T2N 1N4 403-220-5901 Fax:403-284-4707 http://ksi.cpsc.ucalgary.ca/KSI
Received on Sunday, 7 January 1996 18:38:46 UTC