Re: ID for Immutable

Amos Jeffries <> Tue, 08 November 2016 04:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9866C1294AB for <>; Mon, 7 Nov 2016 20:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.398
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xwHDHMWwfBn4 for <>; Mon, 7 Nov 2016 20:34:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31B15129406 for <>; Mon, 7 Nov 2016 20:34:06 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c3y3B-0001jX-Fr for; Tue, 08 Nov 2016 04:30:21 +0000
Resent-Date: Tue, 08 Nov 2016 04:30:21 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c3y32-0007Z8-AY for; Tue, 08 Nov 2016 04:30:12 +0000
Received: from [] ( by with esmtp (Exim 4.84_2) (envelope-from <>) id 1c3y2w-0004Jy-3T for; Tue, 08 Nov 2016 04:30:07 +0000
Received: from [] (unknown []) by (Postfix) with ESMTP id DB2BEE6A52 for <>; Tue, 8 Nov 2016 17:29:32 +1300 (NZDT)
References: <> <>
From: Amos Jeffries <>
Message-ID: <>
Date: Tue, 8 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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=;;
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: 1c3y2w-0004Jy-3T e8e08780f42732b26e0e530c1dada7c8
Subject: Re: ID for Immutable
Archived-At: <>
X-Mailing-List: <> archive/latest/32854
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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

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.