Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9218.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

It is common for representations of an HTTP[HTTP]resource to have relationships to one or more other resources. Clients willoften discover these relationships while processing a retrieved representation,which may lead to further retrieval requests. Meanwhile, the nature of therelationships determines whether a client is blocked from continuing to processlocally available resources. An example of this is the visual rendering of an HTMLdocument, which could be blocked by the retrieval of a Cascading Style Sheets (CSS) file that thedocument refers to. In contrast, inline images do not block rendering and get drawnincrementally as the chunks of the images arrive.¶

HTTP/2[HTTP/2] and HTTP/3[HTTP/3] support multiplexing of requests and responses ina single connection. An important feature of any implementation of a protocolthat provides multiplexing is the ability to prioritize the sending ofinformation. For example, to provide meaningful presentation of an HTML documentat the earliest moment, it is important for an HTTP server to prioritize theHTTP responses, or the chunks of those HTTP responses, that it sends to aclient.¶

HTTP/2 and HTTP/3 servers can schedule transmission of concurrent response databy any means they choose. Servers can ignore client priority signals and stillsuccessfully serve HTTP responses. However, servers that operate in ignoranceof how clients issue requests and consume responses can cause suboptimal clientapplication performance. Priority signals allow clients to communicate theirview of request priority. Servers have their own needs that are independent ofclient needs, so they often combine priority signals with other availableinformation in order to inform scheduling of response data.¶

RFC 7540[RFC7540] stream priority allowed a client to send a series ofpriority signals that communicate to the server a "priority tree"; the structureof this tree represents the client's preferred relative ordering and weighteddistribution of the bandwidth among HTTP responses. Servers could use thesepriority signals as input into prioritization decisions.¶

The design and implementation of RFC 7540 stream priority were observed to haveshortcomings, as explained inSection 2. HTTP/2[HTTP/2] has consequently deprecated the use ofthese stream priority signals. The prioritization scheme and priority signalsdefined herein can act as a substitute for RFC 7540 stream priority.¶

This document describes an extensible scheme for prioritizing HTTP responsesthat uses absolute values.Section 4 defines priority parameters, which area standardized and extensible format of priority information.Section 5defines the Priority HTTP header field, which is anend-to-end priority signal that is independent of protocol version. Clients can send this header field to signal theirview of how responses should be prioritized. Similarly, servers behind anintermediary can use it to signal priority to the intermediary. After sending arequest, a client can change their view of response priority (seeSection 6) by sending HTTP-version-specific frames as defined inSections 7.1 and7.2.¶

Header field and frame priority signals are input to a server's responseprioritization process. They are only a suggestion and do not guarantee anyparticular processing or transmission order for one response relative to anyother response. Sections 10 and12 provideconsiderations and guidance about how servers might act upon signals.¶

2.Motivation for Replacing RFC 7540 Stream Priorities

RFC 7540 stream priority (seeSection 5.3 of [RFC7540]) is a complex systemwhere clients signal stream dependencies and weights to describe an unbalancedtree. It suffered from limited deployment and interoperability and has been deprecatedin a revision of HTTP/2[HTTP/2]. HTTP/2 retains these protocol elements inorder to maintain wire compatibility (seeSection 5.3.2 of [HTTP/2]), whichmeans 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 prioritysignals.¶

Prioritization can use information that servers have about resources orthe order in which requests are generated. For example, a server, with knowledgeof an HTML document structure, might want to prioritize the delivery of imagesthat are critical to user experience above other images. With RFC 7540, it isdifficult for servers to interpret signals from clients for prioritization, asthe same conditions could result in very different signaling from differentclients. 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 apriority signal for intermediaries.¶

RFC 7540 stream priority is expressed relative to other requests sharing the sameconnection at the same time. It is difficult to incorporate such a design intoapplications that generate requests without knowledge of how other requestsmight share a connection, or into protocols that do not have strong orderingguarantees across streams, like HTTP/3[HTTP/3].¶

Experiments from independent research[MARX] have shownthat simpler schemes can reach at least equivalent performance characteristicscompared to the more complex RFC 7540 setups seen in practice, at least for theWeb use case.¶

3.Applicability of the Extensible Priority Scheme

