- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 10 Jan 96 12:13:18 PST
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: http-caching@pa.dec.com
I think we have almost converged. I think the remaining confusion stems from an unstated distinction between "ideal" behavior and "reasonably good practical approximation to ideal" behavior. Let me try to illustrate with these trial definitions (which I am not suggesting are all worth putting into the spec): ideal cache exists to model the origin server's responses to requests. Semantically transparent to the user for all practical purposes, but should improve performance according to one or more metrics. ideal history buffer records what the user has seen during past interactions, and provides a means for the user to revisit those views exactly as they were seen. ideal location log records what locations the user has visited during past interactions; provides a means for the user to revisit those locations to discover their current contents. practical cache exists to model the origin server's responses to requests. Semantically transparent to the user, except that the origin server, user, or cache administrator may choose to compromise transparency in the service of performance or availability. Should improve performance according to one or more metrics. practical history buffer records what the user has seen during some subset of past interactions, and provides a means for the user to revisit those views exactly as they were seen, or as best as can be approximated given finite buffer space. practical location log records a subset of the locations the user has visited during past interactions; provides a means for the user to revisit those locations to discover their current contents. I'll note right away that I don't know if any existing browsers make a clear distinction between the history buffer and the location log, at least in their user interfaces. That doesn't mean that we can't make the distinction, at least for the purposes of discussing these in the context of the HTTP protocol specification. So what does this mean? First, I think we can agree that the HTTP specification should include some constraints on the behavior of caches, but should also leave some of the behavior up to the implementer or user. Second, I think we have no choice but to leave the behavior of a history buffer up to the browser implementor, although we might specify that if a browser confuses the distinctions, then any resulting erroneous behavior is not the fault of the servers or proxies. A browser implementor may choose to use the browser's cache to approximate the history buffer, in which case it's possible that a user will see something other than the "historically accurate view" of a page, but that's between the user and the browser vendor; it's not something we can fix in the protocol spec. This includes issues such as "does 'subset' mean terminal subsequence?" and does "approximated mean one can retrieve a new copy of the page if the old view didn't fit into the buffer?" Although we might want to make a few "recommendations" here. Similarly, the implementation of a location log isn't something we can specify, although we could recommend that (for example) it includes a terminal subsequence of the locations visited. -Jeff
Received on Wednesday, 10 January 1996 22:32:25 UTC