Re: ID for Immutable

On 29/10/2016 4:41 a.m., Kari Hurtta wrote:
> Alex Rousskov wrote: (Fri Oct 28 18:23:54 2016)
> [ Charset windows-1252 converted... ]
>> On 10/28/2016 08:44 AM, Kari Hurtta wrote:
>>> If server can't calculate hash-function over resource,
>>> is is really static non-caching resource?
>>
>> There is sometimes a big difference between the _ability_ to calculate a
>> hash and the _expense_ of doing so. AFAICT, immutable responses may
>> still be dynamically generated (or otherwise costly to produce) on the
>> origin server.
>>
>> For example, loading, encoding, and hashing a 2-hour video of the 1948
>> Olympics opening ceremony could be rather expensive, but will produce
>> the same immutable result [until the server has to inject a fresh set of
>> advertisements sometime tomorrow].
> 
> Yes, that is valid concern.
>  
>> Alex.
> 
> 
> And calculating may be even mode expensive for client. Server
> needs do it only once. Not for every request. After all supposed usage 
> was that resource for same URL is not updated. 
> 
> So new advertisements produce new URL for that a 2-hour video of the 
> 1948 Olympics opening ceremony.
> 
> But these cases client anyway will not cache resource so
> immutable does not help.
> 
> / Kari Hurtta
> 


Verification of the response is orthoginal to being immutable.

The client application can use many independently defined approaches to
check what it gets from the server (or proxy). If it detects corruption
it can send a request containing "Cache-Control: no-cache" which should
cause replacement of the 'corrupt' object in any intermediary caches
along the way.

Amos

Received on Sunday, 30 October 2016 02:56:21 UTC