Re: Scope of Server Push

Alcides Viamontes E <> Wed, 24 August 2016 11:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5A7512D931 for <>; Wed, 24 Aug 2016 04:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.468
X-Spam-Status: No, score=-7.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YFxPO4n-hhcM for <>; Wed, 24 Aug 2016 04:36:35 -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 AA01C12D100 for <>; Wed, 24 Aug 2016 04:36:35 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bcWPE-0005Qa-AD for; Wed, 24 Aug 2016 11:31:40 +0000
Resent-Date: Wed, 24 Aug 2016 11:31:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcWP4-0005Pp-AC for; Wed, 24 Aug 2016 11:31:30 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcWP2-0005Ut-22 for; Wed, 24 Aug 2016 11:31:29 +0000
Received: by with SMTP id n59so22572937uan.2 for <>; Wed, 24 Aug 2016 04:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OxLdaNBTsJS5r6wfcku4cT+RXVaZ3Kn2SHgY8YZoUpk=; b=Zp0fTFNRZCYc0bKuBf+cbFIV4R/YecaMZgvv9QmdKGE7//WzpERm1mYx0aoBE0ktHm YPzdRduvUKrXomK4rMykqqDn1A2g8SBkUOkqK7HAq3uduPnwFHSHoflhNrWAzZzJDeZo sEyR19rCvceKK8bJWFB8hro7lLC7J9Lw+kiv6uEFNZ3b4F7KMUxSRgQBspIZgCLAsLBK S2tLhRUNS74HgNcfFbulP8HuOXtU/f5ljKbtFHvZrEkHU5mkEBGnJC34EN7YC9nNkxF/ fjaS+5zwJ+jJwuU6LJs8Dw4dVLQUxEVT9Bc+mLpRujq96fiDxYlIs95KJunbX5YTZig7 37Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OxLdaNBTsJS5r6wfcku4cT+RXVaZ3Kn2SHgY8YZoUpk=; b=QdgRTF0Rkw3hgEjO5l3m9to5an9HRC61xjmLPmBzu6eMmCWCWxKvVRHp6ZTKMx/dRj wCgMSO6OGzii2+zI9InG8KjEOZjKFX0nozKnCPx1ldl1+ZkgR9WDVaaDdlkhyy8VwmLD lrEL3B96yffrjocQMTRIQiRiNjGtsqw9CBwm49uBqu9Jj2rBXP1cqxiddBg3hWtBW1HA hmrM4ITNErGy/kxt8kIwJIp/tl4r8ihaxgCEXXu12ycqPYVL1DgOH7smIMRxbY8C7cIv q/d1GqIHJ6iQhIxmX2hC1hEeCPNrqfkOXmiw+OS4e2vAb8xK6wvPDkvIo3+jcys6wB67 YAsg==
X-Gm-Message-State: AEkoouvHoJokC73uTMKXN1Fvelbxf6hYMvPWGwYToqa9WA79I89leTcWTwAt8xwsdc1BlTnGPb4Hmu4E2/zJtQ==
X-Received: by with SMTP id g4mr1411446vkb.77.1472038261071; Wed, 24 Aug 2016 04:31:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Aug 2016 04:31:00 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Alcides Viamontes E <>
Date: Wed, 24 Aug 2016 13:31:00 +0200
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=001a114e3f32a5b930053acf9d04
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.067, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1bcWP2-0005Ut-22 7675882b59e74f9b9928802d5cfc099f
Subject: Re: Scope of Server Push
Archived-At: <>
X-Mailing-List: <> archive/latest/32349
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Two quick comments.

The first is related to the "rendezvous zone"... how long are things
expected to be kept there?

The second has to do with a use case that I think falls into a gray zone:
using Push as a "good" way of doing HTML inlining.  Just to dust it off,
say that the HTML file goes like this:


<script src="nugget.js"></script>



The server may want to push 'nugget.js' as a way to save a round-trip. At
first instinct one would like to send the push promise either immediately
before the HTTP headers for the HTML stream, or immediately after. But
piling too many push-promises  close to the start of the TCP connection may
trigger a round trip.
An alternative is  to architect the DATA frames for the HTML so that there
is one terminating at "point", insert the push promise for nugget.js there
(if the server knows, e.g. via cache digests, that the client doesn't have
"nugget.js"), and only then continue sending the HTML data frames.

Notice that this is the same use case that has been imagined for Push, and
I have reviewed RFC 7540 to see if this contradicts the spec in some way
and so far I think it doesn't. It is just sending the push promise as late
as possible to avoid congestion round-trips. There is no need to do this
for pages that only require a few scripts to be pushed, but if developers
are going to stop concatenating assets, the number of smallish Javascript
and other files one may need to push to get a quick first render grows very
quickly, we have seen this happen in some of our sites.

Waiting as much as possible to send push promises would also work nicely
with the current cache digest proposal, as the server gets more time to
receive any cache digest frames in flight from the browser.

Sending push promises just before the links embedded in DATA frames  may or
may not work today, since there is no hard requirement for browsers to mix
links scanned from the HTML contents with links arriving in push promises
as strictly and eagerly as possible. It would be nice to account for this
use case in any future precisions to HTTP/2 push.

On Wed, Aug 24, 2016 at 6:55 AM, Mark Nottingham <> wrote:

> 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 <
> fetch/issues/354>), 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?
> Discuss.
> Cheers,
> --
> Mark Nottingham

Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
( is a property of Zunzun AB)