Re: Experiences with HTTP/2 server push

Kazuho Oku <> Sun, 14 August 2016 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBA5612D7DF for <>; Sun, 14 Aug 2016 14:20:17 -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 z2H-mIIxh80s for <>; Sun, 14 Aug 2016 14:20:16 -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 8EDA112D7D8 for <>; Sun, 14 Aug 2016 14:20:16 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bZ2lD-0005iB-VL for; Sun, 14 Aug 2016 21:15:59 +0000
Resent-Date: Sun, 14 Aug 2016 21:15:59 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bZ2l5-0005hL-5O for; Sun, 14 Aug 2016 21:15:51 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bZ2l3-0003SV-0V for; Sun, 14 Aug 2016 21:15:50 +0000
Received: by with SMTP id o80so71059795wme.1 for <>; Sun, 14 Aug 2016 14:15:28 -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=2ClQnkrQvp/eIKZtVeGeO8Lq970CGycV7j0OCEmeMAI=; b=QIY/Gj312Y3HRZ6G6EGeQ8ksdnyBTDjRIkACol5e3y2dIzxnQA9YEzab7HN4SBuQU3 iWysN89Gh9MrlIFsFv1S8wz4PSe4FYfegFYMyTMqb+/sk3/lWyjnL/oV1lRMnzgzhtmd ejQFLz9Uz/HjLDXtR7yGqa9RtT1J5vUmksFYx+qRu6MXknqqzW0/NILYfILaGVAKtoCY GQoEEhD4ComVThBB8fxw2DaeQrdT8lJBvfnB3CQ8KqbawuysZOaSEN7JhG9SdjPB04WS 8Zr+nbOGbBCVBdDfgk8CpdsVSXOvpCLWhikAjH6jMcE6JjS+1lxpz3nYD+XCeUwWzU8j 6SOg==
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=2ClQnkrQvp/eIKZtVeGeO8Lq970CGycV7j0OCEmeMAI=; b=bVRBK7Og00IFeL31OkjA8cZGLKQCbM5jq+MK/smgip4ua6zc7YpZRDOl4125Pa91No qjedaUxECpckKHC+dxXfBM+RVEoMrbXAWRwvwxMTfVSizkrHzpTDULK2FfkwJT0g71Sm pWoZCPiqmWRdjd7lfXbk80nbCCfQ8qRLH1NgxqN5BRvRiRycPvpwDJLjQRN405yJ0zPr U1kZRaqGMewx2eHOWwBfS+X8O7hQIArvqqqnKULzE09oSQRt/d4ear8k0dprAfkuQwl1 w5OtycnHJf66ofhwp8GD4v8CnUt/h66af5atdmJJFRBQQ3FteK39Z5GmTMwQVhv5ZeMe xCkw==
X-Gm-Message-State: AEkoouv0ESONYD4okCtsewE0xJsdgLUUsSxz3z6b72wILeyXsiML0FzTaNE3ouRWGSLkyZh//WyzFviUcRo8ig==
X-Received: by with SMTP id eu18mr26735785wjd.121.1471209321818; Sun, 14 Aug 2016 14:15:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 14 Aug 2016 14:15:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Kazuho Oku <>
Date: Mon, 15 Aug 2016 06:15:20 +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: 1bZ2l3-0003SV-0V 4b4e69295f2511b9d49df3fba4d5a79b
Subject: Re: Experiences with HTTP/2 server push
Archived-At: <>
X-Mailing-List: <> archive/latest/32266
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

2016-08-08 11:02 GMT+09:00 Martin Thomson <>:
> On 6 August 2016 at 01:20, Tom Bergan <> wrote:
>> On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <>
>> wrote:
>>> I didn't read through this in detail, but there is a fairly big error
>>> here when it comes to the description of using priorities.  You say:
>>> > One way to implement this is for the server to update its HTTP/2
>>> > priority tree, **then send PRIORITY frames to the client that make A the
>>> > exclusive parent of C** and C the exclusive parent of D. This is an
>>> > attractive implementation because the server can continue using the HTTP/2
>>> > priority tree to order requests C, D, and B.
>>> The server can't send PRIORITY frames in this way.  Or at least, that
>>> won't have the effect you think it does.
>>> The server can (and should) just send as it sees fit, using as input
>>> its own knowledge and the priority that the client has provided.  If
>>> the server sends PRIORITY, that is to affect client processing (hint:
>>> that's not going to happen here). Given that the space that you are
>>> examining is a problem for server-to-client transmission only, the
>>> server expressing priority is pointless.
>> Yes, we agree with you. The point of that section is that the server should
>> *not* send PRIORITY frames like that. Here's the next paragraph:
>>> However, this is fundamentally racey: if both ends (client and server)
>>> update the priority tree concurrently, it can easily become out-of-sync. For
>>> this reason, we advocate not mutating the priority tree on the server.
> I think that you still misunderstand.  The priority tree is the
> client's data.  The server cannot mutate it because it doesn't own it.
> As you say, if the server makes changes, the state is ruined.

I agree with Martin that a server should never send a PRIORITY frame.

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

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.

>> 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.

Kazuho Oku