Re: ID for Immutable

Patrick McManus <> Thu, 27 October 2016 01:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D063112960A for <>; Wed, 26 Oct 2016 18:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.851
X-Spam-Status: No, score=-6.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, 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 VSR1rxKfy9RT for <>; Wed, 26 Oct 2016 18:33:47 -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 24F2B1295D6 for <>; Wed, 26 Oct 2016 18:33:46 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bzZVY-0007Ct-8y for; Thu, 27 Oct 2016 01:29:28 +0000
Resent-Date: Thu, 27 Oct 2016 01:29:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bzZVT-0007BC-94 for; Thu, 27 Oct 2016 01:29:23 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1bzZVJ-0008Pu-Hg for; Thu, 27 Oct 2016 01:29:18 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=VA/QaM7ZQ/DVoSjbl2y9q0kuwsE=; b=hezJ8wG6IxTUO0wd0/ eegvWQQM0LyWseLryXEdAlvStsEmyrfpNWfESSWlzE5DJQ6d63rLl6UIYd6dlePK BjPk/P4Ut49MDibsFq+UNZmFuvGLqXSeH2+FBriu4UOmipu3RrFjM9pk0IOR7gBV 9AZoyJEnKSqt1RAvWt8ZOME3o=
Received: by with SMTP id filter0170p1las1-23496-5811584D-49 2016-10-27 01:28:45.718495692 +0000 UTC
Received: from ( []) by (SG) with ESMTP id -Hcn4WKKQOSkLRqZE_XPGg for <>; Thu, 27 Oct 2016 01:28:45.570 +0000 (UTC)
Received: by with SMTP id y2so24580828oie.0 for <>; Wed, 26 Oct 2016 18:28:45 -0700 (PDT)
X-Gm-Message-State: ABUngve3ySYFr5HqsJXhcuL0iosaDz0yOsF8l+VjJaAzl3vx3m3W3hvFehPmpp1Bw6vQEmOawTzVCXyX1IgJBg==
X-Received: by with SMTP id h137mr4987823ita.47.1477531724749; Wed, 26 Oct 2016 18:28:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Oct 2016 18:28:44 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Patrick McManus <>
Date: Wed, 26 Oct 2016 21:28:44 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Amos Jeffries <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=001a1147416a992548053fcea9ea
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh7pRk2ySaCQgP1wxFnJMy1k2qE67e23EQIzQL FCl8ipiVInLoCW+sjX+apuh2YnBUs6I0cm1+V2ZzGqjXgGIJJAACF4dUXcjAUbuULNPTKw/QwlX1JW xvz8CglJhvvAqCpQ8O85s/IzdZfBq1pBOFMfEox3I9x6vUjMGDjyVUCNnRjV1AmDOtEIA+9x8Y70tg A=
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.7
X-W3C-Scan-Sig: 1bzZVJ-0008Pu-Hg 9ab549d58d36f2745f017265530272ff
Subject: Re: ID for Immutable
Archived-At: <>
X-Mailing-List: <> archive/latest/32683
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

hey amos - thanks for the thoughtful reply. Let's work through these and
I'll incorporate it into a -01

On Wed, Oct 26, 2016 at 7:36 PM, Amos Jeffries <> wrote:

> This control seems like it will also be useful for proxy caches to
> prevent relaying the same revalidations from older clients that don't
> support the control.
> However the draft does not mention any proxy handling.
> * does it override must-revalidate etc on the stored response?
>  - what about proxy-revalidate?

my understanding is that must-revalidate and proxy-revalidate only apply to
stale responses. immutable only applies to fresh responses - therefore I
don't think it has any impact on *-revalidate handling.

> * does it override a client request max-age=0 and/or request no-cache?
>  - the stated intention implies that it does.
I think a request with no-cache means don't use the cache - so any
directives in the cache including immutable are irrelevant. (the draft
should say this about immutable). I wouldn't think requests bearing
no-cache are using revalidations anywhere along the chain - this is
normally the mechanism afaik used to correct corruption.

max-age=0 is messy, but I think OK, for a proxy cache to apply the
immutable logic to its stored fresh response. The alternative is really
just to revalidate it, but the meaning of immutable is that the
revalidation is going to return 304 during the freshness lifetime.

You would need to make sure not to send a Age > 0 in the response.

> * assuming immutable overrides those client reload signals; is the proxy
> supposed to deliver a 200, 304 or 4xx to clients sending max-age=0 ?
I don't think immutable impacts that much. The proxy has used immutable to
auto-revalidate its stored response.. whether it returns that to the
user-agent as a 200 or 304 I would assume would depend on whether the
user-agent made a conditional request.

> * how does immutable interact with the 'must not send on re-use' headers?
>  - ie. no-cache="Set-Cookie", private="Set-Cookie" and similar cases ?

you're going to have to walk me through what you're thinking here because
I'm not immediately seeing the relevance. Immutable allows a client
(including a proxy) that is about to make a conditional request for a fresh
stored response to know that it is going to receive a 304 for that before
doing so and therefore avoid the transaction if it chooses to. Are you
suggesting that the resource varies by cookie or somesuch? I would think
that would be taken into account in the general logic of "do I have a fresh
resource for this request" logic.