- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 11 Jan 96 11:53:01 PST
- To: "Balint Nagy Endre" <bne@bne.ind.eunet.hu>
- Cc: http-caching@pa.dec.com (http WG caching subwg)
I think we should support any of them, and data owners /service authors can
choose the appropriate validators for a particular URL.
The prioritised list is: digest checksum opaque timestamp.
I think your useful table makes some interesting points. However, we
should be careful to separate the concepts of checking cache validity
from those of checking content integrity.
If the server prefers to use a content-based scheme (such as a CRC or
hash) to check the validity of cached responses, it can easily do so by
using one of these values as its opaque validator. Remember that this
places no requirement on the client to actually compute the CRC or hash
(so, for example, a server could use a proprietary hash or even an
export-controlled algorithm). Since the client simply returns the
validator value it got from the server, it need not care if the server
is using a hash.
If the server transmits a hash using a header field such as
Content-MD5:, then the client or cache can use this for the purpose of
checking integrity. And nothing prevents the server from transmitting
the same value in both the Cache-validator: and Content-MD5: fields,
but we should be clear that this is for two different purposes and
results in two different kinds of client behavior. The value sent in
the Cache-validator: must be used for conditional requests, which
requires no computation at the cleint; the value sent in the
Content-MD5: header may be used to check integrity, which does require
client computation.
Anyway, it's not up to the caching subgroup to debate whether clients
and servers may/should/must use explicit digest or CRC headers.
-Jeff
Received on Thursday, 11 January 1996 20:05:03 UTC