- From: Anselm Baird_Smith <abaird@www43.inria.fr>
- Date: Tue, 7 Jan 1997 09:03:16 +0100 (MET)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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.
Received on Tuesday, 7 January 1997 00:09:02 UTC