Re: Experiences with HTTP/2 server push

Martin Thomson <> Mon, 08 August 2016 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2C0F12D098 for <>; Mon, 8 Aug 2016 14:00:04 -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 1Lgc7ekENbw1 for <>; Mon, 8 Aug 2016 14:00:03 -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 1AAA212B027 for <>; Mon, 8 Aug 2016 14:00:03 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bWraZ-0005mU-MM for; Mon, 08 Aug 2016 20:55:59 +0000
Resent-Date: Mon, 08 Aug 2016 20:55: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 1bWraT-0005lj-2w for; Mon, 08 Aug 2016 20:55:53 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bWraR-0002xe-EP for; Mon, 08 Aug 2016 20:55:52 +0000
Received: by with SMTP id x25so209836585qtx.2 for <>; Mon, 08 Aug 2016 13:55:31 -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=EE5sGvyvu7rRLXjye8DEMEbxFJlUT0ISMR/k7O97KH8=; b=q3ezUJJSBNmqnE1YSh4tv5fbu+ff7DcHfpZqZkEZmED0rp042cfTI4/VkmppmDoXFv CWhOWW4bjFJ14l1XIh7xK8gze15Hdme0JlIyDv+LYY0dH6N19u+AEFqEK8yiC3XvwrlL au4puKbPzU3CHUYSvFh8NsbH27MeUhG7wUhAmWv3bDkC3klBLcS7a5JS/3T35qtulOhG qL0JoDU1ETaY6q5/YQQPRfiIGhA82YYbG+EQnpHRjtR3GiEMUU0RzPKIrcjL+jMEuifZ 9rRcaiN2Awzuw33cWf3paI/WRtpSULTosTYnAUTkwwp7+KgYeCdjnTkKeY0NLZM4ats1 5+kQ==
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=EE5sGvyvu7rRLXjye8DEMEbxFJlUT0ISMR/k7O97KH8=; b=hrEnl94JTQALDJj+m/FOnHiXk9zAdhjmX002iWpvW3mcwUk4oNB1qSXHMvT7t3ia/Y KjIDh0DzGS8bGCc6VgbF/suny2FRHJEcNzvPG8hxfJUUMWN8T5Uw2jIUNIj3L6PgxjM1 AOuy4o3Oz+007buLaFFsDEGMvI+tZtdIPQAvKCCrf2evA0oR2xJ1xY5WZQIGkIWuOTGc wMGQ1lkmGl5xpE+AA0rrh53P9R2xOGtzPKvThMrYFlldi9Se3CPpcYvG9dHpH4v9ePFf rpAZPpFxwWdufMl271xNUR6gVNgE1wo6Y/kodk2GoQ3WPA3tOBl/P0wVW/1lOsFBrdcp lLpA==
X-Gm-Message-State: AEkoousL0ARXkaWeIcfSLyRdI0lPP7JCWjj4YkbJf0pILqYAdmGBGhlFwtdNiWM1G/CjRM0OjTgfEnu2P0TvYw==
X-Received: by with SMTP id a7mr25745959qtb.43.1470621735448; Sun, 07 Aug 2016 19:02:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 7 Aug 2016 19:02:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Martin Thomson <>
Date: Mon, 08 Aug 2016 12:02:14 +1000
Message-ID: <>
To: Tom Bergan <>, Stefan Eissing <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, 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_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1bWraR-0002xe-EP 0bb1bcfb8f59511927150a089ef7e85d
Subject: Re: Experiences with HTTP/2 server push
Archived-At: <>
X-Mailing-List: <> archive/latest/32231
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.  Note
that no client I'm aware of will do anything with the server's
PRIORITY frames, let alone adjust its own priority tree.

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