RE: Call for Adoption -- Cache-Control: immutable

Mike Bishop <> Thu, 08 December 2016 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C37E129561 for <>; Thu, 8 Dec 2016 12:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.897
X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DfAGBqnehMHl for <>; Thu, 8 Dec 2016 12:31:33 -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 1270012957D for <>; Thu, 8 Dec 2016 12:31:32 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cF5It-0002lK-IT for; Thu, 08 Dec 2016 20:28:31 +0000
Resent-Date: Thu, 08 Dec 2016 20:28:31 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cF5Ik-0002kJ-N8 for; Thu, 08 Dec 2016 20:28:22 +0000
Received: from ([] by with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cF5Ic-0000on-BY for; Thu, 08 Dec 2016 20:28:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GFS6ScMwP027BbwfnJTav3QRUHXW4GIdZtg2e7laJ9c=; b=OVJySfnO6SEm2L9N6t6KfdPQRn+QyoXKXqDv4CFKUDZD7HOi9+mGKngVJwkuiw8XKp5TelmQfKNQmRjiLA5Z8E2wEkL6JXtugNRJMcMoAr4VYvQmoXBSTuBoCFhiwEGNP6WzPR7OjnjFbw8m1r8r04waJ2LT5uCoJD+O7fvIOLw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Thu, 8 Dec 2016 20:27:46 +0000
Received: from ([]) by ([]) with mapi id 15.01.0747.021; Thu, 8 Dec 2016 20:27:46 +0000
From: Mike Bishop <>
To: "Martin J. Dürst" <>, Mark Nottingham <>, HTTP Working Group <>
CC: Patrick McManus <>
Thread-Topic: Call for Adoption -- Cache-Control: immutable
Thread-Index: AQHSUQh8YrGn09l1wEaoi1n8t44eR6D9ewqwgAAINwCAAPuTkA==
Date: Thu, 08 Dec 2016 20:27:46 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:b::51f]
x-ms-office365-filtering-correlation-id: 06173eec-d251-4343-2999-08d41fa8ac26
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708;
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:dDlfaEvL885JNGT8HGyN4MLTnhCjmwl4z5GiEod2iPaIQMX5jKE0PGYkkJvhUlSUe0mOI0rxt83zeSFQq0oHylRPO4ohl/hjES5O56U/uBXNDj4KbvPxur2xC6Ps8oSIN7ZfPbGVC6km6urtPG8O9oFWNwe+Owcwqcq/1Q0ZSuOd1d7IPYIMJHDNUHRERZi2mp5KP8icq0nsjJ91p1nyWQwX0AmMhR8dc9ngro4J7+AZDpf60O+a6P2M8deIOjkJsFTA29Tl//ilceb+jeH9TXUaVunfkuYRChIcNc4z1VaMrYUwBwT2003lJbN4M2qXCge3BT3tu8Gtt0BJhJpxz3eqp8x7Tf+csP6fl/zyFoY71X+Ld79cSGgayhhTwHQueeTXuixivMA4pHVDH7aKZDl6bzWsX/ICsGqTd1Tb0cwkCeHpiDKGgVmAPH+f/wSnz3+HpKDa/4rz0ZIyuXxw/QJTnCgRzdposmpgQfgBnks=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(211936372134217);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6047074); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 0150F3F97D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39860400002)(39450400003)(13464003)(51444003)(377454003)(199003)(189002)(24454002)(7696004)(97736004)(229853002)(9686002)(68736007)(2906002)(86612001)(575784001)(86362001)(77096006)(5001770100001)(81156014)(189998001)(122556002)(4326007)(5660300001)(2950100002)(8936002)(38730400001)(81166006)(8676002)(8990500004)(2900100001)(76176999)(33656002)(54356999)(101416001)(76576001)(50986999)(92566002)(3280700002)(3660700001)(6116002)(106116001)(99286002)(106356001)(102836003)(105586002)(305945005)(10090500001)(74316002)(6506006)(5005710100001)(6436002)(7736002)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 20:27:46.5668 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.437, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1cF5Ic-0000on-BY e07c30a700be08c9dbb331f099ff2c7d
Subject: RE: Call for Adoption -- Cache-Control: immutable
Archived-At: <>
X-Mailing-List: <> archive/latest/33137
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Shift-Reload is different still -- all requests go out without looking at the cache in the first place.  So you see unconditional requests, rather than revalidations, and always get fresh content.  If those responses are cacheable, they still get added to the cache later, though.

The one situation I've thought of is that a change to browser behavior only gets the updated clients, whereas "immutable" supported in a proxy can effectively help every client behind them, updated or not.  However since immutable restricts itself to HTTPS, which is less likely to be proxied, how *much* larger is a very open question.

-----Original Message-----
From: Martin J. Dürst [] 
Sent: Wednesday, December 7, 2016 9:20 PM
To: Mike Bishop <>; Mark Nottingham <>; HTTP Working Group <>
Cc: Patrick McManus <>
Subject: Re: Call for Adoption -- Cache-Control: immutable

On 2016/12/08 13:55, Mike Bishop wrote:
> I'm generally favorable toward this idea, but will note one open question in my mind:  This seems to be very tightly tied to the scenario of hitting refresh on a page whose content frequently changes but whose dependent resources don't.  Putting "immutable" on those dependent resources helps reduce the server load and time taken when the user hits refresh, either in their own local cache or in proxies that are on path to the site.
> There seems to be a parallel discussion (see for Chrome's) about softening the behavior of the refresh button to avoid force-refreshing all dependencies, which would likely have the same results.  Can someone point me to a scenario in which both are worth doing, or is this really a pair of mutually-sufficient solutions to the same problem?

There's a big difference between what is ideal (or close to ideal) for development and for production,...

For development, you want the "always reload everything" behavior. For production, you hopefully don't need that anymore. So the browser-side solution with a switch between "really reload everything" and "reload, but with moderation" could work. I think that at some time, Ctrl-R did the later, and Ctrl-Shift-R did the former on some browsers.

There are other tricks you can play. Some frameworks (e.g. Rails) add a number for a "stable" resource and increase the number every time that resource is changed.

Overall, it's probably possible to imagine an ideal world where only one such mechanism is used, but because neither browsers nor servers (and the stuff served by them) are perfect, we usually end up with needing more than one mechanism.

Regards,   Martin.