Re: Comments on Extensible Prioritization Scheme for HTTP

On Sat, Apr 09, 2022 at 02:37:56PM +0200, Willy Tarreau wrote:
> On Sat, Apr 09, 2022 at 07:25:57AM -0400, Glenn Strauss wrote:
> > For widest client compatibility, lighttpd also plan to omit sending
> > SETTINGS_NO_RFC7540_PRIORITIES=1
> 
> HAProxy doesn't implement priority either and currently sends nothing.
> However once this draft becomes standard, I plan to send this setting
> to inform compatible clients that they do not have to expect any
> particular behavior from it on this point. It's not a matter of client
> compatibility, H2 agents are required to ignore unkonwn settings, so
> those unaware of this setting will not change anything, while those
> aware of it will benefit from it.

It would be trivial for lighttpd to unconditionally send
SETTINGS_NO_RFC7540_PRIORITIES=1 with server connection preface.

However, I am choosing not to do so (at least for now) due to:
https://mikebishop.github.io/http-misc-extensions/draft-bishop-httpbis-grease.html
"The need for such a technique was demonstrated recently by an HTTP/2
 implementation which closed the connection upon receipt of an unknown
 setting."

I do not know which client this was or how widely it is used, but it is
mentioned in the grease draft as a good reason supporting greasing
HTTP/2 SETTINGS.

I have completed implementing PRIORITY_UPDATE on my public dev branch.
I want to avoid a lighttpd upgrade breaking an existing client when
PRIORITY_UPDATE is not yet standardized.

> > Currently, SETTINGS_NO_RFC7540_PRIORITIES=1 is proposed for client to
> > tell the server that the server need not keep RFC7540 PRIORITY state,
> > but existing clients do not send that, and many also do not utilize
> > PRIORITY.
> 
> The most important is that many clients *do* support priority, that
> these ones are already deployed and working fine, and that you cannot
> suddenly break them by telling them "ah, you didn't read the news, the
> default value recently changed and while you used to comply with the
> standard now you violate it".

Prioritization signals may be ignored by the server.  Clients will not
"break".  SETTINGS_NO_RFC7540_PRIORITIES=1 is not standardized, so it is
to be expected that most/all current clients do not send that setting,
and it is unknown when they will be upgraded, and when upgraded,
unknown if this will be a required setting.  For server implementations
which implement PRIORITY, this may be a missing signal.

Will a future revision of HTTP/2 include this signal, saying that a
client SHOULD send SETTINGS_NO_RFC7540_PRIORITIES=1 in the client
connection preface if the client does not intend to use RFC7540
PRIORITY?  Or will a future revision of HTTP/2 deprecate PRIORITY?

> > If PRIORITY gets deprecated, then over time, the sending of
> > SETTINGS_NO_RFC7540_PRIORITIES=1 will end up being wasted bytes.
> 
> Yes that's true. And probably that advertising the desired priority
> scheme number instead would be better, with 0=not supported,
> 1=default=RFC7540, 2=priority_update, and so on. At least these bytes
> would be re-usable for future schemes. But you cannot change the default
> that works fine between a non-negligible set of clients and servers.
...
> That's why one must never change default values once adopted, and why
> the default set must be well thought before a standard is released!

I agree with you that this setting might be better as an advertisement
of bitflags, supporting up to 32 different prioritization schemes,
with 0 indicating none supported.  (bitflags in one SETTING would be an
alternative to separate SETTINGs to enable PRIORITY, PRIORITY_UPDATE.)

That would suggest the server send something akin to
SETTINGS_PRIORITIZATION_SCHEMES
  0x0 none
  0x1 PRIORITY_UPDATE
  0x2 PRIORITY
  0x4 ???
  0x8 ...
and the flags can be OR'd together.

If the client sent SETTINGS_PRIORITIZATION_SCHEMES, that would be a hint
to the server, especially if the bitflag for PRIORITY were omitted so
that the server knows affirmatively that the server need not keep
PRIORITY state.

Absense of the setting from from server connection preface would
indicate RFC7540 defaults or could be affirmatively indicated with
  SETTINGS_PRIORITIZATION_SCHEMES=2

In the above
  SETTINGS_PRIORITIZATION_SCHEMES=1 == SETTINGS_NO_RFC7540_PRIORITIES=1
but 
  SETTINGS_PRIORITIZATION_SCHEMES=0 indicates no prioritization,
    as opposed to SETTINGS_NO_RFC7540_PRIORITIES=0 which indicates
    RFC7540 defaults, and could be equally achieved by omitting
    SETTINGS_NO_RFC7540_PRIORITIES=0.

Willy, I like your proposal to make the setting a more bona fide
advertisement and hope that the PRIORITY_UPDATE proposal authors will
take another look at SETTINGS_NO_RFC7540_PRIORITIES

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority-12#section-2.1
   The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any
   value other than 0 or 1 MUST be treated as a connection error (see
   Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR.  The initial value
   is 0.

Cheers, Glenn

Received on Saturday, 9 April 2022 13:58:38 UTC