RE: Setting to disable HTTP/2 Priorities

Mike Bishop <> Tue, 30 July 2019 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A472F12023E for <>; Tue, 30 Jul 2019 07:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4zpdjFU_8uIY for <>; Tue, 30 Jul 2019 07:38:06 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 605DE120240 for <>; Tue, 30 Jul 2019 07:38:01 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hsTDk-0003zK-3f for; Tue, 30 Jul 2019 14:35:20 +0000
Resent-Date: Tue, 30 Jul 2019 14:35:20 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hsTDg-0003yU-7u for; Tue, 30 Jul 2019 14:35:16 +0000
Received: from ([] by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hsTDd-0004Wf-Er for; Tue, 30 Jul 2019 14:35:16 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=H45MgX9LhYEtqDIOW1ZechijXp04qcZTG4iz+iH0I0hfju4QBKZ9+LX4O9ZoRyFNOf9eWN06PQLwVWSE8mVyldbb6hadhcDdFz69QbkbPTDAdlwI1t+YKswQ/6UoVFkytXOIeu9V03ySeR3wcIUE7IEvi73MkCmbLuRlSBraBCtm1BZTSuinhORmbO9xv6s4A2Jh3eietlm8L2Jm4bXQCdrtE6AysZ4ILiI3nn/qDclE5RX5N0fXuoroKBue6EbPAOrEpID2HkN4gQK5RDayzQyqOMJPHbILjN+evWimfXMEU27W1gqUHmrnzLT0v/L7VtH+pCpIrXFNo1LquG86cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9U3UL1DiJh9MkPeoI6EFHNqAncQBdQnXmoRAc6dPWMo=; b=FYcwLwVL0L+CyNgnfsFOzzSubxnpGjxI7y+yVyYtcrJnVAG+c5bdBYxOsRyRf4YRDB0NDEZtLJMSVyc70OCr3xQxYUV9kX+ahCfavWSjFK58qgYzn/K27cNacfX5NWUFK+qFNbvKhdiNZCbVXhYwKUP6MzjhmIQE1a7jh8MM82VXntaBvKUOM9lK0TWaeE8yFiEzra3PSLWe5cDCA9vzhHQ09KnbIf6dP1XPHImIIEe09zO93Eh3x7lzP3+A2Nm67etWHN1UEOxOS65P3GmBlhdd0Kak6xh4tjO/tPmBeL+FqaxHNVm/Fth0AqKJp9yyb8WFadWOvUnwvxdz2xQ71A==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9U3UL1DiJh9MkPeoI6EFHNqAncQBdQnXmoRAc6dPWMo=; b=ZJSSd8xZViEWQRrmFetBuEBMLGFH2o5JyAkc3qqcB5uxDkTAA8PhEMU+//j/r7WSPEWuAwHRo8cRzzGx5+YNrpL1naUN3W4frWvw4KaXa7LcxYI57rk24+nXlW1gcewnNDQyRuKyX1uO/hsccR2HrStmzVc/jyM6mtr8lBMv1Bk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.12; Tue, 30 Jul 2019 14:34:49 +0000
Received: from ([fe80::4190:c9d6:bf3f:2432]) by ([fe80::4190:c9d6:bf3f:2432%4]) with mapi id 15.20.2115.005; Tue, 30 Jul 2019 14:34:49 +0000
From: Mike Bishop <>
To: Willy Tarreau <>, Kazuho Oku <>
CC: Lucas Pardue <>, Brad Lassey <>, HTTP Working Group <>
Thread-Topic: Setting to disable HTTP/2 Priorities
Date: Tue, 30 Jul 2019 14:34:49 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7d0be932-ffff-465e-a3f2-08d714fb13d9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0728;
x-ms-traffictypediagnostic: CY4PR22MB0728:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0114FF88F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(136003)(39830400003)(13464003)(199004)(189003)(51444003)(66556008)(4326008)(8676002)(316002)(81156014)(14454004)(81166006)(14444005)(53936002)(256004)(54906003)(2906002)(86362001)(68736007)(110136005)(508600001)(305945005)(7736002)(476003)(25786009)(64756008)(6246003)(53546011)(55016002)(6506007)(71190400001)(9686003)(76176011)(6436002)(8936002)(102836004)(66066001)(74316002)(486006)(71200400001)(66946007)(11346002)(186003)(7696005)(446003)(76116006)(26005)(52536014)(66446008)(229853002)(3846002)(33656002)(99286004)(66476007)(5660300002)(6116002)(66574012)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0728;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: aLe9gi+1yDL/f88P5em98WhIB/2nZ3M1g4+1tMdjQVZ6iSDhIT0H70HaBUX26SfLlG1N3SAmD/+tBrY/v8JwNbSemXu8Jcd+/0+7EQxfbbwBONyZ700hfLGZXLWmWzsd9noWPlmWU8JfKfgxtXDbzCTZk5WN43faGGL0i7CzV1HUHbtKDf1eqavPOsyIhqG59RHh+y6Jx3MjaHRwPKNdPCTW3P5r4Lfu3uGSxiJbJMQnn3qrJW26k/onnpCy3cFJyXnF8+Dlf8NKu3j+2T4TlD/YZPd+Ou6N5v/l3PZpyDfxJH4tbvZtT6PH0MeHIZDsFaqLtgE9duGAsON1gOQgOaNypyq7LOb1Hc1UpxcKVt7fAEt3UYFGgi5U02t+EjobQu5h4rkD7cWdvBR8cvA5c5sd84QpkFe7+WaKPz+JWwM=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d0be932-ffff-465e-a3f2-08d714fb13d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 14:34:49.6942 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0728
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hsTDd-0004Wf-Er d0af3c422e08ca23a6183e002e87b2b0
Subject: RE: Setting to disable HTTP/2 Priorities
Archived-At: <>
X-Mailing-List: <> archive/latest/36876
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Personal opinion, not backed by any browser stack:  Browsers have seen some benefits from the current prioritization scheme when implemented by both server and client.  If you are able to implement it, you'll likely improve your performance with browsers that currently send priority information.  When there's a new scheme, there will likely be some negotiation mechanism to determine what the peers support.  I doubt that the client with existing implementations will quickly rip them out; your work would continue to be leveraged while the replacement is being developed and by older browsers in the future.

I don't think it would be wasted work, particularly if your client population already sends priorities; however, it's likely that a few years from now, it would be less-exercised code that might need maintenance.  That's the balance you have to weigh; I don't know what the drop-off curve or the maintenance cost will look like.

Again, the point isn't that the priority scheme in RFC7540 doesn't provide benefit -- it's that it's over-general and therefore not getting good traction in the ecosystem.

-----Original Message-----
From: Willy Tarreau <> 
Sent: Monday, July 29, 2019 11:51 PM
To: Kazuho Oku <>
Cc: Mike Bishop <>be>; Lucas Pardue <>om>; Brad Lassey <>rg>; HTTP Working Group <>
Subject: Re: Setting to disable HTTP/2 Priorities

On Tue, Jul 30, 2019 at 10:06:14AM +0900, Kazuho Oku wrote:
> 2019?7?30?(?) 4:41 Mike Bishop <>be>:
> >
> > Both are issues.  I think the first order of business is to know whether the peer supports PRIORITY. If the client doesn't, the server might choose to be more aggressive about making its own inferences.  If the server doesn't, the client might as well save some bytes and might choose to delay low-priority requests on the assumption the server will be assuming the requests are in priority order.
> +1.
> I think that the proposed settings is the right way to go.

I agree, this is fast and clean.

> Even though
> it is sometimes the issue with endpoints using priorities incorrectly 
> (e.g., a web browser assigning different "weights" based on the type 
> of the resource), introducing the proposed settings would be the 
> correct thing to do in order to sunset the H2 prioritization scheme.

I just have a practical question : does this mean I'll waste my time if I implement H2 priorities in haproxy ? I mean, if there's a general consensus that this is counter-productive or if browsers are thinking about abandoning priorities, I probably have better to work on. If it's only for certain corner cases that priorities should be abandoned and that they are still valuable, I can continue to work on this. I'm interested on any advice on this!