Re: Comments on Byte range draft

Jeffrey Mogul writes:
 >     I agree that there should be some *opaque* string used to select if the
 >     object is the same or not (string which could be for instance a last
 >     modified date, an MD5 digest,... whatever the server wants)
 >     And the client could for instance blindy use what the server sent as
 >     Content-Digest: (for instance, but we could use a different name if that
 >     one is 'burned' ;-) )
[rest of my suggestion, which gave more information about how
"flexibility" of the digest can be used to make the thing really
opaque was deleted by Jeffrey]
 > I would recommend against using the Content-Digest as the
 > cache-authenticator.  This means that if a server wants to control
 > caching, it is forced to generate a Content-Digest that is also
 > semantically correct for whatever other uses a Content-Digest
 > is useful for.
 > In short, Content-Digest is NOT opaque to the client.
As I said, It can be made, just a matter of defining the correct
behaviour, see below. (as content-digest: does not yet exists, it is
still possible to state precisely several cooperating utilisations)
 > It also means that the server must either re-digestify the object
 > to do a validity check, or keep a database of Digest values.
This is not a problem, as the "digest" can be anything server wants 
 > If the server wants to use a simpler scheme (such as file modification
 > time) to generate a validator, it should be able to do so.
It can, As I gave in exemple (did you read?) there is no problem using
which couple is opaque
ie it is ok to have (again from my exemple):
Content-Digest: date="Tue Nov 14 21:18:28 MET 1995"
or whatever the server wants
Content-Digest: private="816380285"
which is faster to compare, or whetever...

anyway, again, if you can't bare the name, its no problem for me to
use another one 
(though suggesting server implementation based on digest is probably
the safest (compared to date stuff))

Laurent Demailly * * Linux|PGP|Gnu|Tcl|...  Freedom
Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept

Received on Tuesday, 14 November 1995 12:34:04 UTC