Re: question on 14.9.4, no-cache directive in requests

     > 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

Received on Monday, 6 January 1997 10:55:45 UTC