RE: Push and Caching

William Chow <wchow@mobolize.com> Tue, 26 August 2014 23:11 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 B6AFB1A00E5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 16:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XwJf55eHyQ0d for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 16:11:26 -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 419BA1A008F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Aug 2014 16:11:26 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XMPqd-0004TE-6G for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Aug 2014 23:08:19 +0000
Resent-Date: Tue, 26 Aug 2014 23:08:19 +0000
Resent-Message-Id: <E1XMPqd-0004TE-6G@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <wchow@mobolize.com>) id 1XMPq6-0004Rs-1c for ietf-http-wg@listhub.w3.org; Tue, 26 Aug 2014 23:07:46 +0000
Received: from mail-bn1bon0062.outbound.protection.outlook.com ([157.56.111.62] helo=na01-bn1-obe.outbound.protection.outlook.com) by lisa.w3.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <wchow@mobolize.com>) id 1XMPq4-0000Xy-GK for ietf-http-wg@w3.org; Tue, 26 Aug 2014 23:07:45 +0000
Received: from DM2PR05MB670.namprd05.prod.outlook.com (10.141.176.22) by DM2PR05MB671.namprd05.prod.outlook.com (10.141.176.23) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Tue, 26 Aug 2014 23:07:14 +0000
Received: from DM2PR05MB670.namprd05.prod.outlook.com ([10.141.176.22]) by DM2PR05MB670.namprd05.prod.outlook.com ([10.141.176.22]) with mapi id 15.00.1010.016; Tue, 26 Aug 2014 23:07:14 +0000
From: William Chow <wchow@mobolize.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: Push and Caching
Thread-Index: Ac+7v7yD0ZTj4Oj/Q2KCGy9THej6JgAEtB4AABO1Y4AAWKDXwAAA/BiwAAXBIYAAAme3gAAhH1uAAAA6DAAAlYD1AAANDLGAAACCPIAAB4OXAAADQUAAAAGZ9YAAAComUAABTwAAAAIQZQAAFMvjAAAAi1OAAANr5IAAAPXfgAAB508wAAKq4QAAACgpgA==
Date: Tue, 26 Aug 2014 23:07:14 +0000
Message-ID: <ee6c28ad51ab4022a6346ffb836bf770@DM2PR05MB670.namprd05.prod.outlook.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> <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> <DE38D1FB-C9E1-441F-BDCE-9258714E0D96@gbiv.com> <02fc4b73d8004853b4286d02acbcc942@DM2PR05MB670.namprd05.prod.outlook.com> <CABkgnnWXiivor8cTrHiAsL8uyJ-42FsiF44_103c7M+w2e797A@mail.gmail.com>
In-Reply-To: <CABkgnnWXiivor8cTrHiAsL8uyJ-42FsiF44_103c7M+w2e797A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [96.251.72.195]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 03152A99FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009011)(6009001)(189002)(51704005)(199003)(90102001)(105586002)(76482001)(107046002)(106356001)(79102001)(31966008)(110136001)(33646002)(74316001)(99286002)(76176999)(74662001)(21056001)(46102001)(74502001)(83322001)(80022001)(64706001)(85306004)(87936001)(76576001)(85852003)(81342001)(66066001)(95666004)(2656002)(86362001)(4396001)(20776003)(83072002)(93886004)(92566001)(81542001)(54356999)(99396002)(108616004)(50986999)(77982001)(101416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB671; H:DM2PR05MB670.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: mobolize.com
Received-SPF: pass client-ip=157.56.111.62; envelope-from=wchow@mobolize.com; helo=na01-bn1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-2.3
X-W3C-Hub-Spam-Report: AWL=-2.300, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1XMPq4-0000Xy-GK ed578a61f982d376a3e815f5efa1ffc1
X-Original-To: ietf-http-wg@w3.org
Subject: RE: Push and Caching
Archived-At: <http://www.w3.org/mid/ee6c28ad51ab4022a6346ffb836bf770@DM2PR05MB670.namprd05.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26751
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>

>> With HTTP2 and server push, there can be multiple responses that directly correspond to that "original request" (this is the term used in the HTTP2 draft).
>
>That's not right.  Server push always provides a request.  The only difference is that it is synthesized by the server.

I am referring to this paragraph in 8.2:

"HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in association with a previous client-initiated request. This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request."

Note that I didn't say the server *didn't* also push the request. I am only referring to the notion stated above that those pushed responses are "in association with a previous client-initiated request". Perhaps you disagree with my use of the term "correspond", so "in association" is fine by me. 

Upon further reflection, the time of the generation of a pushed response is going to be effectively the same time as the generation of the response to the original request, so perhaps there isn't much practical difference between your proposed text and mine. What I am hoping we'd be able to do is to include language that describes the relationship between the original request/response and the pushed responses, so that caches have guidance on when it is safe to serve a pushed response when the client-initiated request is actually received later from the UA. 

For your proposed text that says a pushed response is validated at the time it was generated, this seems so obvious as to not have any value for the no-cache case. Specifically, it seems that a pushed no-cache response should only be valid when *used* in combination with the response it was pushed with. I think this is what Roy F. was alluding to in his other response (about not preventing use, but to discourage reuse). While we can call out the no-cache case specifically, it seems we don't really need to if we had language that coupled the pushed responses's validity with their associated original request/response.

--Will