Re: Push and Caching

Martin Thomson <martin.thomson@gmail.com> Tue, 26 August 2014 18:41 UTC

Return-Path: <ietf-http-wg-request@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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4E1A01E8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 11:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.67
X-Spam-Level:
X-Spam-Status: No, score=-7.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 3EtMMpHAK5Dq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 11:41:16 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0971A01C5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Aug 2014 11:41:16 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XMLdO-00056X-I1 for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Aug 2014 18:38:22 +0000
Resent-Date: Tue, 26 Aug 2014 18:38:22 +0000
Resent-Message-Id: <E1XMLdO-00056X-I1@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XMLd4-00055f-1a for ietf-http-wg@listhub.w3.org; Tue, 26 Aug 2014 18:38:02 +0000
Received: from mail-la0-f47.google.com ([209.85.215.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XMLd2-0002rc-PQ for ietf-http-wg@w3.org; Tue, 26 Aug 2014 18:38:01 +0000
Received: by mail-la0-f47.google.com with SMTP id mc6so15249926lab.6 for <ietf-http-wg@w3.org>; Tue, 26 Aug 2014 11:37:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gH7FV02bchCqoZBfAnNOlo9/wPxAQSjheOXu0DPJKKc=; b=NGf0CtBKq+iMnp2XmxmfTmRSFFwZui5KgLUe3h+ejMpIDn1sQArD1Q6ocwTg0OmyST dvNXu3bywgf+pWmYSBZbkTEXEsNCczRNiMEGiJB2F9ZhvtSI128st5vJPYwADDPI4Yps Wt89Jzmaatc5ZtW0Dfu8ZXbm2tnBSyrk51M2wTuje67WCznd1sEM5bafOD2rd7RIF8dT 0NVaqUXdExUvOQ2rbneF5j8L7kEeDkfVYu3+NMkHWmeJuPtqvYEHllkCeje6rRbpNYlw hmBVVXVKJCc2G9QKHWJcNQdH3iGxVD5kg6dP0TgWgvVaqbEVg12got0Be8wdKHmXk+vX TurQ==
MIME-Version: 1.0
X-Received: by 10.152.87.97 with SMTP id w1mr4445063laz.92.1409078253776; Tue, 26 Aug 2014 11:37:33 -0700 (PDT)
Received: by 10.25.166.75 with HTTP; Tue, 26 Aug 2014 11:37:33 -0700 (PDT)
In-Reply-To: <22238EC5-50F4-4611-9FED-39E3D7B67B10@gbiv.com>
References: <dc3d860ecb4b4d408a5ed0519a036e61@BL2PR03MB132.namprd03.prod.outlook.com> <CABkgnnWvKgyDcm-1jEKZUA2Qza9M46X+X_QybwuqRwvSUrTjNw@mail.gmail.com> <B6B89855-237F-44DA-B29C-2A3BB5CE0EED@mnot.net> <920b92b90a3c47ef8d450c903b83af40@DM2PR05MB670.namprd05.prod.outlook.com> <d94a3acceb954583a61b0118381df417@BL2PR03MB132.namprd03.prod.outlook.com> <CAOdDvNpa5WR4LJbsgQaBE3bTSAc+gXfYqCmV+zmUzE5b7+1a9A@mail.gmail.com> <CECA0C1A-E64C-443A-87AF-22BC66286F72@mnot.net> <CABkgnnXVJA3R4qhc__k4j+_LzeS7B24VxfCZwBSfywepEx=tKA@mail.gmail.com> <40d03e3bb1df480e808e64fa29048880@BL2PR03MB132.namprd03.prod.outlook.com> <CABkgnnX-0X+JZfFYhm18b=bLidaq_pqN5s-K0NBS28m-s6+9Kg@mail.gmail.com> <233C8C21-BF80-4E07-9717-56630085E192@mnot.net> <CABkgnnW9Uq5R1KvuTXuT=xUdX_pVWikyAOMp=ixJe+c0NRs4Lg@mail.gmail.com> <CAH_y2NHV_966DSX4yX-=tfDPUkk-obCXFbJnPifQpFb1KFjYDg@mail.gmail.com> <7d2fdc975fec4646b21e86620a834e72@DM2PR05MB670.namprd05.prod.outlook.com> <2C38B85E-7290-4AE3-A886-12A329DE449C@mnot.net> <CACweHNAxpaZRsK-Uu5biSvzt3kLhY4Bcw4pQgXSVcKYmKK-E_w@mail.gmail.com> <D92F296B-3E9A-42B3-978C-AC319C072C60@mnot.net> <9C64D35C-49BF-47F7-8D72-EFA2DA546FEA@gbiv.com> <22238EC5-50F4-4611-9FED-39E3D7B67B10@gbiv.com>
Date: Tue, 26 Aug 2014 11:37:33 -0700
Message-ID: <CABkgnnWssBqVw+aSb_8y80JBRWkQ8H+MPvmYZ7MyzOkYUQwWTQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.215.47; envelope-from=martin.thomson@gmail.com; helo=mail-la0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.730, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1XMLd2-0002rc-PQ 5d5b702a1fc97d0dd31fbbc568caeddc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Push and Caching
Archived-At: <http://www.w3.org/mid/CABkgnnWssBqVw+aSb_8y80JBRWkQ8H+MPvmYZ7MyzOkYUQwWTQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26744
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 26 August 2014 09:59, Roy T. Fielding <fielding@gbiv.com> wrote:
> "A recipient cache SHOULD consider a pushed response to be valid for the
> duration of the connection (or until it is replaced during that connection)
> even if the pushed response contains cache directives that would normally
> indicate that the response is immediately stale."

Given the long-lived nature of HTTP/2 connections is this really the
right bound on validity?  It's not as though the server is guaranteed
an opportunity to replace/invalidate the response.

I'm a little leery of implying something about regular response
validity in this context.  I couldn't find anything concrete in RFC
7234 about the period over which a response can be considered valid
once it arrives at the client.  The best I could find was: "A cache
need not validate a response that merely became stale in transit."

If anything 7234 uses validation in the instantaneous sense
exclusively.  Freshness seems to be the only concept that is
associated with a time period, but we're carefully avoiding that here.
This, to my reading, is breaking new ground.  And people are right to
notice the prefetch and request combining features as having
interactions with this, even though those seem to be confined to web
use cases.

I don't think that this is a defect of RFC 7234, but it's an issue
that I'd prefer to see addressed more comprehensively than just for
push.

...and that's mainly why I suggested the "at the time that the
response is generated".