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

At 06:39 AM 1/15/96 +0100, Balint Nagy Endre wrote:
>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.)

Someone has already complained vehemently against using length as a cache
validators however.  (Was it Chuck from StarNine?)  The problem is, if we
define what the validator is, we burden the server with doing the validation
computation, and the server might not be willing to do that validation
computation.  For instance, to use the example Chuck gave: a server might do
end-of-line translations on the content before sending it out, and in order
to do a validation for a IMS request, it has to open the file and do those
translations needlessly.  In order to appease Chuck, we let the server
decide what it's validation scheme is.  Maybe Chuck has meta-information
about that content body more readily available to him.  Maybe he wants to a
an MD5, maybe he just wants to use the date.  It's the server's choice here.
That's what the benefit of an opaque validator is.

>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.

I don't see how these things particularly hurt the opaque validator scheme.
These issues can also affect IMS times.  the worst case scenario is that
caches become invalidated and the thing has to be resent.  Bugs are bugs.
We can't design the protocol to remove bugs.

>> 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!

The price we pay for distinguishing between cache validation and content
integrity mean we might have overlapping resource expenditures.  So be it.

>> 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-FooOne,Content-FooTwo...]
>worth of the effort putting them into the spec?

I have to agree with Jeff.  These are Content integrity checks and aren't
appropriate discussion for the caching subgroup.  Cache validation IS
appropriate.

-----
Dan DuBois, Software Animal           http://www.spyglass.com/~ddubois/
    Download a totally free copy of the Spyglass Web Server today!
   Not a demo copy, not an eval copy.  Four times faster than NCSA.
        http://www.spyglass.com/products/server_download.html

Received on Tuesday, 16 January 1996 17:06:50 UTC