Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

Matthew Kerwin <> Wed, 31 July 2019 23:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A5E21200FF for <>; Wed, 31 Jul 2019 16:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zNjTPDgDLOmy for <>; Wed, 31 Jul 2019 16:12:27 -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 D79721200B5 for <>; Wed, 31 Jul 2019 16:12:26 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hsxjf-0006tH-BO for; Wed, 31 Jul 2019 23:10:19 +0000
Resent-Date: Wed, 31 Jul 2019 23:10:19 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hsxjc-0006sW-NU for; Wed, 31 Jul 2019 23:10:16 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hsxjZ-0005qM-Uv for; Wed, 31 Jul 2019 23:10:16 +0000
Received: by with SMTP id f4so140120364ioh.6 for <>; Wed, 31 Jul 2019 16:09:53 -0700 (PDT)
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=kQYKdSXEBbJAqGde3gHqhedEBqY1GwnkxLScukwytI0=; b=YwUbFikEtNnbXN7ChRosheM/ixz1osEkNrQ6M6iGldZ5MRIKfDIBa+md6Uj9YpRayq 2527PQDS65gZsTglnQVstj4t4JAO3/NiQorxpmE9Mlb8kKjIrjncv/EFP0UcJ3X8yMz+ WqvMRryBrEUVfTa2YOztmGdqemGmUyR7l4+pc/Nej0EKBc5E8JXxDyDMdqhhPDDdSt3x mT511T91c+/Uqc+sxv1amW/NLrn4bIv/0Med6QChcoqgw3HuHm+8ud7LbXkpA1wIkPaw Rlt2QMctTDf7L06tQ8OKNz0r/iyfCmwKCDp7O7DcTkCUWwGS3xZjqOWvJfVJV35LJL1W f0DA==
X-Gm-Message-State: APjAAAV7GWT72Zciw7L6ZyrfjVvuL7tLrqDCfwXUqZW5/ohCLYA0kHGR exUnRZzvrGwXFFu0Ln5Od4Gm8yrjhDhmUt/pdC4=
X-Google-Smtp-Source: APXvYqxKYqP/yeJQ3RPEs+5Ry8VUIhr/V8fthpSYtuClS1PahDSFvPRr75fX824KnDI9Ryzfu2G0W0WaNYKiz4HW6oU=
X-Received: by 2002:a05:6602:1d2:: with SMTP id w18mr2996716iot.157.1564614592917; Wed, 31 Jul 2019 16:09:52 -0700 (PDT)
MIME-Version: 1.0
References: <20190725191746.GB12596@ubuntu-dmitri> <> <> <> <>
In-Reply-To: <>
From: Matthew Kerwin <>
Date: Thu, 1 Aug 2019 09:09:43 +1000
Message-ID: <>
To: Lucas Pardue <>
Cc: Kari Hurtta <>, HTTP Working Group <>, Brad Lassey <>, Dmitri Tikhonov <>
Content-Type: multipart/alternative; boundary="00000000000005767a058f0239a7"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Scan-Sig: 1hsxjZ-0005qM-Uv 7a77ae3d46b29cafd717f3547225e3d0
Subject: Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities
Archived-At: <>
X-Mailing-List: <> archive/latest/36895
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Wed, 31 Jul 2019 at 21:02, Lucas Pardue <>

> Hi Matthew,
> On Tue, 30 Jul 2019, 22:25 Matthew Kerwin, <> wrote:
>> At the risk of bike-shedding, I think calling it "enable" is a bit of an
>> issue. The setting, as an advertisement of the sender's capability, should
>> say something like "will ignore" (for disabling 7540 priorities) or "can
>> understand" (for enabling some other scheme).
>> Unless we also feel the need to advertise "will not send"?
> It's difficult for a server to guess at the client intent. Not sending
> PRIORITY information is also a signal to prioritise the request with
> default RFC7540 parameters (depend on root node with weight 16). So having
> a clear signal from client to server along the lines of "I don't intend to
> send, and don't infer any RFC7540 meaning from it" avoids that problem and
> my impression from Montreal was that this is a desirable goal.

A hint, then.  Different from all the "I will understand if you do this"
settings.  I feel it's important to reiterate, though, that the setting *can
not* say "don't infer meaning from it" -- you can't use a setting to tell
the other end how to respond to your frames, only how you will respond to

What happens if the client connects to a server that doesn't understand the
setting?  Are you using it as a negotiation-lite signal, so the client
won't switch off its 7540-priority-tree code path until both ends have said
they're happy doing so?

> In Montreal we also discussed a possible experiment where the H2 PRIORITY
> frame contents would be repurposed, which requires a compatible server to
> read it correctly. In this case the signal would be more like "will send in
> an RFC7540-incompatible format".
> Lucas

Eurgh, why?  Are we that short on frame types?

  Matthew Kerwin