Re: Experiences with HTTP/2 server push

Kazuho Oku <> Mon, 15 August 2016 02:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAFCE12D1C1 for <>; Sun, 14 Aug 2016 19:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.268
X-Spam-Status: No, score=-8.268 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 h76HzhqlQR8h for <>; Sun, 14 Aug 2016 19:03:31 -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 EF74C12D10E for <>; Sun, 14 Aug 2016 19:03:30 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bZ7BE-0007SY-4N for; Mon, 15 Aug 2016 01:59:08 +0000
Resent-Date: Mon, 15 Aug 2016 01:59:08 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bZ7B8-0007RG-8c for; Mon, 15 Aug 2016 01:59:02 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bZ7B4-00032c-KK for; Mon, 15 Aug 2016 01:59:01 +0000
Received: by with SMTP id i5so77501086wmg.0 for <>; Sun, 14 Aug 2016 18:58:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kOM3NxS0nTb9nzDVy6cvtB6qKBXemLQLUnHVWwevye8=; b=p72NyXauWoZ2TmS1iWVslg7COnlkI3znbpZ0jQASbxmLoD9dKXlf4gxXYkfdY8DiE8 OI+/JsoexqmUO4Ji1a0+SVoOntLc97W43fbjAh1lPSMksOL8NWEGxY9h1b1bLRaN/u7s XWsxwDpO++4kBIwdotZAWhkYnTSjnJjASF+qGICwjqK41cecBvj7eET4o5nCabzN58K7 ynFG6HpyQtEcollCIJxDNlHfQTFsf0cn3jU8ovzpQ9a5w+GW6JIvNFWA9cOc8RN00pio kDKAgsFydUqpOiviyd+9h1r+IzqxxQ1ZrqxmCsf1grW9Nesa5OhbLMjR4la8iX+r0h0P eD2A==
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=kOM3NxS0nTb9nzDVy6cvtB6qKBXemLQLUnHVWwevye8=; b=EtJX+6OVmP1XzT3GNe36X+OXsapU/7b8qhnsUdlQ0NLAtvSYORy36ZzIEJznPZUOVm zqOY/DQC8YZNce2OYaq3ffHeKuQuVMk/Y/j2QPg7l8/7Q80m+96XPHs+sen1jMAsLLZH s9CbIsfO4vXYoFuc2foHUnfm5UTgHV5ak4TpjVXVJ4DMbG8/g+iPUs63MXVL9QqpoHi8 jZeHYdx2P84TsJ3Xe48lnyge7bs+X8p2cOkg6CIGO4F4J6ozPDLh6RknwF/zPe/zwWrN 0VqJHfJpBtTYO1pg6N6S2CP0XyUAu2fdRn3Sz4+50uxH2KpvBENQeWHJdkdTj7QdlFOn vcWA==
X-Gm-Message-State: AEkoous4stuHcrciY7dVJL04oxop3BqM9uKrAyyYb/MdKlUT2sWBaeEFjTqx8glxqN7auBFJsdIdpz8LOTKSVg==
X-Received: by with SMTP id eu18mr27871665wjd.121.1471226311390; Sun, 14 Aug 2016 18:58:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 14 Aug 2016 18:58:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Kazuho Oku <>
Date: Mon, 15 Aug 2016 10:58:30 +0900
Message-ID: <>
To: Martin Thomson <>
Cc: Tom Bergan <>, Stefan Eissing <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.817, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bZ7B4-00032c-KK 171ad6fbae4b13ebfe645a289fba09a3
Subject: Re: Experiences with HTTP/2 server push
Archived-At: <>
X-Mailing-List: <> archive/latest/32268
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

2016-08-15 10:14 GMT+09:00 Martin Thomson <>:
> On 15 August 2016 at 07:15, Kazuho Oku <> wrote:
>> OTOH let me note that a server can also send priority information as
>> part of a PUSH_PROMISE frame. This way, the priority tree does not get
>> ruined.
> I don't think that makes sense.  If the client processes the
> PUSH_PROMISE and immediately reprioritizes the push, then the PRIORITY
> frame that appears afterwards will be exactly as meaningless or
> destructive as anything else.

Sorry, I agree with you on this point. My misunderstanding was that it
was possible to embed priority information within PUSH_PROMISE frame
like the way that can be done with a HEADER frame.

>> Ideally, I think clients should send PRIORITY frames when it finds out
>> how the content of a pushed stream is used, so that a server (that
>> consider clients to have better understanding of how the resources
>> should be prioritized) can respect the updated tree to prioritize the
>> pushed streams.
> This is good advice.
>>>> We are aware of a few servers that update the priority tree like
>>>> this, e.g., see Apache's h2_session_set_prio.
>>> Stefan, is this right?  See above.
>> In case of H2O, we prioritize pushes of certain media types, but that
>> is done out of the HTTP/2 prioritization tree. I think that is the way
>> to go.
> I couldn't parse this.  Do you mean that you ignore the client's
> express priorities, or work within the client's priorities?

Generally speaking, a server should respect the priority tree
constructed by the client if it considers the client's knowledge of
how the responses should be ordered superior to the knowledge of the
server. OTOH, if a server considers itself to have better knowledge on
how to prioritize the streams, then it should ignore client-driven

Since the client cannot accurately prioritize a pushed stream until
client observes how the resource is used, server-driven prioritization
of pushed streams is necessary until client updates the priority of a
pushed stream.

So our approach is to create a separate tiny pool of streams _above_
the HTTP/2 prioritization tree, and initially register the pushed
streams with certain media types (e.g. CSS, JavaScript) to the tiny
pool. The server does not send PRIORITY frames for the pushed streams.

This means that until the client sends a PRIORITY frame to update the
precedence of a pushed stream, pushed CSS and JS will be sent before
any other responses. Once the server receives a PRIORITY frame, then
the pushed streams will be prioritized as specified by the client.

Kazuho Oku