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

[Lucas Pardue <[e-mail]>]

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.

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.

Lucas

On Thu, Aug 8, 2019 at 6:39 PM Kari Hurtta <[e-mail]>
wrote:

> <  ⋯ >
> > > 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?
> >
> > Cheers
> > --
> >   Matthew Kerwin
> >   https://matthew.kerwin.net.au/
>
> Yes, it makes sense to allocate new type number for PRIORITY when frame
> content is repurposed.
>
> Also is make sense to allocate new type number for HEADERS when
> "Stream Dependency" or "Weight" field of HEADERS frame conrent is
> repurposed.
>
> That avaind dance about on what point on time change of  "Stream
> Dependency" / "Weight" field"
> field happens.
>
>
> If you are running out of framer's type numbers, reserve some number for
> "extended type number". ☻
>
> / Kari Hurtta
>
>