View: Browse HTML Browse Raw Text From: Jeffrey Mogul <mogul@pa.dec.com> Date: Thu, 13 Mar 97 14:02:49 PST To: jg@w3.org Subject: Issues list item "NO-CACHE"
The issues list has a pointer to a message from Anselm Baird-Smith into the middle of this conversation, but I don't think it includes my summary of the situation. -Jeff ------- Forwarded Message Return-Path: masinter@parc.xerox.com Received: by acetes.pa.dec.com; id AA01819; Sun, 2 Mar 97 10:13:39 -0800 Received: by pobox1.pa.dec.com; id AA22996; Sun, 2 Mar 97 10:13:42 -0800 Received: from alpha.Xerox.COM by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)id AA32531; Sun, 2 Mar 1997 10:05:47 -0800 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16600(4)>; Sun, 2 Mar 1997 10:04:28 PST Received: from palimpsest ([127.0.0.1]) by palimpsest.parc.xerox.com with SMTP id <242>; Sun, 2 Mar 1997 10:04:19 PDT Sender: masinter@parc.xerox.com Message-Id: <3319C122.5242@parc.xerox.com> Date: Sun, 2 Mar 1997 09:04:18 PST From: Larry Masinter <masinter@parc.xerox.com> Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: jg@w3.org Cc: mogul@pa.dec.com Subject: [Fwd: please add this to the "bug list"] Content-Type: multipart/mixed; boundary="------------7DB94F479FB" This is a multi-part message in MIME format. - --------------7DB94F479FB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm vaguely uneasy that I already mailed this one to you; apologies if so. Anyway, I don't know what to call this, but it should be there. - -- http://www.parc.xerox.com/masinter - --------------7DB94F479FB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from alpha.xerox.com ([13.1.64.93]) by casablanca.parc.xerox.com with SMTP id <71830>; Mon, 6 Jan 1997 11:33:17 PST Received: from mail2.digital.com ([204.123.2.56]) by alpha.xerox.com with SMTP id <17485(6)>; Mon, 6 Jan 1997 11:33:11 PST Received: from acetes.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA29415; Mon, 6 Jan 1997 11:27:38 -0800 Received: by acetes.pa.dec.com; id AA16941; Mon, 6 Jan 97 11:27:37 -0800 Message-Id: <9701061927.AA16941@acetes.pa.dec.com> To: masinter@parc.xerox.com Subject: please add this to the "bug list" Date: Mon, 6 Jan 1997 11:27:37 PST From: Jeffrey Mogul <mogul@pa.dec.com> Specifically, either we need to change the grammar for cache-request-directive = "no-cache" [ "=" <"> 1#field-name <"> ] to cache-request-directive = "no-cache" or we need to define what it means to send a field-name here. Also, the meaning of no-cache="field-name" in a response probably needs to be made more explicit. - -Jeff - ------- Forwarded Message To: Anselm Baird-Smith <abaird@w3.org> Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com Subject: Re: question on 14.9.4, no-cache directive in requests Date: Mon, 06 Jan 97 10:45:24 PST From: Jeffrey Mogul <mogul@pa.dec.com> > The complete text of this paragraph is: > The request includes a "no-cache" Cache-Control directive or, for > compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field > names may be included with the no-cache directive in a request. The > server MUST NOT use a cached copy when responding to such a request. First of, my interpretation was based on the fact that the BNF explictly allows for it (section 14.9, p 69): cache-request-directive = "no-cache" [ "=" <"> 1#field-name <">] | ... This looks like a bug in the specification. At least, it's either an explicit contradiction, or we have defined no semantics for what 'Cache-control: no-cache="foo"' means in a request, which means that it has no useful meaning. The usage I had in mind was: GET /icons/w3c Cache-Control: no-cache="Accept" Accept: image/gif Semantics: I am getting a (negotiated) resource, you can use that Accept header to fetch it, but you should not cache it (ie I don't want any proxy to save it permanently). This may prevent (in that precise case) the caching of the whole reply, but I don't care... This is an interesting proposal, but since the meaning isn't defined in the current HTTP/1.1 draft, I can't imagine anyone relying on it. Maybe you would like to write up a proposed specification as an I-D? As far as I know, no other aspect of the protocol lets the client control what an intermediate cache should do with respect to caching the response to the current request. I.e., the origin server can say "don't cache this response", and the client can say "don't give me a response from your cache", but we have no defined mechanism for the client to say "don't put the response to this request into your cache". In your case, you seem to be going one step further (if I understand your example), in that the client says "it's OK to cache the response to this request, but don't remember the fact that my request said 'Accept: image/gif'." Unfortunately, if the response includes 'Vary: Accept', which is likely to do, the spec *requires* the proxy to remember what the named request header(s) said. So you would have to be careful to define what happens in this case. > In a *response* message, we allowe the no-cache directive to carry one > or more field names, e.g., > > HTTP/1.1 200 OK > Server: CERN/3.0 libwww/2.17 > Cache-control: no-cache="Server" > > would mean (according to the somewhat sketchy language in > section 14.9.1) that an HTTP/1.1 client or proxy could cache > most of the response, but could not cache the "Server" response header. > > I believe that this was intended as a way for certain applications > to allow caching while preventing the storage of certain response > fields that might have privacy implications, although I'm not > sure I can come up with a good example. (However, I would > expect that the "private" response directive would serve that > purpose well enough.) My reading of 14.9.1 is that private means "cacheable only by private cache" while "no-cache" means "don't cache under any circumstances". Not exactly. The meaning of "no-cache" shifts somewhat when there is a field-name attached. If no field-name is included, then "no-cache" in a response does indeed mean "don't cache under any circumstances." However, if a field-name is present, then the meaning is "don't cache the named fields under any circumstances." (I'm not sure this is really explicit enough in the draft, however.) Implicit in a response that says 'Cache-control: no-cache="Server"' is that you *can* cache the rest of the response (including the body and the other header fields), since otherwise the server would simply have sent 'Cache-control: no-cache', right? I'm not sure that this convoluted definition of no-cache really makes life easier for people. I remember arguing that we should be using a wider range of names for cache-control directives, and being accused of trying to make the specification "too complex." But it's probably too late to change the actual specification of "no-cache", although I think it's clear that we need to clarify it. - - -Jeff - ------- End of Forwarded Message - --------------7DB94F479FB-- ------- End of Forwarded Message