W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

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

From: Anselm Baird_Smith <abaird@www43.inria.fr>
Date: Tue, 7 Jan 1997 09:03:16 +0100 (MET)
Message-Id: <199701070803.JAA20410@www43.inria.fr>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:25 EDT