]> Cloudflare

lucaspardue.24.7@gmail.com

Applications and Real-Time HTTP next generation unicorn sparkling distributed ledger The send-order parameter for the HTTP extensible prioritization scheme allows explicit ordering indication independent of request order. This can be used to as an additional input signal to scheduling decisions, to support alternative sending behaviors. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The extensible prioritization scheme for HTTP provides guidance for servers using priority signals to schedule the sending of stream data; . It recommends that when there are multiple items with the same urgency servers choose how to allocate bandwidth by considering the stream ID and incremental parameter, and possibly other signals. In web use cases, an HTML document can include other resources and user agents tend to issue requests in an ordered sequence that matches the actions of HTML or HTTP receiver processing. Requests are made using ascending stream IDs where lower-numbered streams typically relate to objects that were discovered earlier than higher-numbered streams. Because stream IDs represent an ordering that closely matches the receiver processing needs, the scheduling guidance in can be effectively used to send data that is optimal for this consumption pattern. As a simple example, a client that issues non-incremental requests of the same urgency on streams 0, 4, 8 and 12 would expect a server , that is following , to serve the response in the order 0, 4, 8 and 12. A strictly singular serving order is unlikely to meet the needs of HTTP-based applications. The urgency and incremental parameters augment stream ID, urgency allows more important resources (from a processing perspective) to be sent ahead of less important resources, while incremental streams share bandwidth among resources that can be effectively loaded in parallel. There are other use cases where the user agent may not be able to influence the order of request emission in the most optimal sequence, or may discover an important resource late on and would like the response to "jump the queue" of other streams within a single urgency level. The send-order parameter defined by this document can be used in these situations. While it might be possible to achieve a similar outcome by careful use of the urgency parameter, such as reserving an urgency level, the limited number of levels can make this approach difficult in practice. Alternatively, rebalancing or reprioritization of concurrent stream urgencies might also achieve these goals but encounters issues related to churn and responsiveness due to the latency of reprioritization signals.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terminology from to specify syntax and parsing: Boolean, Dictionary, and Integer. Example HTTP requests and responses use the HTTP/2-style formatting from . This document uses the variable-length integer encoding from .

The send-order parameter The send-order (bikeshed-order-name) parameter value is Integer (see ), between 0 and 2³². The range is ascending, higher values have precedence over lower values. Endpoints use send-order to communicate an ordering precedence that is independent of the request order. There is no default value, omission of the parameter means that there is no additional ordering preference. The send-order parameter satisfies the urgency and incremental parameter compatibility requirements in . The following example shows an HTTP/3 client issuing multiple requests on the same connection, without the send-order parameter, and responses sent by a server following the guidance in . The following example shows an HTTP/3 client issuing multiple requests on the same connection, without the send-order parameter, and responses sent by a server following the guidance in .

Server Scheduling This document updates the scheduling guidance in . Non-incremental responses of the same urgency SHOULD be served by prioritizing bandwidth allocation in ascending order of send-order. If there are no responses with a send-order, allocation SHOULD use ascending order of stream ID. Incremental responses of the same urgency are not affected by send-order.

Security Considerations The considerations in apply. There are not believed to be any additional considerations.

IANA Considerations TODO

Normative References This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Acknowledgments TODO acknowledge.