Re: ID for Immutable

Patrick McManus <mcmanus@ducksong.com> Thu, 27 October 2016 18:14 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 5CFA5129685 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 27 Oct 2016 11:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.851
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sendgrid.me
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 IpMjPONhL7NL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 27 Oct 2016 11:14:36 -0700 (PDT)
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 A4264129643 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 27 Oct 2016 11:14:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bzp7w-00048p-VM for ietf-http-wg-dist@listhub.w3.org; Thu, 27 Oct 2016 18:10:09 +0000
Resent-Date: Thu, 27 Oct 2016 18:10:08 +0000
Resent-Message-Id: <E1bzp7w-00048p-VM@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1bzp7o-0002SG-Ve for ietf-http-wg@listhub.w3.org; Thu, 27 Oct 2016 18:10:01 +0000
Received: from o1.7n.fshared.sendgrid.net ([167.89.55.7]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1bzp7g-00071K-1T for ietf-http-wg@w3.org; Thu, 27 Oct 2016 18:09:55 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=ihxfYEHavoMzFEesfqh59/IjDTo=; b=wmkQbIvEZUq0d1ncbz dnlEQ75Yne146l7wc1LIWpOMeMpNgmM6p89q2NBRLx9tjb2UUxza+coKnRL7WAP6 z9Y9ZDaLWmKw4nm9RaxWvOBacGTyaAZFumtOBUY6Hr6CtCCUyCuWeF49DHoHmGqh ve1CsovJGkmcFP30H5gVFTSoQ=
Received: by filter0603p1mdw1.sendgrid.net with SMTP id filter0603p1mdw1-15785-5812428F-40 2016-10-27 18:08:15.487500363 +0000 UTC
Received: from mail-yb0-f170.google.com (mail-yb0-f170.google.com [209.85.213.170]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id QEV5yzZeS1Og6xPbeUdGyg for <ietf-http-wg@w3.org>; Thu, 27 Oct 2016 18:08:15.430 +0000 (UTC)
Received: by mail-yb0-f170.google.com with SMTP id 205so9704047ybz.3 for <ietf-http-wg@w3.org>; Thu, 27 Oct 2016 11:08:15 -0700 (PDT)
X-Gm-Message-State: ABUngvcUrg6agJfoGs4cr9YBYGA98Q6hDa/pJpdkMRvpaaKJk3h7weodwhxaaKsKC8BYrDnsV5sfrymXypIBfA==
X-Received: by 10.36.126.203 with SMTP id h194mr11748850itc.47.1477591694723; Thu, 27 Oct 2016 11:08:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.228.236 with HTTP; Thu, 27 Oct 2016 11:08:13 -0700 (PDT)
In-Reply-To: <e1255f7b-6c04-576c-0e58-f5288eeeede1@treenet.co.nz>
References: <CAOdDvNqam930_0eA1p3yHW+xDdOm0AAMKvVKe6xwNwm1itpRpQ@mail.gmail.com> <f5bd0a86-57e2-7d6c-09a7-86d6a8639ce0@treenet.co.nz> <CAOdDvNrua_-RJfNz-+i1gN2tBH8wGXzGGGhL1MeLrsPqnAM0JQ@mail.gmail.com> <e1255f7b-6c04-576c-0e58-f5288eeeede1@treenet.co.nz>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Thu, 27 Oct 2016 14:08:13 -0400
X-Gmail-Original-Message-ID: <CAOdDvNqB01N2+YOggKsD8+kcYYkCU2jyeH4RrDVrGzLBYr_15w@mail.gmail.com>
Message-ID: <CAOdDvNqB01N2+YOggKsD8+kcYYkCU2jyeH4RrDVrGzLBYr_15w@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a113ac3d2165351053fdca08f
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh4KqjM3glLJq007jIE5PeJ9oeUPxNKc7yt46M jrhotV0/7Yc5DtTy9f5hGgZCLmoozWjRdMHqnffJHFa1F4NPMBiI00jNboHTYRoyfwqFARCWVqO388 Tgc68e+/BVymgtc0Q8gxeSFxiOXoOKdirIGs77ijq/TLfr61Wb2HiwhVH3/+5ULfHO4v6x9b19gTKr U=
Received-SPF: pass client-ip=167.89.55.7; envelope-from=bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net; helo=o1.7n.fshared.sendgrid.net
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=-0.236, 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.411, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1bzp7g-00071K-1T b96a813e9b5f1698ddecfe75ace14bbc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ID for Immutable
Archived-At: <http://www.w3.org/mid/CAOdDvNqB01N2+YOggKsD8+kcYYkCU2jyeH4RrDVrGzLBYr_15w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32693
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 Wed, Oct 26, 2016 at 10:23 PM, Amos Jeffries <squid3@treenet.co.nz>
wrote:

> On 27/10/2016 2:28 p.m., Patrick McManus wrote:
>
> > 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.
> >
>
> Hmm. Does that mean we need to update the output Date header with the
> amount which would otherwise be in Age?
>
> Which makes me wonder if immutable needs to be forbidden on responses
> with heuristic freshness. The current wording does not differentiate
> between explicit and heuristic freshness.
>
> If we adjust the Date in the absence of a Last-Modified we could be
> wrongly extending the freshness period estimated by downstream caches.
>
>
I think you've gotten me to change my mind on Age > 0. I wrote that
concerned that a client unaware of immutable would get cranky at seeing
"Age: 30" in response to a request with "max-age: 0". But I don't really
have any evidence of that, nor upon reflection would I really expect anyone
to care as long as the Age was correct.

The alternative, as you point out, is messing with the end-to-end headers..
like Date. And that's definitely worse.

So I'll change my position and say the proxy should just send the cached
response in the way it normally would for a full cache hit. (which could be
a 200 or 304 depending on whether the request was conditional or not). does
that make more sense?


>
>
> >
> >
> >> * how does immutable interact with the 'must not send on re-use'
> headers?
> >>  - ie. no-cache="Set-Cookie", private="Set-Cookie" and similar cases ?
> >>
> >
> [...]
>
> The main use-case for those controls using lists of header names is to
> force a revalidate to get new values per-client for those headers.
> Set-Cookie being the one seen most often, though others are possible.
>
> At present we revalidate stored responses with these controls so the 304
> from the server can produce any relevant new values for the new client.
>
>
as I understand this, your choice to revalidate the stored responses is an
implementation decision (no doubt a wise one!).. the spec allows you to
reuse the fresh content directly with (e.g.) set-cookie redacted but your
experience tells you that the revalidation makes more sense.

I don't think immutable really addresses the concern one way or the other..
it says that the same representation will come back, but the response
headers might indeed be different just as they may be different on a 304 vs
200. If I were you I would keep doing the revalidation, but because you
aren't required to do so in the first place I'm not sure what the spec
would say about that.

and honestly, as noted in the specs, the qualified forms of no-cache and
private are often treated as unqualified forms.. so I wouldn't expect folks
to be declaring immutable content with them as it requires fresh cached
content to work. your trick to store it and revalidate it to pick up new
headers is clever and should just carry on :)