Re: ID for Immutable

Amos Jeffries <squid3@treenet.co.nz> Sun, 30 October 2016 03:00 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4A12956D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 29 Oct 2016 20:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.498
X-Spam-Level:
X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnA52uZnaa6O for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 29 Oct 2016 20:00:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1703F126D74 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 29 Oct 2016 20:00:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c0gIN-000874-EW for ietf-http-wg-dist@listhub.w3.org; Sun, 30 Oct 2016 02:56:27 +0000
Resent-Date: Sun, 30 Oct 2016 02:56:27 +0000
Resent-Message-Id: <E1c0gIN-000874-EW@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1c0gIG-00084x-VY for ietf-http-wg@listhub.w3.org; Sun, 30 Oct 2016 02:56:21 +0000
Received: from [121.99.228.82] (helo=treenet.co.nz) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <squid3@treenet.co.nz>) id 1c0gI9-0000Fn-9b for ietf-http-wg@w3.org; Sun, 30 Oct 2016 02:56:15 +0000
Received: from [192.168.20.251] (unknown [121.98.45.78]) by treenet.co.nz (Postfix) with ESMTP id 764D2E6EAA for <ietf-http-wg@w3.org>; Sun, 30 Oct 2016 15:55:41 +1300 (NZDT)
To: ietf-http-wg@w3.org
References: <CAOdDvNqam930_0eA1p3yHW+xDdOm0AAMKvVKe6xwNwm1itpRpQ@mail.gmail.com> <20161028144407.48EFF162D1@welho-filter4.welho.com> <2eaa785f-8736-f677-db11-7595fae3eb9a@measurement-factory.com> <201610281541.u9SFfV6u025712@shell.siilo.fmi.fi>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <02d5bf20-8b2e-1e90-1d44-0fd8ed2c735e@treenet.co.nz>
Date: Sun, 30 Oct 2016 15:55:04 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <201610281541.u9SFfV6u025712@shell.siilo.fmi.fi>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.271, BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c0gI9-0000Fn-9b 2e616f53987aa5d89b5ffa656a4b0953
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ID for Immutable
Archived-At: <http://www.w3.org/mid/02d5bf20-8b2e-1e90-1d44-0fd8ed2c735e@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32728
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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