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

[Lucas Pardue <[e-mail]>]

On Thu, 8 Aug 2019, 23:16 Matthew Kerwin, <[e-mail]> wrote:

>
>
> On Fri, 9 Aug 2019 at 03:58, Lucas Pardue <[e-mail]>
> 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.