- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Tue, 20 Feb 1996 09:18:48 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-caching@pa.dec.com
> 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.
Are the names confusing, or is it just that people do not understand
the difference between "browser actions" and protocol syntax?
The fact that a single browser action is achieved by a combination
of two (or more) protocol elements may be confusing, but we wouldn't
make it less confusing by changing the name of one of those elements
when the one by itself is not sufficient to achieve the semantics
of its new name.
> 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.
No problem there -- the answer is to improve the wording of the
specification to explain the usage of multiple protocol elements
to achieve the desired semantics. That is what the chapter on Caching
is supposed to do.
> 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".
The way you phrased the above sentences would lead you down the wrong
track in trying to determine the actual semantics. Try this:
(A) I want a new copy from the origin server.
(B) I want a response from the origin server
based on the parameters of this request.
(C) I want a new copy from the next inbound cache or origin.
(D) I want a response from the next inbound cache or origin
based on the parameters of this request.
(E) I want whatever is currently available.
Note: (A) is just a special case of (B)
(C) is just a special case of (D)
(E) is a special case of (D) as well, except that it is explicitly
saying that semantic transparency is not desired.
> (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.
A = Reload
B = Refresh (whether or not it is valid is immaterial)
C = Refresh from origin (Revalidate is okay, but less descriptive)
D = Conditional GET
E = GET
> (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
Yes.
> B = Revalidate
> GET /home.html HTTP/1.1
> Cache-control: max-age=0
No. B = Refresh
GET /home.html HTTP/1.1
<some-conditional-header>: <time or version-based condition>
> C = Specific revalidate
> GET /home.html HTTP/1.1
> If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
> Cache-control: no-cache
Yes, but more accurately:
C = Refresh from origin
GET /home.html HTTP/1.1
<some-conditional-header>: <condition that achieves refresh>
Cache-control: no-cache
> D = Conditional method
> GET /home.html HTTP/1.1
> If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
Nope, that is only one of [6?] proposed ways of making a condition
D = Conditional method
GET /home.html HTTP/1.1
<some-conditional-header>: <condition>
> E = Normal method
> GET /home.html HTTP/1.1
>
> Of course, "If-Invalid:" would be used if the server has sent an opaque
> validator.
Or IF, If-ID, Unless-Modified-Since, Cache-control: max-age, etc.
> This is what my proposal was:
> A = Reload
> GET /home.html HTTP/1.1
> Cache-control: reload
No, it introduces an unnecessary contradiction with
GET /home.html HTTP/1.1
Cache-control: reload
If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
> B = Revalidate
> GET /home.html HTTP/1.1
> Cache-control: revalidate
No, it introduces a contradiction if no validation information is provided
to go along with the revalidate directive. Furthermore, it places syntax
significant to an origin server in a place that origin servers should
never need to look.
> C = Specific revalidate
> GET /home.html HTTP/1.1
> If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
> Cache-control: revalidate
Redundant.
> 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.
The meaning of both of those directives are identical on both request
and response. The only thing that changes are the browser actions
which make use of those directives, and that distinction is not
meaningful to the protocol.
> 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.
I don't. Your syntax ignores my (E) and therefore is inadequate
to describe existing browser behavior, let alone the protocol.
HTTP/1.1 as currently specified has our two (E)'s being equivalent.
I'm not sure why you have it that HTTP will only transfer fresh entities
by default. If you change that default, then you also need a new
syntax for obtaining the old default.
> (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.
Negative. The terms used in the HTTP/1.1 spec are more accurate
regarding the purpose and effect of the protocol elements in question.
> (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).
Yes. That and a less-than-perfect understanding of the protocol based
in no small part on a less-than-perfect description in the spec.
> (b) different views of whether the existing syntax of
> Pragma: should be carried forward to Cache-control:
Not relevant -- the syntax was carried forward because it was the
right syntax for Pragma as well.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Tuesday, 20 February 1996 18:03:32 UTC