RE: Server Push and Caching

Mike Bishop <Michael.Bishop@microsoft.com> Wed, 24 August 2016 18:35 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 EED6012D63C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Aug 2016 11:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.568
X-Spam-Level:
X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, RP_MATCHES_RCVD=-0.548, 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=microsoft.com
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 ATIcR5gdt38N for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Aug 2016 11:35:21 -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 A85C912D65E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Aug 2016 11:35:21 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bccwA-0002Xb-Rd for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Aug 2016 18:30:06 +0000
Resent-Date: Wed, 24 Aug 2016 18:30:06 +0000
Resent-Message-Id: <E1bccwA-0002Xb-Rd@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <Michael.Bishop@microsoft.com>) id 1bccw2-0007Qq-L2 for ietf-http-wg@listhub.w3.org; Wed, 24 Aug 2016 18:29:58 +0000
Received: from mail-cys01nam02on0138.outbound.protection.outlook.com ([104.47.37.138] helo=NAM02-CY1-obe.outbound.protection.outlook.com) by lisa.w3.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <Michael.Bishop@microsoft.com>) id 1bccw0-0004Os-3a for ietf-http-wg@w3.org; Wed, 24 Aug 2016 18:29:58 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lok7W76KSvG3dbcgVl7qooytUl/b3K04sqAWg65Qyes=; b=iHRiho7q0wFx8dkmDeCY7h+J04WH9VNIfJdEw7zGqEFzhk0tfrSTsQXuVdghGOELVQoqIpl08iJXTyrWsabqf1pJkRGhMjX3PDcnzktDSwWQViUSLPq4PiQDIHQPQ5mF2U1cl5/hbHTxJlnyRy0aHEgoC2L2y8SkfmqyTN9O1vs=
Received: from BY1PR03MB1338.namprd03.prod.outlook.com (10.162.109.20) by BY1PR03MB1340.namprd03.prod.outlook.com (10.162.109.22) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 18:29:27 +0000
Received: from BY1PR03MB1338.namprd03.prod.outlook.com ([10.162.109.20]) by BY1PR03MB1338.namprd03.prod.outlook.com ([10.162.109.20]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 18:29:28 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Tom Bergan <tombergan@chromium.org>, Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: Server Push and Caching
Thread-Index: AQHR/cPlE94Nfml5F0mdR3C70KL0iKBYTXkAgAAhgVA=
Date: Wed, 24 Aug 2016 18:29:28 +0000
Message-ID: <BY1PR03MB13387365AB202BB0BB0CAA6A87EA0@BY1PR03MB1338.namprd03.prod.outlook.com>
References: <3904FEC0-4362-47A0-886A-B97FB97E2515@mnot.net> <CA+3+x5F+KVMvfDu=+H0-ScqiYbGL5RPcF9wfZ5992Q=xcp1k8A@mail.gmail.com>
In-Reply-To: <CA+3+x5F+KVMvfDu=+H0-ScqiYbGL5RPcF9wfZ5992Q=xcp1k8A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2001:4898:80e8:9::390]
x-ms-office365-filtering-correlation-id: b87435ff-256c-4660-b9e8-08d3cc4c9539
x-microsoft-exchange-diagnostics: 1; BY1PR03MB1340; 6:hR7BuDT1lJ9GpLOjOtSgA3iJo55DtmaQuQ6KLureUkV0yiCLatr9weqESAzULES++zIza6wbnVLgLyfXgmV4r0sly9ruMqFSDUynv4+meQloBwdiPEz9XeiEdJNKEQVtqJsX1/uw0DFfidlGD13aUVHzSJ3jcHNmjy3twor7491RCzQlUwpMuoJSaliEcgrfrm2UZKrYM+9KcWQtHEjn/mH6ciHsl6rToOXiE02mbtJQB5AeDdpCfXGtIEPnYmHoZcS0Q78XTqTKT7QUvBhzU+lcIDB1R9EumLzOO+en0hn90aXBoHHQBKZcX6mRpGSzoCC3js1vryauA5YmbN+RXw==; 5:tWcZNNjDOt8mvl4s0jYsBh30TW2EKz7GW6vcljMJz/h4AWLnJT8oFneUYl8hvbte/OozkuF0ENCuDO8UwzHkahFtPnxz3lMBOxpppPywA/MI9TQh3Y9W9TDkRGL4buUdFztNFa6aZBCNHWCLFm6dUw==; 24:WnfiGyZGE7wI38Pnw/meYAMKsJJ01m0yplJGWLMgnwXspfm72KKN8JY2aDXrOfUWUTKacwWbV4Sp12nQHmiRWDSGSV2Xv0wpwVvXpHVwOHI=; 7:M11Dleifl3biWpGu4Kbz4d7qDYCDwlSs3wWGFpDfWfDb1Hr2j4AuZLwq3fbfD/86y055+zdaLQM6GER37mogz9nnQNyH4D/VNYc887ESmg8p6+s/ytZj4ixU8B3tgNcVQv4cMrFqqwL6STwuDjtJ3VJsBaIFiGvFjgPIywUF6UCL1+yG6Z52hEwXu034bbWYAR4SC5EflIaLghl/5CO9AOCBLjW8bjn00eGpsm0wVLi9ByXrrGnWFrBvqltSoOlt
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1340;
x-microsoft-antispam-prvs: <BY1PR03MB134070983C0C3681990B4F8487EA0@BY1PR03MB1340.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(228788266533470)(211936372134217)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR03MB1340; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1340;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(24454002)(19617315012)(3480700004)(8990500004)(7906003)(7846002)(122556002)(81156014)(8676002)(77096005)(106356001)(81166006)(7736002)(8936002)(74316002)(15975445007)(10290500002)(2900100001)(106116001)(5005710100001)(87936001)(2950100001)(105586002)(97736004)(50986999)(7696003)(10400500002)(19580395003)(9686002)(54356999)(5002640100001)(16236675004)(92566002)(19609705001)(19625215002)(2906002)(86612001)(76576001)(189998001)(5660300001)(101416001)(4326007)(68736007)(76176999)(586003)(5001770100001)(33656002)(3660700001)(6116002)(102836003)(790700001)(19300405004)(99286002)(19580405001)(10090500001)(86362001)(3280700002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1340; H:BY1PR03MB1338.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY1PR03MB13387365AB202BB0BB0CAA6A87EA0BY1PR03MB1338namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 18:29:28.0368 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1340
Received-SPF: pass client-ip=104.47.37.138; envelope-from=Michael.Bishop@microsoft.com; helo=NAM02-CY1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-2.454, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: lisa.w3.org 1bccw0-0004Os-3a bf22a4c93c70b8c7dca95e9500e76e00
X-Original-To: ietf-http-wg@w3.org
Subject: RE: Server Push and Caching
Archived-At: <http://www.w3.org/mid/BY1PR03MB13387365AB202BB0BB0CAA6A87EA0@BY1PR03MB1338.namprd03.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32358
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>

IIRC, we consider the response to be fresh if a request for the resource occurs within the scope of the navigation that triggered the push.  That is, we ignore the detail of when the stream actually closes and put a different time boundary on freshness.

From: Tom Bergan [mailto:tombergan@chromium.org]
Sent: Wednesday, August 24, 2016 9:28 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Server Push and Caching

Thanks for starting this thread. I have questions about the following quote from the RFC:

On Tue, Aug 23, 2016 at 9:50 PM, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
RFC7540, Section 8.2 says:

> Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present (RFC7234, Section 5.2.2)) while the stream identified by the promised stream ID is still open.

