Re: reserved bit from Flags field | Re: new type number versus repurpose of existing field | … | Re: Setting to disable HTTP/2 Priorities

[Kari Hurtta <[e-mail]>]

Lucas Pardue <[e-mail]>: (Fri Aug  9 13:08:52 2019)
> I'd treat both options as a class of change that RFC 7540 says MUST be
> negotiated:
> 
>    Extensions that could change the semantics of existing protocol
>    components MUST be negotiated before being used.  For example, an
>    extension that changes the layout of the HEADERS frame cannot be used
>    until the peer has given a positive signal that this is acceptable.
> 
> 
> Changing frame flags relies on implementations both understanding the flag
> and its meaning, which is difficult to do in an uncoordinated and robust
> way. For example, adding a field and setting a flag that no one knows to
> check will likely result in extant HEADERS frame parsers detecting a . size
> error, resulting in a connection error. That's pretty high risk.

Yes. Recipient of these changed frames needs send first SETTINGS frame
(for example) which it tells that that change is supported.

Also new type codes for HEADERS and PRIORITY frames need similar negotiation
(because accounting of frames and HPACK is affected; they can not just
ignored as unknwon frame type codes are ignored).
 
> Lucas

/ Kari Hurtta