Re: Extensible Priorities and Reprioritization

Lucas Pardue <> Tue, 09 June 2020 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BEC43A0959 for <>; Tue, 9 Jun 2020 09:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Status: No, score=-2.748 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.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 GZT9qYacJV5x for <>; Tue, 9 Jun 2020 09:21:11 -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 AF3A63A0935 for <>; Tue, 9 Jun 2020 09:21:11 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jigxG-0004yY-C0 for; Tue, 09 Jun 2020 16:18:26 +0000
Resent-Date: Tue, 09 Jun 2020 16:18:26 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jigxD-0004uZ-OM for; Tue, 09 Jun 2020 16:18:23 +0000
Received: from ([2a00:1450:4864:20::42a]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jigxC-0007CI-5i for; Tue, 09 Jun 2020 16:18:23 +0000
Received: by with SMTP id e1so22008660wrt.5 for <>; Tue, 09 Jun 2020 09:18:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/RWbWNx24TG/lbL27Efs8M8sYCFhFrwSjCS8UBo7/iA=; b=tpFFJa2bIbuIWR1TkcYLvUJBom1S0R9pSPqKG/0okZPBeex62qbX+vihI2kd//GTPN iAJqxPQUq9qJS4/41D0ozVZyRMUWxnaYPbXn8QTqBicieuKy4BmTUkAkJtF50aemGLjr bNyMHVVomg7LnooRQoNpKxJ8eM4SLSO1BA58YmMaC6zSV+dX40xWCJIoWXLGc9lMMHpA TVg2fDX7ig3MhvahHIks0Bcw0+0ZgmrKvQTwndRjNwmuNba7PkXwp8QZXfUjplrD41Bf ugmbbO8UIGWJIjj2Xf1PyMB7zowlRqugYhoC1kKyCY7KFy8QPJr9B7DeAJJjbkhK++2T gZXQ==
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=/RWbWNx24TG/lbL27Efs8M8sYCFhFrwSjCS8UBo7/iA=; b=eLloQW9CvIQpWOz+Zx1tNcvv8+BOS7BriW9Umh9yEr4m4IpuPdhCU9pl/PlLexd+vg q2LcZhqXYdKtEdmJKGtOrPt/qiJ/RQvlxOx+8j4PCwBM39Pc9REHlii+ZZfA4fWkcbvX IxbBhXkkK+oM6Ny+HbO333fi/iS2AavRMbTgCAvDfy5GWsUBFhyyeMTrvQIKjXTUeHSN B/7ySCEnb+StJLNhGLc7hKsTJ8ptDshvnTk5u1sPWY7e4rGmyl/ENbxHStnJuMCwtcIu m1Kwo2vv3UqzQmVxprRlNTsf9cEL8QWMtwGT0cgmc9nXSso5ospYAhcxVrp6Zcize+Ct +7Dg==
X-Gm-Message-State: AOAM5335h6mX9NCpzRn7SxlFDiWT3/Od6D/FzeEnuDQbYHxNrH/+gw2l j7VurUmI8zluY8z6WE0kKwEc4qtjz3lIjJMbn8g=
X-Google-Smtp-Source: ABdhPJy3J/DGBI0nTNKY1SC+xkysCjVCk3uTA9rQ4tp4olV2yrLF+JbuqPpoiPr6z9j3iRb1kGKzAW5I6ewvCeduaiM=
X-Received: by 2002:a5d:4a04:: with SMTP id m4mr5822017wrq.153.1591719490816; Tue, 09 Jun 2020 09:18:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 9 Jun 2020 17:17:59 +0100
Message-ID: <>
To: Patrick Meenan <>
Cc: =?UTF-8?Q?Bence_B=C3=A9ky?= <>, Kazuho Oku <>, Eric Kinnear <>, Yoav Weiss <>, Patrick Meenan <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000d5128c05a7a912d1"
Received-SPF: pass client-ip=2a00:1450:4864:20::42a;;
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Scan-Sig: 1jigxC-0007CI-5i c50842f26a5982bb4f5755380755f8a5
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37740
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <> wrote:

> Eric's download example is a great one for exposing the risks that would
> come for an implementation that supported prioritization but not
> reprioritization.
> Take the trivial example of an anchor link that links to a download (say,
> a 200MB installer of some kind):
> - When the user clicks on the link, the browser assumes it is doing a
> navigation and issues the request with the "HTML" priority (relatively
> high, possibly non-incremental
> - When the response starts coming back, it has the content-disposition to
> download to a file.
> - At this point, the 200MB download will block every other lower-priority
> request on the same connection (or possibly navigation if it is
> non-incremental)
> - The user clicks on another page on the same site and gets nothing or a
> broken experience until the 200MB download completes
> Without reprioritization the browser will effectively have to burn the
> existing QUIC connection and issue any requests on a new connection (and
> repeat for each new download).
> Implementing prioritization without reprioritization in this case is worse
> than having no prioritization support at all.

Thanks Eric for presenting this case, and Patrick for breaking it down.
That does seem like a pretty bad outcome.

Is this a good candidate for a test case? IIUC correctly the problem might
occur today with HTTP/2 depending on how exclusive priorities are used. I'm
curious if browsers can share any more information about what they do
already. How does Firefox manage such a resource with it's priority groups?