This implies that, while that stream is open, the pushed response can be used by the cache, even when it contains any (or all) of the following cache directives:

* max-age=0
* no-cache
* s-maxage=0 (for shared caches)

The underlying principle here is that while the response stream is still open, it's semantically equivalent to a "normal" response to a just-issued request; it would be senseless to require it to be immediately revalidated before handing it to the application for use.

The cache can also store the response, but once the stream is closed, if that response is stale -- either because of the presence of one of the directives above, or some combination of `Expires`, `Age`, `Date`, and `Cache-Control`, it will need to be revalidated before use.

Chrome does not implement this. Some discussion starting here:
https://groups.google.com/a/chromium.org/d/msg/net-dev/CCNLknIbzYs/hdMw8qYRAgAJ

I can see why the above sentence was added to the RFC -- there needs to be some semantics for pushing immediately-stale responses, and the above sentence seems like reasonable semantics at first glance. However, I'm concerned that these semantics are not implementable in practice. On the client side, the user agent will typically store pushed responses in a side cache until they are matched with an actual request. On the server side, the server will send END_STREAM with the last DATA frame in the pushed response. This creates a race where the client may see END_STREAM before it's done enough processing to realize that it needs the pushed response. For example, consider cases where the server tries to push an "inlined" resource, but happens to push the inlined resource before the referencing HTML tag.

A server might try to avoid this race by holding the stream open, but how long should it keep the stream open? There's no way for the client to signal that a pushed response has matched a request. Further, the client cannot know (in general) if the server is holding a stream open to preserve validity of the no-cache response or because it's slow to send the final DATA frames.

I'm not sure what the right semantics are. One option is to allow the user agent optional leeway to consider the response validated for a longer period, perhaps using a timeout as Chrome does. Or, perhaps, a browser might consider a pushed response validated for the duration of the parent navigation event. Thoughts?