2. Motivation for Replacing RFC 7540 Stream Priorities
RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex system where clients signal stream dependencies and weights to describe an unbalanced tree. It suffered from limited deployment and interoperability and has been deprecated in a revision of HTTP/2 [HTTP/2]. HTTP/2 retains these protocol elements in order to maintain wire compatibility (see Section 5.3.2 of [HTTP/2]), which means that they might still be used even in the presence of alternative signaling, such as the scheme this document describes.
Many RFC 7540 server implementations do not act on HTTP/2 priority signals.
Prioritization can use information that servers have about resources or the order in which requests are generated. For example, a server, with knowledge of an HTML document structure, might want to prioritize the delivery of images that are critical to user experience above other images. With RFC 7540, it is difficult for servers to interpret signals from clients for prioritization, as the same conditions could result in very different signaling from different clients. This document describes signaling that is simpler and more constrained, requiring less interpretation and allowing less variation.
RFC 7540 does not define a method that can be used by a server to provide a priority signal for intermediaries.
RFC 7540 stream priority is expressed relative to other requests sharing the same connection at the same time. It is difficult to incorporate such a design into applications that generate requests without knowledge of how other requests might share a connection, or into protocols that do not have strong ordering guarantees across streams, like HTTP/3 [HTTP/3].
Experiments from independent research [MARX] have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the Web use case.
2.1. Disabling RFC 7540 Stream Priorities
The problems and insights set out above provided the motivation for an alternative to RFC 7540 stream priority (see Section 5.3 of [HTTP/2]).
The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this document in order to allow endpoints to omit or ignore HTTP/2 priority signals (see Section 5.3.2 of [HTTP/2]), as described below. 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 [HTTP/2]) of type PROTOCOL_ERROR. The initial value is 0.
If endpoints use SETTINGS_NO_RFC7540_PRIORITIES, they MUST send it in the first SETTINGS frame. Senders MUST NOT change the SETTINGS_NO_RFC7540_PRIORITIES value after the first SETTINGS frame. Receivers that detect a change MAY treat it as a connection error of type PROTOCOL_ERROR.
Clients can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to indicate that they are not using HTTP/2 priority signals. The SETTINGS frame precedes any HTTP/2 priority signal sent from clients, so servers can determine whether they need to allocate any resources to signal handling before signals arrive. A server that receives SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 MUST ignore HTTP/2 priority signals.
Servers can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to indicate that they will ignore HTTP/2 priority signals sent by clients.
Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to use alternative priority signals (for example, see Section 5 or Section 7.1), but there is no requirement to use a specific signal type.
2.1.1. Advice when Using Extensible Priorities as the Alternative
Before receiving a SETTINGS frame from a server, a client does not know if the server is ignoring HTTP/2 priority signals. Therefore, until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see Sections 5 and 7.1).
Once the client receives the first SETTINGS frame that contains the SETTINGS_NO_RFC7540_PRIORITIES parameter with a value of 1, it SHOULD stop sending the HTTP/2 priority signals. This avoids sending redundant signals that are known to be ignored.
Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with a 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. However, the client MAY continue sending the Priority header field (Section 5), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to.