question on 14.9.4, no-cache directive in requests

Anselm Baird_Smith (abaird@www43.inria.fr)
Mon, 6 Jan 1997 12:50:07 +0100 (MET) 

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.