The priority scheme defined by this document is primarily focused on theprioritization of HTTP response messages (seeSection 3.4 of [HTTP]). Itdefines new priority parameters (Section 4) and a means of conveying thoseparameters (Sections 5 and7), which is intended to communicatethe priority of responses to a server that is responsible for prioritizingthem.Section 10 provides considerations for servers about acting onthose signals in combination with other inputs and factors.¶

The CONNECT method (seeSection 9.3.6 of [HTTP]) can be used to establishtunnels. Signaling applies similarly to tunnels; additional considerations forserver prioritization are given inSection 11.¶

Section 9 describes how clients can optionally apply elements ofthis scheme locally to the request messages that they generate.¶

Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream behavior ordefine new data carriage mechanisms. Such extensions can themselves definehow this priority scheme is to be applied.¶

4.Priority Parameters

The priority information is a sequence of key-value pairs, providing room forfuture extensions. Each key-value pair represents a priority parameter.¶

The Priority HTTP header field (Section 5) is an end-to-end way totransmit this set of priority parameters when a request or a response is issued.After sending a request, a client can change their view of response priority(Section 6) by sending HTTP-version-specific PRIORITY_UPDATE frames asdefined in Sections 7.1 and7.2. Frames transmit priorityparameters on a single hop only.¶

Intermediaries can consume and produce priority signals in a PRIORITY_UPDATEframe or Priority header field. An intermediary that passes only the Priorityrequest header field to the next hop preserves the original end-to-end signalfrom the client; seeSection 14.An intermediary could pass the Priority header field and additionally send a PRIORITY_UPDATE frame. This would have the effect of preserving the original client end-to-end signal, while instructing the next hop to use a different priority, per the guidance inSection 7. An intermediary that replaces or adds a Priority request header field overrides the original client end-to-end signal, which can affect prioritization for all subsequent recipients of the request.¶

For both the Priority header field and the PRIORITY_UPDATE frame, the set ofpriority parameters is encoded as a Dictionary (seeSection 3.2 of [STRUCTURED-FIELDS]).¶

This document defines the urgency (u) and incremental (i) priority parameters.When receiving an HTTP request that does not carry these priority parameters, aserverSHOULD act as if their default values were specified.¶

An intermediary can combine signals from requests and responses that it forwards.Note that omission of priority parameters in responses is handled differently fromomission in requests; seeSection 8.¶

