W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2022

Comments on Extensible Prioritization Scheme for HTTP

From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
Date: Thu, 31 Mar 2022 01:21:42 -0400
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: kazuhooku@gmail.com, lucaspardue.24.7@gmail.com
Message-ID: <YkU6IoXeg470P45G@xps13>
Comments on Extensible Prioritization Scheme for HTTP
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority-12

HTTP/2 SETTINGS frame in the original RFC7540 spec contains
  SETTINGS_ENABLE_PUSH
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
  SETTINGS_NO_RFC7540_PRIORITIES
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
  SETTINGS_ENABLE_PRIORITY
  SETTINGS_ENABLE_PRIORITY_UPDATE
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:
  SETTINGS_ENABLE_<feature>
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

This archive was generated by hypermail 2.4.0 : Thursday, 31 March 2022 05:25:38 UTC