- From: Shel Kaphan <sjk@amazon.com>
- Date: Thu, 15 Feb 1996 14:46:12 -0800
- To: hardie@nasa.gov
- Cc: Shel Kaphan <sjk@amazon.com>, hardie@nic.nasa.gov, masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Ted Hardie writes: > Thanks for your explanation. If we believe that proxies should reload > pages as they pass by (even if they have a copy they think is "good"), > then I suspect we should use cache-control: reload, rather than > cache-control: no-cache. That language makes it clear enough that the > proxy will and should update its copy. I believe it was Jeff Mogul's intention to use that language to signify ``reload from the origin server'', not ``reload into your cache''. Isn't English wonderful? With cache-control: no cache, > an implementor might assume that the directive was to be used when the > user agent did not want integrity checks to be applied or did not want > the results of the request stored in that cache (some info might not be > appropriate for a public cache, for example). > > Ted Hardie > NASA Science Internet This points to the likelihood of confusion when overloading the same token (``no-cache'') with a meaning in both requests and responses. In Roy's proposed spec for HTTP 1.1, cache-control: no-cache in requests indicates that the request cannot be serviced by any intermediate server -- only the origin server. In responses, cache-control: no-cache indicates that the response cannot be stored in a cache. So the hypothetical implementor you describe would be wrong to make that assumption. --Shel
Received on Thursday, 15 February 1996 14:52:08 UTC