Receivers parse the Dictionary as described inSection 4.2 of [STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed, this documentplaces the additional requirement that unknown priority parameters, priorityparameters with out-of-range values, or values of unexpected typesMUST beignored.¶

:method = GET:scheme = https:authority = example.net:path = /style.csspriority = u=0

:method = GET:scheme = https:authority = example.net:path = /image.jpgpriority = u=5, i

5.The Priority HTTP Header Field

The Priority HTTP header field is a Dictionary that carries priority parameters (seeSection 4).It can appear in requests and responses. It is an end-to-end signal thatindicates the endpoint's view of how HTTP responses should be prioritized.Section 8 describes how intermediaries can combine the priority informationsent from clients and servers. Clients cannot interpret the appearance oromission of a Priority response header field as acknowledgement that anyprioritization has occurred. Guidance for how endpoints can act on Priorityheader values is given in Sections 9 and10.¶

An HTTP request with a Priority header field might be cached and reused forsubsequent requests; see[CACHING]. When an originserver generates the Priority response header field based on properties of anHTTP request it receives, the server is expected to control the cacheability orthe applicability of the cached response by using header fields that controlthe caching behavior (e.g., Cache-Control, Vary).¶

6.Reprioritization

After a client sends a request, it may be beneficial to change the priority ofthe response. As an example, a web browser might issue a prefetch request for aJavaScript file with the urgency parameter of the Priority request header fieldset tou=7 (background). Then, when the user navigates to a page thatreferences the new JavaScript file, while the prefetch is in progress, thebrowser would send a reprioritization signal with the Priority Field Value settou=0. The PRIORITY_UPDATE frame (Section 7) can be used for suchreprioritization.¶

7.The PRIORITY_UPDATE Frame

This document specifies a new PRIORITY_UPDATE frame for HTTP/2[HTTP/2]and HTTP/3[HTTP/3]. It carries priority parameters andreferences the target of the prioritization based on a version-specificidentifier. In HTTP/2, this identifier is the stream ID; in HTTP/3, theidentifier is either the stream ID or push ID. Unlike the Priority header field,the PRIORITY_UPDATE frame is a hop-by-hop signal.¶

PRIORITY_UPDATE frames are sent by clients on the control stream, allowing themto be sent independently of the stream that carries the response. This meansthey can be used to reprioritize a response or a push stream, or to signal theinitial priority of a response instead of the Priority header field.¶

A PRIORITY_UPDATE frame communicates a complete set of all priority parametersin the Priority Field Value field. Omitting a priority parameter is a signal touse its default value. Failure to parse the Priority Field ValueMAY be treatedas a connection error. In HTTP/2, the error is of type PROTOCOL_ERROR; in HTTP/3,the error is of type H3_GENERAL_PROTOCOL_ERROR.¶

A clientMAY send a PRIORITY_UPDATE frame before the stream that it referencesis open (except for HTTP/2 push streams; seeSection 7.1). Furthermore,HTTP/3 offers no guaranteed ordering across streams, which could cause the frameto be received earlier than intended. Either case leads to a race conditionwhere a server receives a PRIORITY_UPDATE frame that references a request streamthat is yet to be opened. To solve this condition, for the purposes ofscheduling, the most recently received PRIORITY_UPDATE frame can be consideredas the most up-to-date information that overrides any other signal. ServersSHOULD buffer the most recently received PRIORITY_UPDATE frame and apply it oncethe referenced stream is opened. Holding PRIORITY_UPDATE frames for each streamrequires server resources, which can be bounded by local implementation policy.Although there is no limit to the number of PRIORITY_UPDATE frames that can besent, storing only the most recently received frame limits resource commitment.¶

HTTP/2 PRIORITY_UPDATE Frame {  Length (24),  Type (8) = 0x10,  Unused Flags (8),  Reserved (1),  Stream Identifier (31),  Reserved (1),  Prioritized Stream ID (31),  Priority Field Value (..),}

HTTP/3 PRIORITY_UPDATE Frame {  Type (i) = 0xF0700..0xF0701,  Length (i),  Prioritized Element ID (i),  Priority Field Value (..),}

8.Merging Client- and Server-Driven Priority Parameters

It is not always the case that the client has the best understanding of how theHTTP responses deserve to be prioritized. The server might have additionalinformation that can be combined with the client's indicated priority in orderto improve the prioritization of the response. For example, use of an HTMLdocument might depend heavily on one of the inline images; the existence of suchdependencies is typically best known to the server. Or, a server that receivesrequests for a font[RFC8081] and images with the same urgency might givehigher precedence to the font, so that a visual client can render textualinformation at an early moment.¶

An origin can use the Priority response header field to indicate its view on howan HTTP response should be prioritized. An intermediary that forwards an HTTPresponse can use the priority parameters found in the Priority response headerfield, in combination with the client Priority request header field, as input toits prioritization process. No guidance is provided for merging priorities; thisis left as an implementation decision.¶

The absence of a priority parameter in an HTTP response indicates the server'sdisinterest in changing the client-provided value. This is different from therequest header field, in which omission of a priority parameter implies the use of its default value (seeSection 4).¶

As a non-normative example, when the client sends an HTTP request with theurgency parameter set to5 and the incremental parameter set totrue¶

:method = GET:scheme = https:authority = example.net:path = /menu.pngpriority = u=5, i

and the origin responds with¶

:status = 200content-type = image/pngpriority = u=1

the intermediary might alter its understanding of the urgency from5 to1,because it prefers the server-provided value over the client's. The incrementalvalue continues to betrue, i.e., the value specified by the client, as the server didnot specify the incremental (i) parameter.¶

9.Client Scheduling

A clientMAY use priority values to make local processing or scheduling choicesabout the requests it initiates.¶

10.Server Scheduling

It is generally beneficial for an HTTP server to send all responses as early aspossible. However, when serving multiple requests on a single connection, therecould be competition between the requests for resources such as connectionbandwidth. This section describes considerations regarding how servers canschedule the order in which the competing responses will be sent when suchcompetition exists.¶

Server scheduling is a prioritization process based on many inputs, withpriority signals being only one form of input. Factors such as implementationchoices or deployment environment also play a role. Any given connection islikely to have many dynamic permutations. For these reasons, it is not possibleto describe a universal scheduling algorithm. This document provides some basic,non-exhaustive recommendations for how servers might act on priorityparameters. It does not describe in detail how servers might combine prioritysignals with other factors. Endpoints cannot depend on particular treatmentbased on priority signals. Expressing priority is only a suggestion.¶

It isRECOMMENDED that, when possible, servers respect the urgency parameter(Section 4.1), sending higher-urgency responses before lower-urgency responses.¶

The incremental parameter indicates how a client processes response bytes asthey arrive. It isRECOMMENDED that, when possible, servers respect theincremental parameter (Section 4.2).¶

Non-incremental responses of the same urgencySHOULD be served by prioritizingbandwidth allocation in ascending order of the stream ID, which corresponds tothe order in which clients make requests. Doing so ensures that clients can userequest ordering to influence response order.¶

Incremental responses of the same urgencySHOULD be served by sharing bandwidthamong them. The message content of incremental responses is used as parts, or chunks,are received. A client might benefit more from receiving a portion of allthese resources rather than the entirety of a single resource. How large aportion of the resource is needed to be useful in improving performance varies.Some resource types place critical elements early; others can use informationprogressively. This scheme provides no explicit mandate about how a servershould use size, type, or any other input to decide how to prioritize.¶

There can be scenarios where a server will need to schedule multiple incrementaland non-incremental responses at the same urgency level. Strictly abiding by thescheduling guidance based on urgency and request generation order might leadto suboptimal results at the client, as early non-incremental responses mightprevent the serving of incremental responses issued later. The following areexamples of such challenges:¶

1. At the same urgency level, a non-incremental request for a large resourcefollowed by an incremental request for a small resource.¶
2. At the same urgency level, an incremental request of indeterminate lengthfollowed by a non-incremental large resource.¶

It isRECOMMENDED that servers avoid such starvation where possible. The methodfor doing so is an implementation decision. For example, a server mightpreemptively send responses of a particular incremental type based on otherinformation such as content size.¶

Optimal scheduling of server push is difficult, especially when pushed resourcescontend with active concurrent requests. Servers can consider many factors whenscheduling, such as the type or size of resource being pushed, the priority ofthe request that triggered the push, the count of active concurrent responses,the priority of other active concurrent responses, etc. There is no generalguidance on the best way to apply these. A server that is too simple couldeasily push at too high a priority and block client requests, or push at too lowa priority and delay the response, negating intended goals of server push.¶

Priority signals are a factor for server push scheduling. The concept ofparameter value defaults applies slightly differently because there is noexplicit client-signaled initial priority. A server can apply priority signalsprovided in an origin response; see the merging guidance given inSection 8.In the absence of origin signals, applying default parameter values could besuboptimal. By whatever means a server decides to schedule a pushed response, itcan signal the intended priority to the client by including the Priority fieldin a PUSH_PROMISE or HEADERS frame.¶

11.Scheduling and the CONNECT Method

When a stream carries a CONNECT request, the scheduling guidance inthis document applies to the frames on the stream. A client that issues multipleCONNECT requests can set the incremental parameter totrue. Servers thatimplement the recommendations for handling of the incremental parameter (Section 10) are likely to schedule these fairly, preventing oneCONNECT stream from blocking others.¶

12.Retransmission Scheduling

Transport protocols such as TCP and QUIC provide reliability by detecting packetlosses and retransmitting lost information. In addition to the considerations inSection 10, scheduling of retransmission data could compete with newdata. The remainder of this section discusses considerations when using QUIC.¶

Section 13.3 of [QUIC] states the following: "EndpointsSHOULD prioritizeretransmission of data over sending new data, unless priorities specified by theapplication indicate otherwise". When an HTTP/3 application uses the priorityscheme defined in this document and the QUIC transport implementation supportsapplication-indicated stream priority, a transport that considers the relativepriority of streams when scheduling both new data and retransmission data mightbetter match the expectations of the application. However, there are norequirements on how a transport chooses to schedule based on this informationbecause the decision depends on several factors and trade-offs. It couldprioritize new data for a higher-urgency stream over retransmission data for alower-priority stream, or it could prioritize retransmission data over new datairrespective of urgencies.¶

Section 6.2.4 of [QUIC-RECOVERY] also highlights considerations regardingapplication priorities when sending probe packets after Probe Timeout timerexpiration. A QUIC implementation supporting application-indicated prioritiesmight use the relative priority of streams when choosing probe data.¶

13.Fairness

Typically, HTTP implementations depend on the underlying transport to maintainfairness between connections competing for bandwidth. When an intermediary receives HTTP requests on client connections, it forwards them to backend connections. Depending on how the intermediary coalesces or splits requests across different backend connections, different clients might experience dissimilar performance. This dissimilarity might expand if the intermediary also uses priority signals whenforwarding requests. Sections 13.1 and13.2 discussmitigations of this expansion of unfairness.¶

Conversely,Section 13.3 discusses how servers might intentionallyallocate unequal bandwidth to some connections, depending on the prioritysignals.¶

14.Why Use an End-to-End Header Field?

In contrast to the prioritization scheme of HTTP/2, which uses a hop-by-hop frame,the Priority header field is defined as "end-to-end".¶

The way that a client processes a response is a property associated with theclient generating that request, not that of an intermediary. Therefore, it isan end-to-end property. How these end-to-end properties carried by the Priorityheader field affect the prioritization between the responses that share aconnection is a hop-by-hop issue.¶

Having the Priority header field defined as end-to-end is important for cachingintermediaries. Such intermediaries can cache the value of the Priority headerfield along with the response and utilize the value of the cached header fieldwhen serving the cached response, only because the header field is defined asend-to-end rather than hop-by-hop.¶

15.Security Considerations

Section 7 describes considerations for server buffering of PRIORITY_UPDATEframes.¶

Section 10 presents examples where servers that prioritize responsesin a certain way might be starved of the ability to transmit responses.¶

The security considerations from[STRUCTURED-FIELDS] apply to the processing ofpriority parameters defined inSection 4.¶

16.IANA Considerations

This specification registers the following entry in the "Hypertext TransferProtocol (HTTP) Field Name Registry" defined in[HTTP/2]:¶

Field Name:

Priority¶

Status:

permanent¶

Reference:

This document¶

This specification registers the following entry in the "HTTP/2 Settings" registrydefined in[HTTP/2]:¶

Code:

0x9¶

Name:

SETTINGS_NO_RFC7540_PRIORITIES¶

Initial Value:

0¶

Reference:

This document¶

This specification registers the following entry in the "HTTP/2 Frame Type"registry defined in[HTTP/2]:¶

Code:

0x10¶

Frame Type:

PRIORITY_UPDATE¶

Reference:

This document¶

This specification registers the following entry in the "HTTP/3 Frame Types"registry established by[HTTP/3]:¶

Value:

0xF0700-0xF0701¶

Frame Type:

PRIORITY_UPDATE¶

Status:

permanent¶

Reference:

This document¶

Change Controller:

IETF¶

Contact:

ietf-http-wg@w3.org¶

IANA has created the "Hypertext Transfer Protocol (HTTP) Priority" registry at<https://www.iana.org/assignments/http-priority> and has populated it with the entries inTable 1; seeSection 4.3.1 for its associated procedures.¶

Acknowledgements

Roy Fieldingpresented the idea of using a header field for representingpriorities in<https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf>.In<https://github.com/pmeenan/http3-prioritization-proposal>,Patrick Meenanadvocated for representing the priorities using a tuple of urgency andconcurrency. The ability to disable HTTP/2 prioritization is inspired by[PRIORITY-SETTING], authored byBrad Lassey andLucas Pardue, withmodifications based on feedback that was not incorporated into an update to thatdocument.¶

The motivation for defining an alternative to HTTP/2 priorities is drawn fromdiscussion within the broad HTTP community. Special thanks toRoberto Peon,Martin Thomson, and Netflix for text that was incorporated explicitly in thisdocument.¶

In addition to the people above, this document owes a lot to the extensivediscussion in the HTTP priority design team, consisting ofAlan Frindell,Andrew Galloni,Craig Taylor,Ian Swett,Matthew Cox,Mike Bishop,Roberto Peon,Robin Marx,Roy Fielding, and the authors of this document.¶

Yang Chi contributed the section on retransmission scheduling.¶

Authors' Addresses