- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 19 Feb 96 13:46:24 PST
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: hardie@nasa.gov
- Cc: http-caching@pa.dec.com
Note that the To: line of this discussion no longer includes the entire HTTP WG. I realize that this may seem confusing, but we need to understand that the two concepts of "don't answer from a cache" and "conditional GET" are completely orthogonal -- the fact that they are used in tandem to achieve a forced refresh versus a forced reload does not mean we should change the names to be more "meaningful", particularly when such a name change would in fact be less meaningful then what we use now. After watching this discussion go by, I'd like to agree with Roy that (1) the Cache-control directives in his HTTP/1.1 draft will work, and (2) they are obviously confusing, because a lot of people (myself included) were confused for a long time. The question of what names should be used is definitely a secondary one, but since lots of people do NOT find the currently-used names "meaningful" (in that they unambiguously convey the intended use and semantics), if we don't change the names then we must certainly improve the specification. The purpose of an IETF-blessed spec is to allow independent implementation of interoperable systems, so if an aspect of the spec has been widely misconstrued, it has to be fixed. Let me see what we have consensus on, and where we are still disagreeing. I will begin WITHOUT reference to specific syntax, because if we cannot agree on the semantics then there's no point in debating syntax. (1) Semantics: the HTTP protocol needs to support these cases in request messages: (A) I want a firsthand response from the origin server. (B) I want a response that has been validated with the origin server after I made this request. (C) I want to validate my own cached response with the origin server. (D) I want to validate my own cached response, but I'll accept a non-authoritative answer (i.e., from a cache that has a still-fresh copy with a matching validator) (E) I want a fresh response. Note that I've arranged these in roughly decreasing order of "paranoia". (2) Terminology: since we seem to spend a lot of time arguing about things when we are really just using different definitions for terms, let me propose a set of terms that we can use for these five cases. A = Reload B = Revalidate C = Specific revalidate D = Conditional method E = Normal method If someone would like to propose a better set of terms, please do so. Please don't just complain without proposing something else. (3) Syntax: if I understand Roy's spec correctly, this is what he has proposed: A = Reload GET /home.html HTTP/1.1 Cache-control: no-cache B = Revalidate GET /home.html HTTP/1.1 Cache-control: max-age=0 C = Specific revalidate GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT Cache-control: no-cache D = Conditional method GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT E = Normal method GET /home.html HTTP/1.1 Of course, "If-Invalid:" would be used if the server has sent an opaque validator. This is what my proposal was: A = Reload GET /home.html HTTP/1.1 Cache-control: reload B = Revalidate GET /home.html HTTP/1.1 Cache-control: revalidate C = Specific revalidate GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT Cache-control: revalidate D = Conditional method GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT E = Normal method GET /home.html HTTP/1.1 <SOAPBOX> I'll state for the record that, while I don't think it makes a big difference, I think it is unnecessarily confusing and absolutely without pragmatic value to use the same tokens (e.g., no-cache or max-age) on both request and response, especially when their meanings are significantly different depending on the direction. While it is true that the current practice with "Pragma: no-cache" does make this error, I do not think that this makes it any more attractive to compound the error in a brand-new header ("Cache-control:"). </SOAPBOX> Summary of consensus status: (1) I believe we have consensus on the underlying semantics for this aspect of the protocol. (2) We need commonly-held terminology to discuss things, and unless someone suggests something better soon, I'll assume we are agreed on my proposed terms. (3) The debate over syntax, as far as I can, is entirely concerned with (a) different views of what is "meaningful" (or how meaningful a token name needs to be anyway). (b) different views of whether the existing syntax of Pragma: should be carried forward to Cache-control: If anyone has a disagreement about this summary of our debate, please speak up immediately. Larry Masinter has asked me to prepare a list of items and how we stand on them, and I need to do this in the next 48 hours. -Jeff
Received on Monday, 19 February 1996 22:00:30 UTC