Re: new type number versus repurpose of existing field | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

Lucas Pardue <> Thu, 08 August 2019 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43EF612003E for <>; Thu, 8 Aug 2019 15:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 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.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 1rM_FpJwtFG9 for <>; Thu, 8 Aug 2019 15:41:19 -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 E88D412002F for <>; Thu, 8 Aug 2019 15:41:18 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hvr4B-0000sn-Ag for; Thu, 08 Aug 2019 22:39:27 +0000
Resent-Date: Thu, 08 Aug 2019 22:39:27 +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 1hvr48-0000rx-9s for; Thu, 08 Aug 2019 22:39:24 +0000
Received: from ([2607:f8b0:4864:20::92e]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hvr46-0002mA-VY for; Thu, 08 Aug 2019 22:39:24 +0000
Received: by with SMTP id j21so37061209uap.2 for <>; Thu, 08 Aug 2019 15:39:02 -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=5X16ou5PEnYLLvAW2P8nXsdoSttVaORG7whGpkpuB7Q=; b=CxOub1oR9qfOC4Vp6Mnf4cv+nXHBZbiPv1LL0dC9KcphqKBYk3k4VrzxXMqtc9XokU 7TqQUTN6XWvB2kT/t93nSnXmtkZHNV68dlWcbtA1ShzDqw6AauIZkV5gvNWWsS1O4XwZ 3EJndHH1v0Pic6hyHch0wZwgtv/ifgcZVBjt3QhWm/Xh48WHPa8Ehl5vCJPwgZOS9aFj CAsTwQnhxtHvNnXrt9SJmkkGBF1ekkKrjPqZIw1ZD8Gk6M83sKtNnkb8r+Sspup9oSf3 W9+tdvtX57yrOq1kBWU3cDxMlXOaW4CPRBtCWQvjddc6wp13tDU3NwNhEKxTtGopBX7c Fvvw==
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=5X16ou5PEnYLLvAW2P8nXsdoSttVaORG7whGpkpuB7Q=; b=bp9HZZchqzEeUWV78DfGZ8e3IeqbE8GBUbqMVVCUfM4x/fIYLqHgahCGptHzQvXQW1 /tFLSJ3xFCj1mGqp4AjunQ7FpB995b1Z76b9kk2XYWZ3NPhUejTyZaj9QZRX+IXADsMF etIWn27p2+bPr3+3tVDD6kDPza0PTYHkhvk9UOWEl4lCP+HtCN1gtanCSxLh40CMMDND dGACsICRAhzAo8/aepLdwUUPl67RsmWQzEHSsZqJuugg2wnqY4M47N/xmX96n0kIknun J7JZYyy56MLimRGPtWu/JlLdXjWaXmMFpAhCkSVmizG88vFtUq4C4vX/QyLWys/I5a3e erzQ==
X-Gm-Message-State: APjAAAV79ZmAvU6Zk3r4S5l554WQF61VqH/rrnuZmuOeCfIcD9ubskvS gcnmC+ymt3fW/sb1x7tFAwib9uWplv84MxX17K8=
X-Google-Smtp-Source: APXvYqwuB9yo40G7r0rrMNGi7C0AwudekyfKoKwD6mKVKXtYV0u/GATebQzyCYSPib5roS07e3F8kc/x1SF9gSLO8JI=
X-Received: by 2002:ab0:2789:: with SMTP id t9mr11010342uap.69.1565303941872; Thu, 08 Aug 2019 15:39:01 -0700 (PDT)
MIME-Version: 1.0
References: <20190725191746.GB12596@ubuntu-dmitri> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 8 Aug 2019 23:38:50 +0100
Message-ID: <>
To: Matthew Kerwin <>
Cc: Kari Hurtta <>, HTTP Working Group <>, Brad Lassey <>, Dmitri Tikhonov <>
Content-Type: multipart/alternative; boundary="0000000000006bc2d4058fa2b914"
Received-SPF: pass client-ip=2607:f8b0:4864:20::92e;;
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: 1hvr46-0002mA-VY d0aad336871c03f12080591d4b30a928
Subject: Re: new type number versus repurpose of existing field | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities
Archived-At: <>
X-Mailing-List: <> archive/latest/36954
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, 8 Aug 2019, 23:16 Matthew Kerwin, <> wrote:

> On Fri, 9 Aug 2019 at 03:58, Lucas Pardue <>
> wrote:
>> Note that it is not my suggestion to do the experiment this way. However,
>> one could theorise that the work required to support generating, sending,
>> receiving and processing new non-core frame types is greater than
>> implementing some conditional code inside the frame parser.
> One could also theorise the opposite.  For example: if someone had thought
> to construct their core H2 engine in such a way that it offloads extension
> values to modular/pluggable handlers.

> It doesn't make sense to override an auxiliary frame like that, especially
> just to appease implementers -- it's not like PRIORITY is welded to the
> heart of the machine, like HEADERS.

HEADERS contain priority information. To experiment with priority requires
a change to how HEADERS are used. Theres no avoiding that. We can split
hairs on what the best way to design an experiment like this would be but
it feels like wasted effort.

Anyone that designed and produced an implementation that allows an easily
usable extension mechanism that can completely substitute aspects of the
core HTTP/2 machinery deserves a gold star.

> Yes frames are cheap, but they also offer an API surface that things get
>> sticky to. For example, reporting and metrics based on frame type counts
>> etc. That adds more overhead to an ad-hoc short-lived data-gathering
>> experiment.
> Good?  Resist the sticky interface.  (BTW, on metrics: how much easier is
> it to report on "unknown frame type 0xD" as opposed to "frame that looks
> like 0x2 but actually isn't because of the contents of some settings
> frames sent elsewhere on this connection"?)

Simple frame counts have a place but there are likely higher-order things
going on. A reporting pipeline for HEADERS information is likely more
focused on the header contents characteristics than the priority
information. Defining a substitute HEADERS extension frame could require a
duplicate pipeline. Things like that provide resistance to experimentation.