question on 14.9.4, no-cache directive in requests

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.

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

-Jeff

Received on Tuesday, 31 December 1996 11:44:39 UTC