Re: Push and Caching
"Roy T. Fielding" <fielding@gbiv.com> Tue, 26 August 2014 19:08 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 135FA1A0166 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 12:08:04 -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 Senns8aynQyE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 12:08:01 -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 790F81A0258 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Aug 2014 12:08:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XMM3p-00051y-0J for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Aug 2014 19:05:41 +0000
Resent-Date: Tue, 26 Aug 2014 19:05:41 +0000
Resent-Message-Id: <E1XMM3p-00051y-0J@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1XMM3Z-0004yk-Iw for ietf-http-wg@listhub.w3.org; Tue, 26 Aug 2014 19:05:25 +0000
Received: from sub4.mail.dreamhost.com ([69.163.253.135] helo=homiemail-a97.g.dreamhost.com) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1XMM3Y-0000Hf-Hn for ietf-http-wg@w3.org; Tue, 26 Aug 2014 19:05:25 +0000
Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 99022286074; Tue, 26 Aug 2014 12:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=4sizJ7+HX6I7uAfJ05aHu/YwAtM=; b=fYK/bX+u8kh9dGAndp8iOwplYpQy i0SMztnOd3KVfKBmQStJp7o2ln0JqtbzTbSyLvKkBXpJch/JO6ZxEKwTGYyhJktT ERvk6zfgtdTFazkLZ9f8WvLieeBDaw/tGde4LKUe8xflMgMUWkQbd/Xw2oiJ+Ujl sDyrqTpjdGpvdHw=
Received: from [192.168.1.5] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 810C328606F; Tue, 26 Aug 2014 12:05:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <CABkgnnWssBqVw+aSb_8y80JBRWkQ8H+MPvmYZ7MyzOkYUQwWTQ@mail.gmail.com>
Date: Tue, 26 Aug 2014 12:05:03 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE38D1FB-C9E1-441F-BDCE-9258714E0D96@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> <C ACweHNAxpaZRsK-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> <CABkgnnWssBqVw+aSb_8y80JBRWkQ8H+MPvmYZ7MyzOkYUQwWTQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=69.163.253.135; envelope-from=fielding@gbiv.com; helo=homiemail-a97.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.388, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: maggie.w3.org 1XMM3Y-0000Hf-Hn ce47c81b511160212036a05d25bc43a5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Push and Caching
Archived-At: <http://www.w3.org/mid/DE38D1FB-C9E1-441F-BDCE-9258714E0D96@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26745
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 Aug 26, 2014, at 11:37 AM, Martin Thomson wrote: > 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 would expect them to push another. Isn't that sufficient? > 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." Hmm, that effectively has the same meaning as what I proposed -- a pushed response can be considered in-transit until it is used. > 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". But that has no value to the recipient. Validation only occurs when a response is used, and it is impossible to use a response at the time it was generated. I think we should just accept that a server is not going to push a response if it expects a validation round-trip to be required for its use. Hence, let the server send another push if it wants to invalidate what it already sent. ....Roy
- 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