Re: validators (was: Re: Koen's comments on...)

Jeffrey Mogul:
> [bne]:
> >   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.
I think anything useable for the second purpose is good for the first.
> 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.
I think, we have no good reasons to prefer opaque validators over other
validators.
Current practice has two headers useable as validators Last-Modified 
and Content-Length (I forgot this when making the table.)
RFC1864 defines the Content-MD5 header, which seems to me adoptable in
HTTP/1.1. (we should have an agreement on 'canonical format' before)
Designing a stable (guaranteed to change to a new unique value every
time when the content of the URI to be validated changes) opaque validator
scheme isn't a trivial job -
think of system crashes, filesystem implementation bugs.
> 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 that's simple waste of bandwidth!
> 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.
But if we have enough power to require opaque validators, then we have
approximately the same power to require any type except whose require
some license.

My questions are:
Is
Content-SEQN (I mean sequence number)
Content-SHA
Content-CRC (CCITT std 16 and/or 32 bit checksums)
Content-PGP-signature
Content-PEM-signature
(of course the last who would point to a different URI, containing the signature.)

worth of the effort putting them into the spec?

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Monday, 15 January 1996 05:58:29 UTC