Re: ID for Immutable

Amos Jeffries <> Sun, 30 October 2016 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36AEC129612 for <>; Sat, 29 Oct 2016 20:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.498
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S-XCGRfRWhHN for <>; Sat, 29 Oct 2016 20:20:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83F761295DD for <>; Sat, 29 Oct 2016 20:20:22 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c0gbU-00041x-SP for; Sun, 30 Oct 2016 03:16:12 +0000
Resent-Date: Sun, 30 Oct 2016 03:16:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c0gbQ-00041G-B1 for; Sun, 30 Oct 2016 03:16:08 +0000
Received: from [] ( by with esmtp (Exim 4.84_2) (envelope-from <>) id 1c0gbK-0002zu-44 for; Sun, 30 Oct 2016 03:16:03 +0000
Received: from [] (unknown []) by (Postfix) with ESMTP id 48C24E6EAA for <>; Sun, 30 Oct 2016 16:15:28 +1300 (NZDT)
References: <> <> <>
From: Amos Jeffries <>
Message-ID: <>
Date: Sun, 30 Oct 2016 16:15:20 +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: 7bit
Received-SPF: pass client-ip=;;
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: 1c0gbK-0002zu-44 fec2b7d9611f0307dc58543e25956b27
Subject: Re: ID for Immutable
Archived-At: <>
X-Mailing-List: <> archive/latest/32729
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 29/10/2016 6:21 a.m., Patrick McManus wrote:
> I do believe the lack of integrity protection in plaintext transfer is an
> important security consideration for immutable that suggests they should
> not be used together. I'm open to other wording on it for sure.. https://
> might be sufficient here.

Since the behaviour which 'immutable' is defining is already optionally
followed by any cache implementation in both insecure and secure
contexts. There is no additional security considerations being added by
this option.

The security considerations around corrupt objects being considered
"fresh" applies to HTTP caching in general, not just immutable objects.

The issues that are being pointed out are real, but apply equally for
secure and for insecure contexts already today without immutable being
involved. I dont see any need to distinguish between contexts in this
draft, nor to prohibit 'insecure' contexts from having immutable objects.

To back this; Squid has for a very long time had a configuration control
which enables admin to mark specific URL as having this same immutable
behaviour. It is one of the more popular ones and used in the 'insecure

AFAIK, the only issue which has come to light in all that time that can
be attributed to this control is that objects changing faster than what
the admin was aware (or their stated expiry time) had to be manually
refreshed from the client end (if anyone actually cared). Moving the
control point from proxy config to origin server avoids that issue.