Re: question on 14.9.4, no-cache directive in requests
Anselm Baird_Smith (abaird@www43.inria.fr)
Tue, 7 Jan 1997 09:03:16 +0100 (MET)
Jeffrey Mogul writes:
> [ about Cache-Control: no-cache=<fields> in requests]
> 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?
I must say it took me sometime to come with an example, and I did it
because of the incorrect spec of cache-request-directive. I am not
sure I am willing to implement this, so I probably shouldn't write
anything about it (ie I do beleive HTTP caching is complex enough)
> 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.
Yes,
> > 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 guess I was taking the semantic shift into account: I should have
written "private means that the fields can only be cached by private
caches, and no-cache means they cannot be cached by shared caches" (if
private and shared are meant to be exclusive, then I have to agree
"no-cache=<fields>" is not really usefull - which I am most happy
with)
BTW: It took me effectively some time to understand the semantics of
"no-cache=<field-names>"
> 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.
Understanding all the cache control directives is probably the
trickiest part of the HTTP spec (for some good reasons). I think the
thing that would really help is to provide (at least) a set of std
algorithms (the tables we have been working on for example along with
the various functions).
Anselm.