Re: ID for Immutable

Amos Jeffries <squid3@treenet.co.nz> Tue, 08 November 2016 04:34 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 9866C1294AB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Nov 2016 20:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xwHDHMWwfBn4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Nov 2016 20:34:07 -0800 (PST)
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 31B15129406 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 7 Nov 2016 20:34:06 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c3y3B-0001jX-Fr for ietf-http-wg-dist@listhub.w3.org; Tue, 08 Nov 2016 04:30:21 +0000
Resent-Date: Tue, 08 Nov 2016 04:30:21 +0000
Resent-Message-Id: <E1c3y3B-0001jX-Fr@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 1c3y32-0007Z8-AY for ietf-http-wg@listhub.w3.org; Tue, 08 Nov 2016 04:30:12 +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 1c3y2w-0004Jy-3T for ietf-http-wg@w3.org; Tue, 08 Nov 2016 04:30:07 +0000
Received: from [192.168.20.251] (unknown [121.98.41.216]) by treenet.co.nz (Postfix) with ESMTP id DB2BEE6A52 for <ietf-http-wg@w3.org>; Tue, 8 Nov 2016 17:29:32 +1300 (NZDT)
To: ietf-http-wg@w3.org
References: <CAOdDvNqam930_0eA1p3yHW+xDdOm0AAMKvVKe6xwNwm1itpRpQ@mail.gmail.com> <901964AC-3423-4789-934F-3C583214ED85@ogre.com>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <98a1f481-af93-3556-2c08-72e3fc8e3482@treenet.co.nz>
Date: Tue, 08 Nov 2016 17:29:12 +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: <901964AC-3423-4789-934F-3C583214ED85@ogre.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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.3
X-W3C-Hub-Spam-Report: AWL=-1.237, 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 1c3y2w-0004Jy-3T e8e08780f42732b26e0e530c1dada7c8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ID for Immutable
Archived-At: <http://www.w3.org/mid/98a1f481-af93-3556-2c08-72e3fc8e3482@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32854
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 8/11/2016 10:20 a.m., Leif Hedstrom wrote:
> 
>> On Oct 26, 2016, at 3:02 PM, Patrick McManus wrote:
>>
>> [as individual]
>>
>> FYI
>>
>> A new version of I-D, draft-mcmanus-immutable-00.txt
>> has been successfully submitted by Patrick McManus and posted to the
>> IETF repository.
> 
> 
> Interesting. Couple of quick thoughts with my proxy-server hat on.
> 
> 1) Many (most?) reverse proxy servers has features to ignore e.g. Cache-Control: max-age=0, or Cache-Control: no-cache from the clients. Not doing so would really open up some ugly rat holes for cache busting. [See the ATS configs below].
> 
> 2) As such, this new CC: immutable directive seems geared primarily towards user-agents and possibly for forward proxies?
> 

It is also proving to be useful for the other types of proxy, to reduce
the need to explicitly configure overrides that abuse the normal HTTP
behaviour. Such as you mention below in your 'PS'.


> 3) I didn’t read particularly carefully, but would it make sense to specify exactly what headers a proxy would ignore in favor of CC: immutable? I’m thinking in my case, we’d honor a CC: immutable over some of our configuration options [again see below].
> 
> For 3), I believe most clients will send something like 
> 
> 	Cache-Control: no-cache
> 	Pragma: no-cache
> 
> correct when doing a “force” revalidate? I understand that this is UA specific, but if we are going to say something about this for intermediaries, maybe worth pointing this out? If so, what about Cache-Control: max-age=0?
> 

In previous posts of this thread we (Patrick, Martin, myself) have
concluded that immutable must not have any effect on no-cache from the
client.

It should only prevent backend revalidation of fresh content. Such as
that triggered by max-age=N (any N) or If-Modified-Since from the client.

Hopefully the next draft iteration will make all that a lot clearer.


> Cheers,
> 
> — leif
> 
> P.s
> Apache Traffic Server settings (defaults):
> 
> 	CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1
> 	CONFIG proxy.config.http.cache.ignore_client_cc_max_age INT 1
> 
> P.P.s
> Yes, we know this violates the RFC :-).
> 

AIUI, immutable should make the second one much less useful.

The first in my experience leads to more user complaints about broken
pages than its worth, but YMMV. In Squid we provide a control to convert
the no-cache into a revalidate request to the backend. That avoids the
cache busting aspect while still allowing data updates when reload is
actually needed.

Cheers
Amos