Re: Comments on Extensible Prioritization Scheme for HTTP

[Willy Tarreau <[e-mail]>]

On Thu, Mar 31, 2022 at 09:46:19AM -0400, Glenn Strauss wrote:
> On Thu, Mar 31, 2022 at 01:06:45PM +0100, Lucas Pardue wrote:
> > It's noble to want a pattern but I don't think we have enough examples of
> > HTTP/2 extensions at the IETF to form consensus on one.
> 
> My understanding is that communicating/negotiating feature support
> is among the raison d'être of HTTP/2 SETTINGS.
> 
> Communicating and negotiating features is not new.  For example, the
> *1977* RFC 731 for telnet has IAC WILL/IAC WONT and IAC DO/IAC DONT.
> 
> I believe that draft-ietf-httpbis-priority for PRIORITY_UPDATE has
> serious omissions in this regard -- communicating and negotiating
> use of the optional feature -- especially since the draft recognizes
> limitations of PRIORITY and proposes an alternative to provide
> substantially overlapping functionality.

But why do you see it different here ? The optional feature here is
to give up on a previously implied one. As such there's a setting
which says exactly this, "let's enable this optional feature that
allows us to agree on giving up the default implied behaviour".

>  For example:
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority-12#section-2.1.1
> makes an assumption which I find incorrect.
> 
>    Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with
>    value of 0 or if the settings parameter was absent, it SHOULD stop
>    sending PRIORITY_UPDATE frames (Section 7.1), since those frames are
>    likely to be ignored.

I'm personally not seeing a problem here. What it says is that if the
peer announces that it doesn't want to abandon the default behavior,
the one seeing this must respect this and not switch to the alternate
one.

> My server (lighttpd) parses and discards PRIORITY frames, but I am
> planning on implementing the coarser, but simpler, PRIORITY_UPDATE,
> as well as supporting the proposed HTTP request header Priority.
> draft-ietf-httpbis-priority does not currently provide a clean way
> to communicate server HTTP/2 support preference for PRIORITY_UPDATE, 
> but not PRIORITY, to the client.  Using HTTP/2 SETTINGS appears to
> me to be a simple and an appropriate place to communicate this.

Not very sure what you mean here. As a server, you'll likely adapt to
what the client presents, so if you see SETTINGS_NO_RFC7540_PRIORITIES
advertised by the client, you'll likely advertise it as well to indicate
your willingness to switch to PRIORITY_UPDATE, or am I missing something ?

Willy