Extensible Prioritization Scheme for HTTP
Extracted elements (28)
Absence of a priority parameter in a server's Priority response header field means the server does not wish to override the client-provided value for that parameter. This differs from a request header, where omission implies the parameter's default value. This asymmetry allows servers to selectively override only the parameters they care about.
RFC 7540 stream priority uses a complex dependency-tree model that suffered from limited deployment, poor interoperability, and no server-to-intermediary signal path. Independent research showed simpler absolute-value schemes achieve equivalent or better performance, motivating the new extensible scheme.
The Priority header field is defined as end-to-end rather than hop-by-hop because the way a client processes a response is a property of the client, not an intermediary. Being end-to-end also allows caching intermediaries to store and reuse the Priority value with the cached response.
HTTP/2 retains RFC 7540 stream priority wire elements for compatibility, so these signals may still appear even when SETTINGS_NO_RFC7540_PRIORITIES is negotiated. Implementations using extensible priorities may encounter both signal types simultaneously.
When a CDN front end demultiplexes HTTP/2 or HTTP/3 connections to HTTP/1.x backends, backend servers MAY use Priority header fields for request scheduling but SHOULD only do so where the priority information can be scoped to individual end clients via authentication or session linkage.
When an intermediary coalesces requests from multiple clients onto a single backend connection, naively honoring Priority signals from one client may starve responses to another. Servers aware of coalescing intermediaries (detectable via Forwarded, X-Forwarded-For, or Via headers) should consider distributing bandwidth more fairly.
A server that receives SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 MUST ignore HTTP/2 priority signals sent by clients.
Before receiving the server's first SETTINGS frame, a client SHOULD send both HTTP/2 priority signals and the extensible priority signals simultaneously. Once the client receives SETTINGS_NO_RFC7540_PRIORITIES=1 from the server, it SHOULD stop sending HTTP/2 priority signals to avoid redundant signaling.
For HTTP/2, the number of streams prioritized but in the idle state plus the number of active streams MUST NOT exceed SETTINGS_MAX_CONCURRENT_STREAMS. A server receiving a PRIORITY_UPDATE that violates this MUST respond with a connection error of type PROTOCOL_ERROR.
It is RECOMMENDED that servers respect the incremental parameter. Incremental responses of the same urgency SHOULD be served by sharing bandwidth among them rather than serializing. Servers are RECOMMENDED to avoid starvation when mixing incremental and non-incremental responses at the same urgency level.
It is RECOMMENDED that servers respect the urgency parameter and send higher-urgency responses before lower-urgency responses when possible. Non-incremental responses of the same urgency SHOULD be served in ascending order of stream ID (request order).
Servers SHOULD buffer the most recently received PRIORITY_UPDATE frame and apply it once the referenced stream is opened, to handle the race condition where a PRIORITY_UPDATE arrives before the referenced stream is opened. Only the most recent frame per stream needs to be stored.
The HTTP/3 PRIORITY_UPDATE frame MUST be sent on the client control stream; receiving it on any other stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. Servers MUST NOT send PRIORITY_UPDATE frames of either type; a client receiving one MUST treat it as H3_FRAME_UNEXPECTED.
The HTTP/3 request-stream PRIORITY_UPDATE (0xF0700) MUST reference a request stream; referencing a non-request stream MUST be treated as a connection error of type H3_ID_ERROR. The push-stream variant (0xF0701) MUST reference a promised push stream; referencing an unpromised or out-of-range push ID MUST be treated as H3_ID_ERROR.
The Stream Identifier field in an HTTP/2 PRIORITY_UPDATE frame header MUST be zero (0x0); any other value MUST be treated as a connection error of type PROTOCOL_ERROR. Servers MUST NOT send PRIORITY_UPDATE frames; a client receiving one MUST respond with a connection error of type PROTOCOL_ERROR.
The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1; any other value MUST be treated as a connection error of type PROTOCOL_ERROR. Endpoints MUST send this setting in the first SETTINGS frame only; senders MUST NOT change it afterward.
Unknown priority parameters MUST be ignored. New priority parameters SHOULD NOT change the interpretation of urgency or incremental in a way that is not backwards-compatible, so that endpoints that do not recognize them can safely continue using the base eight urgency levels.
Priority parameters are key-value pairs encoded as a Structured Fields Dictionary. This document defines the urgency (u) and incremental (i) parameters. Unknown parameters, out-of-range values, and unexpected types MUST be ignored.
SETTINGS_NO_RFC7540_PRIORITIES is an HTTP/2 settings parameter (code 0x9, initial value 0) that allows endpoints to signal they will not use or will ignore RFC 7540 stream priority signals. A value of 1 means the sender will not use HTTP/2 priority signals.
The incremental (i) parameter is a Structured Fields Boolean (default false) indicating whether the client can usefully process response bytes as they arrive incrementally. Servers may use this to decide whether to multiplex bandwidth across responses of equal urgency.
The Priority HTTP header field is a Structured Fields Dictionary carrying priority parameters. It is an end-to-end header that may appear in both requests (client-to-server) and responses (server-to-intermediary), and is independent of HTTP version.
The PRIORITY_UPDATE frame is a hop-by-hop signal sent by clients on the control stream to set or change the priority of a request or push stream, independently of the stream carrying the response. It carries a complete set of all priority parameters; omitting a parameter signals use of its default value.
The urgency (u) parameter is a Structured Fields Integer between 0 (highest priority) and 7 (lowest) inclusive, with a default of 3. Urgency 7 is reserved for background tasks such as software updates and SHOULD NOT be used for responses that affect user interaction.
This document creates the 'Hypertext Transfer Protocol (HTTP) Priority' registry at IANA, initially populated with urgency (u) and incremental (i). Single-character keys require Specification Required; longer keys use Expert Review. It also registers: Priority in the HTTP Field Name Registry, SETTINGS_NO_RFC7540_PRIORITIES (0x9) in HTTP/2 Settings, PRIORITY_UPDATE (0x10) in HTTP/2 Frame Types, and PRIORITY_UPDATE (0xF0700-0xF0701) in HTTP/3 Frame Types.
Servers that buffer PRIORITY_UPDATE frames for streams not yet opened must bound the resources allocated, as there is no protocol limit on the number of PRIORITY_UPDATE frames a client may send. Implementations should store only the most recently received frame per stream to cap resource use.
Servers that strictly honor urgency-based scheduling may be starved of the ability to transmit lower-urgency responses if a client sends a continuous stream of high-urgency requests. Server implementations should take measures to avoid such starvation.
The HTTP/2 PRIORITY_UPDATE frame (type=0x10) contains: a 24-bit Length, 8-bit Type, 8 unused flag bits, 1 reserved bit + 31-bit Stream Identifier (must be 0x0), 1 reserved bit + 31-bit Prioritized Stream ID, and a variable-length Priority Field Value in ASCII Structured Fields encoding.
The HTTP/3 PRIORITY_UPDATE frame uses type 0xF0700 for request streams and 0xF0701 for push streams. Its payload contains: a variable-length integer Prioritized Element ID (stream ID or push ID) and a variable-length Priority Field Value in ASCII Structured Fields encoding.