Re: Comments on Extensible Prioritization Scheme for HTTP

On Thu, Mar 31, 2022 at 09:07:09AM +0200, Willy Tarreau wrote:
> Hello Glenn,
> 
> On Thu, Mar 31, 2022 at 01:21:42AM -0400, Glenn Strauss wrote:
> > 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.
> 
> It's not as much a desire to "disable" as it is an indication that
> it will neither emit nor process them.

I have proposed SETTINGS_ENABLE_PRIORITY w/ boolean to enable instead of
SETTINGS_NO_RFC7540_PRIORITIES w/ inverted boolean to enable.

> > 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.
> 
> But that wouldn't work with existing deployments! Right now support for
> priorities is implied by H2. Both a client and a server willing to use
> them have nothing to say, and any RFC7540-compliant implementation will
> see it like this. Thus a client may expect that the server will deliver
> important objects first and may possibly announce certain priorities
> based on what it thinks it needs. In fact both sides may act in a way
> that is supposed to help the other one based on the assumption that it
> will use it and benefit from this.

Since the PRIORITY frame type already exists, perhaps the default for
SETTINGS_ENABLE_PRIORITY should be 1 and a server can send
SETTINGS_ENABLE_PRIORITY 0 to mean the same thing as
SETTINGS_NO_RFC7540_PRIORITIES 1.  If not sent in the HTTP/2 server
connection preface, then the default remains.  I believe that this is
fully compatible with existing deployments.

However, given that the draft spec deprecates PRIORITY frames, I would
prefer that the default be SETTINGS_ENABLE_PRIORITY 0, and become an
opt-in.  For advanced systems attempting to leverage PRIORITY, I would
expect those systems to be better maintained and able to upgrade in a
reasonable timeframe, as compared to more typical, often non-existent
maintenance cycles.

Please understand that my primary reason for posting is to suggest a
pattern to follow for this and for future opt-in extensions.  The draft
for the proposed PRIORITY_UPDATE might result in unnecessary chatter by
new implementations assuming support for PRIORITY *and* PRIORITY_UPDATE,
whereas my proposed adjustments suggests a more determistic template for
opt-in extensions.

Cheers, Glenn

Received on Thursday, 31 March 2022 11:33:37 UTC