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

Re: Data Integrity

From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 15 Feb 1996 14:46:12 -0800
Message-Id: <199602152246.OAA02303@bert.amazon.com>
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 EST

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