- From: Anselm Baird_Smith <abaird@www43.inria.fr>
- Date: Mon, 6 Jan 1997 12:50:07 +0100 (MET)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul writes: > Anselm asks > - [a question] 14.9.4 says under "End to end reload" that "... No > field names may be included with the no-cache directive in a > request". I assume an "In that case, " is implicitly assumed at the > beginning of the sentence ? [I can see good reasons for using > no-cache with field names in a request, as does] > > The complete text of this paragraph is: > End-to-end reload > 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. > > Actually, our intention (as far as I understand it) for this > request directive was that it totally prevents the use of a cached > response in reply to the request. I.e., we did not intend that > there be an "In that case" at the beginning of the second sentence. > I'm not sure I understand what it would mean to specify a field name > in the request. E.g., what does this mean: > > GET /foo.html HTTP/1.1 > Cache-control: no-cache="Expires" > > If you have an example that does make sense, that would be helpful. 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 <">] | ... 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...[btw I haven't implemented that version of no-cache in Jigsaw though] > 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". Anselm.
Received on Monday, 6 January 1997 04:41:20 UTC