Re: ID for Immutable

Kari Hurtta <hurtta-ietf@elmme-mailer.org>: (Fri Oct 28 18:12:15 2016)
> Patrick McManus <pmcmanus@mozilla.com>: (Fri Oct 28 17:50:16 2016)
> > the notion of integrity hashes have failed in the past (notably md5)..

And anyway even MD5 is good enough for this purpose. Something like
crc32 is not. For avoid making truncations immutable also resource
length in bytes is good enough for this purpose.

Server still known length of resource for a 2-hour video of the 1948
Olympics opening ceremony (using example of Alex Rousskov).

Server does not know resource length in bytes when it generates
response from database dynamically (in these cases also
content-length is not used but chunked transfer-encoding)

( Assuming that you do not put Cache-Control to
  trailer of chunked transfer-encoding. In that
  case also calculating hash of response is not 
  really expensive part here.
)

My favorite test query produces about 24 gigabytes answer 
(if I remember correctly). Yes, some variations
of this may be immutable, but I'm not sure that 
"immutable" cache-control is very usefull here.

( These have nice property that any 32 bit counters
  wrap several times and loading that answer takes
  several hours. 
)

> > separable from immutable imo and would rather not tie that anchor to its
> > fate.
> 
> That why I wrote "Several immutable cache controls are invalid if they are result
> of same hash-function" implying that hash-function is detectable
> from result of function (Either by size or something like multihash
> https://github.com/multiformats/multihash).
> 
> > > So that immutable does not have effect if result of hash-function
> > > does not give same value that what is value of immutable
> > > cache control.
> > >
> > > Several immutable cache controls are invalid if they are result
> > > of same hash-function.

/ Kari Hurtta

Received on Saturday, 29 October 2016 05:31:21 UTC