HTTP/2 (RFC7540) tree priorities exit (opt out) | Re: ENABLE ⇒ PROVIDE | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

> Thanks. Along that line of thinking, maybe its simpler just to represent
> this as an opt out flag? E.g. SETTINGS_RFC7540_PRIORITY_OPT_OUT which can
> only ever be a value of 1. By default H2 endpoints have opted in and they
> have a freedom to opt out. However, once they do so there are no take
> backs.
> 
> Lucas
> 
> P.s.the cynic in me would call this SETTINGS_PREXIT. An endpoint that
> invokes RFCticle 9050,  needs to select a new deal or crash out to WT(FIF)O
> priorities.
> 

If peer implements HTTP/2 (RFC7540) tree priorities but is willing
also to use other priority scheme, then either

 • HTTP/2 (RFC7540) tree priorities must be active until
   both peers have sent and received SETTINGS frame
   with HTTP/2 (RFC7540) tree priority opt out, 

or

 • peer needs delay sending SETTINGS frame with HTTP/2 (RFC7540) tree 
   priority opt out until it is received SETTINGS frame 
   which suggests some other priority scheme (or until server
   is received HTTP request with some other priority scheme).


So it is important to consider how selecting some other priority scheme
and opting out HTTP/2 (RFC7540) tree priorities interacts.



I notice that SETTINGS parameter, which suggests of some other priority scheme 
( or set of schemes), work as HTTP/2 (RFC7540) tree priority opt
out IF initial value for that SETTINGS parameter is allowed to be unset.

So SETTINGS_PRIORITY_MASK which I mentioned on other post may
work if it's initial value is unset on HTTP/2 ( but 0 on HTTP/3).

On that case

HTTP/2 (RFC7540) tree priorities are active until peer
is sent AND received SETTINGS frame with SETTINGS_PRIORITY_MASK
parameter.

So to crash out to WT(FIF)O priorities is sending SETTINGS frame with
SETTINGS_PRIORITY_MASK value 0 (and receiving SETTINGS frame with
any SETTINGS_PRIORITY_MASK value).


In that case HTTP/2 (RFC7540) tree priorities also remain active
if either peer does not implement SETTINGS_PRIORITY_MASK parameter.

( Assuming that HTTP/2 (RFC7540) tree priorities are implemented. )

I do not know can initial value for some SETTINGS paramater to be
considered unset where unset is special meaning.


If SETTINGS_PRIORITY_MASKS can not have initial unset value but 
it's value is allowed to include bit for HTTP/2 tree priorities,
it also works. In that case initial value on HTTP/2 for
SETTINGS_PRIORITY_MASKS includes only bit for HTTP/2 tree priorites.

Calculating of new available priority scheme set must be delayed
until SETTINGS frame with SETTINGS_PRIORITY_MASKS paramater
is sent AND received.

/ Kari Hurtta

Received on Thursday, 1 August 2019 04:42:30 UTC