Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

[Matthew Kerwin <[e-mail]>]

On Wed, 31 Jul 2019 at 21:02, Lucas Pardue <[e-mail]>
wrote:

> Hi Matthew,
>
>
> On Tue, 30 Jul 2019, 22:25 Matthew Kerwin, <[e-mail]> wrote:
>
>>
>> At the risk of bike-shedding, I think calling it "enable" is a bit of an
>> issue. The setting, as an advertisement of the sender's capability, should
>> say something like "will ignore" (for disabling 7540 priorities) or "can
>> understand" (for enabling some other scheme).
>>
>> Unless we also feel the need to advertise "will not send"?
>>
>
> It's difficult for a server to guess at the client intent. Not sending
> PRIORITY information is also a signal to prioritise the request with
> default RFC7540 parameters (depend on root node with weight 16). So having
> a clear signal from client to server along the lines of "I don't intend to
> send, and don't infer any RFC7540 meaning from it" avoids that problem and
> my impression from Montreal was that this is a desirable goal.
>

A hint, then.  Different from all the "I will understand if you do this"
settings.  I feel it's important to reiterate, though, that the setting *can
not* say "don't infer meaning from it" -- you can't use a setting to tell
the other end how to respond to your frames, only how you will respond to
theirs.

What happens if the client connects to a server that doesn't understand the
setting?  Are you using it as a negotiation-lite signal, so the client
won't switch off its 7540-priority-tree code path until both ends have said
they're happy doing so?



> 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/