W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: why no-cache is not reload

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 19 Feb 96 13:46:24 PST
Message-Id: <9602192146.AA00907@acetes.pa.dec.com>
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

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

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

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:").

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
	(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.

Received on Monday, 19 February 1996 22:00:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC