- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Feb 96 11:56:44 PST
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
Oh dear, I'm afraid I've confused matters by assuming that we had shared definition for the term "to store". I was trying to make a distinction between two things a cache might do with a data item (response or part thereof): (1) return it in response to some request other than the one that cause the cache to receive the data in the first place. (2) save it in some storage medium (disk, RAM, etc.) The reason I was making this distinction is that some people (specifically Dave Morris) had insisted on the ability to specify that caches NOT do #2 for some resources. Not that I necessarily think this is a good thing to put into the protocol, but apparently some customers insist on this sort of nonsense (not to bias the discussion or anything :-). I had thought that Roy was using the word "store" in this more specific meaning, and apparently he was. I.e., his clarification today that "must not be stored unless the user explicitly requests it through a separate action" means "must not be stored by a cache but the user may explicitly save the value to a file outside the control of the application" (or something close to that). I'm not quite sure if this applies to history buffers, either. Roy then managed to confuse me again by objecting to my proposal for "Cache-control: no-store" because it doesn't solve the eavesdropping problem, but I think this is an inconsistent position. Either the protocol spec says nothing about "storing" values, but confines itself to specifying when they may be "returned" from a cache ... or the spec DOES talk about when they can be stored, in which case it seems appropriate to give servers and users some control over this. -Jeff
Received on Tuesday, 20 February 1996 20:16:23 UTC