Re: Setting to disable HTTP/2 Priorities

Willy Tarreau <w@1wt.eu> Fri, 26 July 2019 03:22 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941C8120281 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Jul 2019 20:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdAy9GjUcght for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Jul 2019 20:22:43 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [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 ietfa.amsl.com (Postfix) with ESMTPS id 6F8CB12027E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Jul 2019 20:22:43 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hqqlg-0004SL-TD for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Jul 2019 03:19:40 +0000
Resent-Date: Fri, 26 Jul 2019 03:19:40 +0000
Resent-Message-Id: <E1hqqlg-0004SL-TD@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <w@1wt.eu>) id 1hqqle-0004RZ-AZ for ietf-http-wg@listhub.w3.org; Fri, 26 Jul 2019 03:19:38 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.89) (envelope-from <w@1wt.eu>) id 1hqqlc-0002eo-I1 for ietf-http-wg@w3.org; Fri, 26 Jul 2019 03:19:38 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x6Q3JC6j029657; Fri, 26 Jul 2019 05:19:12 +0200
Date: Fri, 26 Jul 2019 05:19:12 +0200
From: Willy Tarreau <w@1wt.eu>
To: Brad Lassey <lassey@chromium.org>
Cc: ietf-http-wg@w3.org
Message-ID: <20190726031912.GB29509@1wt.eu>
References: <CALjsk164zz+nDy5ZmOhvCscBQrBNMKTW0fz7Zxy=KtVx+ktz+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALjsk164zz+nDy5ZmOhvCscBQrBNMKTW0fz7Zxy=KtVx+ktz+Q@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=1.084, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hqqlc-0002eo-I1 2e140f92c7562596907d1327a6504106
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Setting to disable HTTP/2 Priorities
Archived-At: <https://www.w3.org/mid/20190726031912.GB29509@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36841
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Brad,

On Thu, Jul 25, 2019 at 02:49:52PM -0400, Brad Lassey wrote:
> Hi all,
> Lucas and I put together a draft to capture at least one of the ways
> forward that were identified at the priorities side meeting yesterday
> morning. Please have a look.
> 
> https://datatracker.ietf.org/doc/draft-lassey-priority-setting/
> https://github.com/bslassey/priority-setting

While I think that's a very wise approach, I think it would have more
success if it doesn't change the default behaviour. I mean, some
developers on both sides have gone through great length implementing
priorities and expecting now that they should suddenly have to add
extra code to continue to use them might be difficult to accept.
Conversely, all those who didn't implement them would have a great
incentive to add a few lines of code to signal their lack of support
and immediately expect a better experience. Thus I think priorities
should remain enabled unless signaled as disabled by this new setting.

And for having been late to implement them into haproxy (still not
present), I'd definitely adopt this proposal as a temporary measure
if it helps improve user experience!

Cheers,
Willy