Re: Extensible Priorities and Reprioritization

Yoav Weiss <> Mon, 08 June 2020 09:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 303D63A083C for <>; Mon, 8 Jun 2020 02:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xVCmorSpwisS for <>; Mon, 8 Jun 2020 02:56:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A33853A091D for <>; Mon, 8 Jun 2020 02:56:29 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jiETY-00062o-L7 for; Mon, 08 Jun 2020 09:53:52 +0000
Resent-Date: Mon, 08 Jun 2020 09:53:52 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jiETW-000623-Ue for; Mon, 08 Jun 2020 09:53:50 +0000
Received: from ([2a00:1450:4864:20::231]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jiETU-0001Bp-KL for; Mon, 08 Jun 2020 09:53:50 +0000
Received: by with SMTP id a25so19659461ljp.3 for <>; Mon, 08 Jun 2020 02:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KZ/LytJnDzyWxPyX13QjDbyCGUW6aSHXUYZV0GtadeM=; b=VrD7o0nng7FSi+qKsF1EXo83b1MAJRaOwN/Schp2HcedgaQao+GVhSNZWzRQxBV5vN CuEZ2umugBwL18CDaXWUmc16jaJDI7RNX/gngg1pJTJIKOI4N1MO4Rbl/8DofVi+Ac5+ pzNVBp6hfSACXtbDxYlYAgxsxKHtS/uTzEid1az9QHl/cHo/B8xqLVxXkD5tVYSl8d3z lwAx+8EMWKFM67X6EOAxxh543JK03O7tLrzzMxAp5DhiIa6Bgy67wsEB+sHOJs57hTh3 0BbbT+YYxNtVYG7U69oIPhcYip/S4wYZa3l/fuALpsqcM/3sni8f1kZl198uBj/JrfiD atYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KZ/LytJnDzyWxPyX13QjDbyCGUW6aSHXUYZV0GtadeM=; b=AM547118I0oGB0NH7pizlHfQtkrgXvtP5Br8SqXv1TmX1h6uPqBy1UNKWQ0IYuFlHa 5H4t3L6eosh3XZvsE48Fs2tdMR2SRkIZDRrBb5aBdN27Y5FhT5KBf7cB63y0G2Lcs/M4 1ABXo01WTP0Ic1tai9iZ1WVqVb+OIaj/0JEd6MIfEo9+eXI1UEozI6F316yJo1sJRZ2u y3yKXBSl587n6vXsX1+5/K5RtYshUrP7yweBajv1Rm0Z2BY15VnYpaamAQ1nwi3c5y+d Qtr+BsgOKHNtxEUYy+sujU5q5vr2yNPmsm7Sn8Zn7mcujTMhQFbYIWyVwSK1PI8NQ7+C V+fA==
X-Gm-Message-State: AOAM5304q3GgLMnLvkOnLwNI3IWz9t7XeDYxp/iXdwQh8+aToG7CHpiA FaIz+FeczMVROaBkIs/d5weNwgvg7uE1Gf/QdBBmfA==
X-Google-Smtp-Source: ABdhPJzmaP4MAJAUnq5RqgDqblx8y6rmZtpjm7xubko1EGVsHIoju6+Sn616famGgd521DTHbUXgNPBKEqIuZVPA0To=
X-Received: by 2002:a2e:b0f9:: with SMTP id h25mr11227974ljl.18.1591610016676; Mon, 08 Jun 2020 02:53:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Yoav Weiss <>
Date: Mon, 8 Jun 2020 11:53:20 +0200
Message-ID: <>
To: Lucas Pardue <>, =?UTF-8?Q?Bence_B=C3=A9ky?= <>, Ian Swett <>
Cc: Patrick Meenan <>, =?UTF-8?Q?Bence_B=C3=A9ky?= <>, Tarun Bansal <>, HTTP Working Group <>, Kazuho Oku <>
Content-Type: multipart/alternative; boundary="000000000000aa56b605a78f95be"
Received-SPF: pass client-ip=2a00:1450:4864:20::231;;
X-W3C-Hub-Spam-Status: No, score=-8.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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: 1jiETU-0001Bp-KL 5d4f63dca2c19d580c5cbbd0a9bede87
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37731
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Jun 5, 2020 at 5:55 PM Lucas Pardue <>

> Hey Patrick,
> On Fri, Jun 5, 2020 at 3:41 PM Patrick Meenan <> wrote:
>> If you're looking for a distilled test case, my HTTP/2 prioritization
>> test page
>> <>
>> used for the prioritization support
>> tracking.  It loads a bunch of images "below the fold" and then after they
>> start loading it injects 2 images (one after the other) into the viewport.
> It's a good test case but I wonder how it directly translates to
> reprioritization frames. I think understanding specific wire behaviour in
> H2 and mapping that into Extensible priorities is the key to figuring out
> if PRIORITY_UPDATE frames are required. I suspect that in H2 and chrome,
> your test case triggers an implicit tree reshuffle because the new request
> is inserted somewhere with an explicit dependency.  Or maybe it triggers a
> whole set of PRIORTY frames that shuffle the tree? How does the behaviour
> of other implementations look on the wire?
> That said, I think things play out differently in Extensible priorities.
> The "below the fold" images can be requested at an urgency of N, the
> injected images are requested later at a higher urgency between N-1 and 0.
> A server that follows the specification's recommendations will pass your
> test; no reprioritization frames are required to be sent.
>> Building a whole separate "VIEWPORT" scheme that is browser-specific
>> feels a bit like punting on the problem and effectively killing it,
>> particularly since most of the drive behind simplifying prioritization was
>> for the browser use case anyway.
> Point taken. Although I will clarify that some of the drive toward a
> header was to expose more control to web developers. We might also want to
> consider how this scheme's reprioritization feature would or would not be
> exposed. That might limit it's usefulness even further.

To clarify, the main use of reprioritization today is for early discovered
resources, which conditions change during the page load, after their
initial requests were already emitted.
The most prominent example is in-viewport images, which requests often go
out before layout happens.
But one can also think of e.g. stylesheets which use the async pattern
<> or low-priority
scripts, which priority suddenly increases (after the request for them is
sent) due to user interaction.

> What are the difficult points around implementing the current
>> reprioritization plans? Is it a sequencing problem with streams and
>> out-of-band changes? Would it help if the priority change was actually a
>> stream-level message and specifically changed just the urgency of the
>> requested stream (with any server-side headers overriding even the changed
>> urgency)?
> The H2 request/response exchange sequence [1] requires the final frame in
> the sequence to bear the END_STREAM flag, which closes the send side of the
> stream and prevents any more frames being sent. Furthermore, see the thread
> Mike Bishop started about H2's lack of grease and the impact on extension
> points [2], support for extension frames on request streams might cause
> connection failures. Since then Cloudflare has fixed a regression that
> addresses this problem but I'm unsure of the status in the wider ecosystem.
> For the above reasons, restricting PRIORITY_UPDATE to the control stream
> (H2 stream 0) is a safe deployable approach. But it introduces cross-stream
> referencing and that requires some careful consideration for
> implementations, such as buffering and resource usage.
> Channeling the WG discussion, I think it is reasonable to ask if clients
> are interested in implementing the reprioritization feature.

I'll let +Bence Béky <> & +Ian Swett <> weigh
in on this question, as they are more likely than me to actually do the
work involved.

> Because if we don't exercise it with running code, it is hard to iron out
> the issues and capture the necessary detail in the document. As evidenced
> by the problems found in H2 stacks after they widely shipped.
> Cheers
> Lucas
> [1] -
> [2] -