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".
- Push and Caching Mike Bishop
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Greg Wilkins
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Mark Nottingham
- RE: Push and Caching William Chow
- RE: Push and Caching Mike Bishop
- Re: Push and Caching Patrick McManus
- Re: Push and Caching Mark Nottingham
- Re: Push and Caching Martin Thomson
- RE: Push and Caching Mike Bishop
- Re: Push and Caching Martin Thomson
- RE: Push and Caching Mike Bishop
- Re: Push and Caching Mark Nottingham
- Re: Push and Caching Greg Wilkins
- Re: Push and Caching Mark Nottingham
- Re: Push and Caching Mark Nottingham
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Mark Nottingham
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Mark Nottingham
- Re: Push and Caching Greg Wilkins
- RE: Push and Caching William Chow
- Re: Push and Caching Mark Nottingham
- RE: Push and Caching William Chow
- Re: Push and Caching Matthew Kerwin
- Re: Push and Caching Mark Nottingham
- Re: Push and Caching Chris Drechsler
- Re: Push and Caching Roy T. Fielding
- Re: Push and Caching Roy T. Fielding
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Roy T. Fielding
- Re: Push and Caching Michael Sweet
- RE: Push and Caching William Chow
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Roy T. Fielding
- RE: Push and Caching William Chow
- Re: Push and Caching Greg Wilkins
- Re: Push and Caching Greg Wilkins
- Re: Push and Caching Martin Thomson
- Re: Push and Caching Greg Wilkins