Comments on Extensible Prioritization Scheme for HTTP

Comments on Extensible Prioritization Scheme for HTTP

HTTP/2 SETTINGS frame in the original RFC7540 spec contains
This is a logical, boolean flag to enable an optional-use feature.

draft-ietf-httpbis-priority-12 has had multiple revisions with name
changes for a new setting, and the current proposed name is
with an *inverted boolean value*, which if set to *true* results in
indicating a desire to *disable* use of RFC7540 HTTP/2 PRIORITY frame.

I am a developer mocking up draft-ietf-httpbis-priority.
From my perspective, in order to follow a logical opt-in to enable use
of optional features, I prefer the following proposal: new SETTINGS
each named after the respective HTTP/2 frame type PRIORITY
and (proposed) PRIORITY_UPDATE.  These are named in similar pattern to
SETTINGS_ENABLE_PUSH feature, associated with HTTP/2 frame PUSH_PROMISE.

Similar to when a TLS client might send TLS early data, an HTTP/2 client
might optimistically send any of the above frames prior to receiving the
HTTP/2 server connection preface.  An HTTP/2 server may ignore unknown
frame types, so a client could determine that a server ignored those
early frames if the HTTP/2 server connection preface does not enable the
SETTINGS feature for supporting the (optional) frame type.  I think that
this is a good convention for optional features:
and optional features using new frame types tend to have the new frame
type named after the feature the new frame type supports.

For the existing HTTP/2 PRIORITY frame, a client would not definitively
know if PRIORITY is supported unless the server were to send
SETTINGS_ENABLE_PRIORITY, but existing support for HTTP/2 frame type
PRIORITY is not widespread, and use of the HTTP/2 PRIORITY frame is
deprecated in the draft being discussed: draft-ietf-httpbis-priority.

Cheers, Glenn

Received on Thursday, 31 March 2022 05:25:37 UTC