Scope of Server Push

Mark Nottingham <> Wed, 24 August 2016 05:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FC5D12D0B6 for <>; Tue, 23 Aug 2016 22:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.469
X-Spam-Status: No, score=-7.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cfmO7fUMwAso for <>; Tue, 23 Aug 2016 22:00:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFE6312D0A4 for <>; Tue, 23 Aug 2016 22:00:04 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bcQDx-00067J-6J for; Wed, 24 Aug 2016 04:55:37 +0000
Resent-Date: Wed, 24 Aug 2016 04:55:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcQDr-00066T-JE for; Wed, 24 Aug 2016 04:55:31 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bcQDo-0001Xa-Og for; Wed, 24 Aug 2016 04:55:30 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D7DD522E256 for <>; Wed, 24 Aug 2016 00:55:04 -0400 (EDT)
From: Mark Nottingham <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
Date: Wed, 24 Aug 2016 14:55:02 +1000
To: HTTP Working Group <>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.6
X-W3C-Hub-Spam-Report: AWL=0.983, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1bcQDo-0001Xa-Og 5afd9877a33800da9cfcca37deef2fe2
Subject: Scope of Server Push
Archived-At: <>
X-Mailing-List: <> archive/latest/32342
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Currently, browser implementations of Server Push will not inject the pushed response into the HTTP cache until there is a reference to it from the stream that the PUSH_PROMISE was sent upon. Reportedly, Firefox ties the affinity of a push to a "load group", whereas Edge is using a "navigation handle."

It's not totally clear whether this is:
 - a completely separate, non-HTTP cache
 - a modification or addition to the HTTP cache itself
 - a secondary level of HTTP caching with special usage rules
 - etc.

AIUI there are also variations about the scope of reuse itself; e.g., whether you can push an HTML page to the browser and have it use that from cache  if the user clicks on a link.

Right now, the requirements about HTTP caching and push are written as if the HTTP cache itself is fulfilling this role. E.g., 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.

Looking through the history, this text was written this way mostly so that pushed responses could use the HTTP cache as a kind of rendezvous with requests from the page. That may be sensible, but it feels like the specification of the relationship of push to the HTTP cache isn't complete (and I'll also start a separate thread about other aspects there).

I think there's an opportunity to clarify this, either in terms of HTTP caching, or browser behaviour (see <>), or both. 

Furthermore, at the Workshop, there was some discussion about whether having this kind of "server push cache" as seperate from the HTTP cache was necessary; do we have any more data about why implementers feel it's necessary to have a reference from the page before insertion into the HTTP cache?



Mark Nottingham