idnits 2.17.1 draft-ietf-httpbis-priority-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 914 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '-1' is mentioned on line 1241, but not defined -- Looks like a reference, but probably isn't: '6' on line 1241 -- Looks like a reference, but probably isn't: '0' on line 1241 -- Looks like a reference, but probably isn't: '7' on line 1241 -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-07) exists of draft-ietf-httpbis-http2bis-05 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP K. Oku 3 Internet-Draft Fastly 4 Intended status: Standards Track L. Pardue 5 Expires: 28 April 2022 Cloudflare 6 25 October 2021 8 Extensible Prioritization Scheme for HTTP 9 draft-ietf-httpbis-priority-07 11 Abstract 13 This document describes a scheme that allows an HTTP client to 14 communicate its preferences for how the upstream server prioritizes 15 responses to its requests, and also allows a server to hint to a 16 downstream intermediary how its responses should be prioritized when 17 they are forwarded. This document defines the Priority header field 18 for communicating the initial priority in an HTTP version-independent 19 manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing 20 responses. These share a common format structure that is designed to 21 provide future extensibility. 23 Note to Readers 25 _RFC EDITOR: please remove this section before publication_ 27 Discussion of this draft takes place on the HTTP working group 28 mailing list (ietf-http-wg@w3.org), which is archived at 29 https://lists.w3.org/Archives/Public/ietf-http-wg/ 30 (https://lists.w3.org/Archives/Public/ietf-http-wg/). 32 Working Group information can be found at https://httpwg.org/ 33 (https://httpwg.org/); source code and issues list for this draft can 34 be found at https://github.com/httpwg/http-extensions/labels/ 35 priorities (https://github.com/httpwg/http-extensions/labels/ 36 priorities). 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 28 April 2022. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 73 2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5 74 2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6 75 2.1.1. Advice when Using Extensible Priorities as the 76 Alternative . . . . . . . . . . . . . . . . . . . . . 7 77 3. Applicability of the Extensible Priority Scheme . . . . . . . 7 78 4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8 79 4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10 82 4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 10 83 5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 11 84 6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12 85 7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12 86 7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13 87 7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 14 88 8. Merging Client- and Server-Driven Parameters . . . . . . . . 15 89 9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 16 90 10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Intermediaries with Multiple Backend Connections . . . . 18 92 11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19 93 12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 19 94 13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20 96 13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21 97 13.3. Intentional Introduction of Unfairness . . . . . . . . . 21 98 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 21 99 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 101 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 17.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 17.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 105 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 106 B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 25 107 B.2. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26 108 B.3. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26 109 B.4. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 26 110 B.5. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 26 111 B.6. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 26 112 B.7. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27 113 B.8. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27 114 B.9. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 27 115 B.10. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 27 116 B.11. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 27 117 B.12. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 120 1. Introduction 122 It is common for representations of an HTTP [HTTP] resource to have 123 relationships to one or more other resources. Clients will often 124 discover these relationships while processing a retrieved 125 representation, which may lead to further retrieval requests. 126 Meanwhile, the nature of the relationship determines whether the 127 client is blocked from continuing to process locally available 128 resources. An example of this is visual rendering of an HTML 129 document, which could be blocked by the retrieval of a CSS file that 130 the document refers to. In contrast, inline images do not block 131 rendering and get drawn incrementally as the chunks of the images 132 arrive. 134 HTTP/2 [HTTP2] and HTTP/3 [HTTP3] support multiplexing of requests 135 and responses in a single connection. An important feature of any 136 implementation of a protocol that provides multiplexing is the 137 ability to prioritize the sending of information. For example, to 138 provide meaningful presentation of an HTML document at the earliest 139 moment, it is important for an HTTP server to prioritize the HTTP 140 responses, or the chunks of those HTTP responses, that it sends to a 141 client. 143 A server that operates in ignorance of how clients issue requests and 144 consume responses can cause suboptimal client application 145 performance. Priority signals allow clients to communicate their 146 view of request priority. Servers have their own needs that are 147 independent from client needs, so they often combine priority signals 148 with other available information in order to inform scheduling of 149 response data. 151 RFC 7540 [RFC7540] stream priority allowed a client to send a series 152 of priority signals that communicate to the server a "priority tree"; 153 the structure of this tree represents the client's preferred relative 154 ordering and weighted distribution of the bandwidth among HTTP 155 responses. Servers could use these priority signals as input into 156 prioritization decision making. 158 The design and implementation of RFC 7540 stream priority was 159 observed to have shortcomings, explained in Section 2. HTTP/2 160 [HTTP2] has consequently deprecated the use of these stream priority 161 signals. 163 This document describes an extensible scheme for prioritizing HTTP 164 responses that uses absolute values. Section 4 defines priority 165 parameters, which are a standardized and extensible format of 166 priority information. Section 5 defines the Priority HTTP header 167 field, a protocol-version-independent and end-to-end priority signal. 168 Clients can use this header to signal priority to servers in order to 169 specify the precedence of HTTP responses. Similarly, servers behind 170 an intermediary can use it to signal priority to the intermediary. 171 Section 7.1 and Section 7.2 define version-specific frames that carry 172 parameters, which clients can use for reprioritization. 174 Header field and frame priority signals are input to a server's 175 response prioritization process. They are only a suggestion and do 176 not guarantee any particular processing or transmission order for one 177 response relative to any other response. Section 10 and Section 12 178 provide consideration and guidance about how servers might act upon 179 signals. 181 The prioritization scheme and priority signals defined herein can act 182 as a substitute for RFC 7540 stream priority. 184 1.1. Notational Conventions 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 The terms Dictionary, sf-boolean, sf-dictionary, and sf-integer are 191 imported from [STRUCTURED-FIELDS]. 193 Example HTTP requests and responses use the HTTP/2-style formatting 194 from [HTTP2]. 196 This document uses the variable-length integer encoding from [QUIC]. 198 The term control stream is used to describe the HTTP/2 stream with 199 identifier 0x0, and HTTP/3 control stream; see Section 6.2.1 of 200 [HTTP3]. 202 The term HTTP/2 priority signal is used to describe the priority 203 information sent from clients to servers in HTTP/2 frames; see 204 Section 5.3.2 of [HTTP2]. 206 2. Motivation for Replacing RFC 7540 Priorities 208 RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex 209 system where clients signal stream dependencies and weights to 210 describe an unbalanced tree. It suffered from limited deployment and 211 interoperability and was deprecated in a revision of HTTP/2 [HTTP2]. 212 However, in order to maintain wire compatibility, HTTP/2 priority 213 signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]). 215 Clients can build RFC 7540 trees with rich flexibility but experience 216 has shown this is rarely exercised. Instead they tend to choose a 217 single model optimized for a single use case and experiment within 218 the model constraints, or do nothing at all. Furthermore, many 219 clients build their prioritization tree in a unique way, which makes 220 it difficult for servers to understand their intent and act or 221 intervene accordingly. 223 Many RFC 7540 server implementations do not act on HTTP/2 priority 224 signals. Some instead favor custom server-driven schemes based on 225 heuristics or other hints, such as resource content type or request 226 generation order. For example, a server, with knowledge of an HTML 227 document structure, might want to prioritize the delivery of images 228 that are critical to user experience above other images, but below 229 the CSS files. Since client trees vary, it is impossible for the 230 server to determine how such images should be prioritized against 231 other responses. 233 RFC 7540 allows intermediaries to coalesce multiple client trees into 234 a single tree that is used for a single upstream HTTP/2 connection. 235 However, most intermediaries do not support this. Additionally, RFC 236 7540 does not define a method that can be used by a server to express 237 the priority of a response. Without such a method, intermediaries 238 cannot coordinate client-driven and server-driven priorities. 240 RFC 7540 describes denial-of-service considerations for 241 implementations. On 2019-08-13 Netflix issued an advisory notice 242 about the discovery of several resource exhaustion vectors affecting 243 multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka 244 "Resource Loop", is based on using priority signals to manipulate the 245 server's stored prioritization state. 247 HTTP/2 priority associated with an HTTP request is signalled as a 248 value relative to those of other requests sharing the same HTTP/2 249 connection. Therefore, in order to prioritize requests, endpoints 250 are compelled to have the knowledge of the underlying HTTP version 251 and how the requests are coalesced. This has been a burden to HTTP 252 endpoints that generate or forward requests in a version-agnostic 253 manner. 255 HTTP/2 priority signals are required to be delivered and processed in 256 the order they are sent so that the receiver handling is 257 deterministic. Porting HTTP/2 priority signals to protocols that do 258 not provide ordering guarantees presents challenges. For example, 259 HTTP/3 [HTTP3] lacks global ordering across streams that would carry 260 priority signals. Early attempts to port HTTP/2 priority signals to 261 HTTP/3 required adding additional information to the signals, leading 262 to more complicated processing. Problems found with this approach 263 could not be resolved and definition of a HTTP/3 priority signalling 264 feature was removed before publication. 266 Considering the deployment problems and the design restrictions of 267 RFC 7540 stream priority, as well as the difficulties in adapting it 268 to HTTP/3, continuing to base prioritization on this mechanism risks 269 increasing the complexity of systems. Multiple experiments from 270 independent research have shown that simpler schemes can reach at 271 least equivalent performance characteristics compared to the more 272 complex RFC 7540 setups seen in practice, at least for the web use 273 case. 275 2.1. Disabling RFC 7540 Priorities 277 The problems and insights set out above provided the motivation for 278 deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]). 280 The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this 281 document in order to allow endpoints to explicitly opt out of using 282 HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints 283 are encouraged to use alternative priority signals (for example, 284 Section 5 or Section 7.1) but there is no requirement to use a 285 specific signal type. 287 The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any 288 value other than 0 or 1 MUST be treated as a connection error (see 289 Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. The initial value 290 is 0. 292 Endpoints MUST send this SETTINGS parameter as part of the first 293 SETTINGS frame. A sender MUST NOT change the 294 SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first 295 SETTINGS frame. Detection of a change by a receiver MUST be treated 296 as a connection error of type PROTOCOL_ERROR. 298 The SETTINGS frame precedes any HTTP/2 priority signal sent from a 299 client, so a server can determine if it needs to allocate any 300 resource to signal handling before they arrive. A server that 301 receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore 302 HTTP/2 priority signals. 304 2.1.1. Advice when Using Extensible Priorities as the Alternative 306 Until the client receives the SETTINGS frame from the server, the 307 client SHOULD send both the HTTP/2 priority signals and the signals 308 of this prioritization scheme (see Section 5 and Section 7.1). When 309 the client receives the first SETTINGS frame that contains the 310 SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD 311 stop sending the HTTP/2 priority signals. If the value was 0 or if 312 the settings parameter was absent, it SHOULD stop sending 313 PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the 314 Priority header field (Section 5), as it is an end-to-end signal that 315 might be useful to nodes behind the server that the client is 316 directly connected to. 318 3. Applicability of the Extensible Priority Scheme 320 The priority scheme defined by this document considers only the 321 prioritization of HTTP messages and tunnels, see Section 9, 322 Section 10, and Section 11. 324 Where HTTP extensions change stream behavior or define new data 325 carriage mechanisms, they can also define how this priority scheme 326 can be applied. 328 4. Priority Parameters 330 The priority information is a sequence of key-value pairs, providing 331 room for future extensions. Each key-value pair represents a 332 priority parameter. 334 The Priority HTTP header field (Section 5) is an end-to-end way to 335 transmit this set of parameters when a request or a response is 336 issued. In order to reprioritize a request, HTTP-version-specific 337 PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by 338 clients to transmit the same information on a single hop. If 339 intermediaries want to specify prioritization on a multiplexed HTTP 340 connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT 341 change the Priority header field. 343 In both cases, the set of priority parameters is encoded as a 344 Structured Fields Dictionary (see Section 3.2 of 345 [STRUCTURED-FIELDS]). 347 This document defines the urgency(u) and incremental(i) parameters. 348 When receiving an HTTP request that does not carry these priority 349 parameters, a server SHOULD act as if their default values were 350 specified. Note that handling of omitted parameters is different 351 when processing an HTTP response; see Section 8. 353 Receivers parse the Dictionary as defined in Section 4.2 of 354 [STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed, 355 this document places the additional requirement that unknown priority 356 parameters, parameters with out-of-range values, or values of 357 unexpected types MUST be ignored. 359 4.1. Urgency 361 The urgency parameter (u) takes an integer between 0 and 7, in 362 descending order of priority. 364 The value is encoded as an sf-integer. The default value is 3. 366 Endpoints use this parameter to communicate their view of the 367 precedence of HTTP responses. The chosen value of urgency can be 368 based on the expectation that servers might use this information to 369 transmit HTTP responses in the order of their urgency. The smaller 370 the value, the higher the precedence. 372 The following example shows a request for a CSS file with the urgency 373 set to 0: 375 :method = GET 376 :scheme = https 377 :authority = example.net 378 :path = /style.css 379 priority = u=0 381 A client that fetches a document that likely consists of multiple 382 HTTP resources (e.g., HTML) SHOULD assign the default urgency level 383 to the main resource. This convention allows servers to refine the 384 urgency using knowledge specific to the web-site (see Section 8). 386 The lowest urgency level (7) is reserved for background tasks such as 387 delivery of software updates. This urgency level SHOULD NOT be used 388 for fetching responses that have impact on user interaction. 390 4.2. Incremental 392 The incremental parameter (i) takes an sf-boolean as the value that 393 indicates if an HTTP response can be processed incrementally, i.e., 394 provide some meaningful output as chunks of the response arrive. 396 The default value of the incremental parameter is false (0). 398 If a client makes concurrent requests with the incremental parameter 399 set to false, there is no benefit serving responses with the same 400 urgency concurrently because the client is not going to process those 401 responses incrementally. Serving non-incremental responses with the 402 same urgency one by one, in the order in which those requests were 403 generated is considered to be the best strategy. 405 If a client makes concurrent requests with the incremental parameter 406 set to true, serving requests with the same urgency concurrently 407 might be beneficial. Doing this distributes the connection 408 bandwidth, meaning that responses take longer to complete. 409 Incremental delivery is most useful where multiple partial responses 410 might provide some value to clients ahead of a complete response 411 being available. 413 The following example shows a request for a JPEG file with the 414 urgency parameter set to 5 and the incremental parameter set to true. 416 :method = GET 417 :scheme = https 418 :authority = example.net 419 :path = /image.jpg 420 priority = u=5, i 422 4.3. Defining New Parameters 424 When attempting to define new parameters, care must be taken so that 425 they do not adversely interfere with prioritization performed by 426 existing endpoints or intermediaries that do not understand the newly 427 defined parameter. Since unknown parameters are ignored, new 428 parameters should not change the interpretation of, or modify, the 429 urgency (see Section 4.1) or incremental (see Section 4.2) parameters 430 in a way that is not backwards compatible or fallback safe. 432 For example, if there is a need to provide more granularity than 433 eight urgency levels, it would be possible to subdivide the range 434 using an additional parameter. Implementations that do not recognize 435 the parameter can safely continue to use the less granular eight 436 levels. 438 Alternatively, the urgency can be augmented. For example, a 439 graphical user agent could send a visible parameter to indicate if 440 the resource being requested is within the viewport. 442 Generic parameters are preferred over vendor-specific, application- 443 specific or deployment-specific values. If a generic value cannot be 444 agreed upon in the community, the parameter's name should be 445 correspondingly specific (e.g., with a prefix that identifies the 446 vendor, application or deployment). 448 4.3.1. Registration 450 New Priority parameters can be defined by registering them in the 451 HTTP Priority Parameters Registry. The registry governs the keys 452 (short textual strings) used in Structured Fields Dictionary (see 453 Section 3.2 of [STRUCTURED-FIELDS]). Since each HTTP request can 454 have associated priority signals, there is value in having short key 455 lengths, especially single-character strings. In order to encourage 456 extension while avoiding unintended conflict among attractive key 457 values, the HTTP Priority Parameters Registry operates two 458 registration policies depending on key length. 460 * Registration requests for parameters with a key length of one use 461 the Specification Required policy, as per Section 4.6 of 462 [RFC8126]. 464 * Registration requests for parameters with a key length greater 465 than one use the Expert Review policy, as per Section 4.5 of 466 [RFC8126]. A specification document is appreciated, but not 467 required. 469 When reviewing registration requests, the designated expert(s) can 470 consider the additional guidance provided in Section 4.3 but cannot 471 use it as a basis for rejection. 473 Registration requests should use the following template: 475 Name: [a name for the Priority Parameter that matches key] 477 Description: [a description of the parameter semantics and value] 479 Reference: [to a specification defining this parameter] 481 See the registry at https://iana.org/assignments/http-priority 482 (https://iana.org/assignments/http-priority) for details on where to 483 send registration requests. 485 5. The Priority HTTP Header Field 487 The Priority HTTP header field carries priority parameters Section 4. 488 It can appear in requests and responses. It is an end-to-end signal 489 of the request priority from the client or the response priority from 490 the server. Section 8 describes how intermediaries can combine the 491 priority information from client requests and server responses to 492 correct or amend the precedence. Clients cannot interpret the 493 appearance or omission of a Priority response header as 494 acknowledgement that any prioritization has occurred. Guidance for 495 how endpoints can act on Priority header values is given in 496 Section 10 and Section 9. 498 Priority is a Dictionary (Section 3.2 of [STRUCTURED-FIELDS]): 500 Priority = sf-dictionary 502 As is the ordinary case for HTTP caching [CACHING], a response with a 503 Priority header field might be cached and re-used for subsequent 504 requests. When an origin server generates the Priority response 505 header field based on properties of an HTTP request it receives, the 506 server is expected to control the cacheability or the applicability 507 of the cached response, by using header fields that control the 508 caching behavior (e.g., Cache-Control, Vary). 510 6. Reprioritization 512 After a client sends a request, it may be beneficial to change the 513 priority of the response. As an example, a web browser might issue a 514 prefetch request for a JavaScript file with the urgency parameter of 515 the Priority request header field set to u=7 (background). Then, 516 when the user navigates to a page which references the new JavaScript 517 file, while the prefetch is in progress, the browser would send a 518 reprioritization signal with the priority field value set to u=0. 519 The PRIORITY_UPDATE frame (Section 7) can be used for such 520 reprioritization. 522 7. The PRIORITY_UPDATE Frame 524 This document specifies a new PRIORITY_UPDATE frame for HTTP/2 525 [HTTP2] and HTTP/3 [HTTP3]. It carries priority parameters and 526 references the target of the prioritization based on a version- 527 specific identifier. In HTTP/2, this identifier is the Stream ID; in 528 HTTP/3, the identifier is either the Stream ID or Push ID. Unlike 529 the Priority header field, the PRIORITY_UPDATE frame is a hop-by-hop 530 signal. 532 PRIORITY_UPDATE frames are sent by clients on the control stream, 533 allowing them to be sent independent from the stream that carries the 534 response. This means they can be used to reprioritize a response or 535 a push stream; or signal the initial priority of a response instead 536 of the Priority header field. 538 A PRIORITY_UPDATE frame communicates a complete set of all parameters 539 in the Priority Field Value field. Omitting a parameter is a signal 540 to use the parameter's default value. Failure to parse the Priority 541 Field Value MUST be treated as a connection error. In HTTP/2 the 542 error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type 543 H3_FRAME_ERROR. 545 A client MAY send a PRIORITY_UPDATE frame before the stream that it 546 references is open (except for HTTP/2 push streams; see Section 7.1). 547 Furthermore, HTTP/3 offers no guaranteed ordering across streams, 548 which could cause the frame to be received earlier than intended. 549 Either case leads to a race condition where a server receives a 550 PRIORITY_UPDATE frame that references a request stream that is yet to 551 be opened. To solve this condition, for the purposes of scheduling, 552 the most recently received PRIORITY_UPDATE frame can be considered as 553 the most up-to-date information that overrides any other signal. 554 Servers SHOULD buffer the most recently received PRIORITY_UPDATE 555 frame and apply it once the referenced stream is opened. Holding 556 PRIORITY_UPDATE frames for each stream requires server resources, 557 which can can be bound by local implementation policy. Although 558 there is no limit to the number of PRIORITY_UPDATES that can be sent, 559 storing only the most recently received frame limits resource 560 commitment. 562 7.1. HTTP/2 PRIORITY_UPDATE Frame 564 The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to 565 signal the initial priority of a response, or to reprioritize a 566 response or push stream. It carries the stream ID of the response 567 and the priority in ASCII text, using the same representation as the 568 Priority header field value. 570 The Stream Identifier field (see Section 5.1.1 of [HTTP2]) in the 571 PRIORITY_UPDATE frame header MUST be zero (0x0). Receiving a 572 PRIORITY_UPDATE frame with a field of any other value MUST be treated 573 as a connection error of type PROTOCOL_ERROR. 575 HTTP/2 PRIORITY_UPDATE Frame { 576 Length (24), 577 Type (i) = 10, 579 Unused Flags (8). 581 Reserved (1), 582 Stream Identifier (31), 584 Reserved (1), 585 Prioritized Stream ID (31), 586 Priority Field Value (..), 587 } 589 Figure 1: HTTP/2 PRIORITY_UPDATE Frame Payload 591 The Length, Type, Unused Flag(s), Reserved, and Stream Identifier 592 fields are described in Section 4 of [HTTP2]. The frame payload of 593 PRIORITY_UPDATE frame payload contains the following additional 594 fields: 596 Reserved: A reserved 1-bit field. The semantics of this bit are 597 undefined, and the bit MUST remain unset (0x0) when sending and 598 MUST be ignored when receiving. 600 Prioritized Stream ID: A 31-bit stream identifier for the stream 601 that is the target of the priority update. 603 Priority Field Value: The priority update value in ASCII text, 604 encoded using Structured Fields. This is the same representation 605 as the Priority header field value. 607 When the PRIORITY_UPDATE frame applies to a request stream, clients 608 SHOULD provide a Prioritized Stream ID that refers to a stream in the 609 "open", "half-closed (local)", or "idle" state. Servers can discard 610 frames where the Prioritized Stream ID refers to a stream in the 611 "half-closed (local)" or "closed" state. The number of streams which 612 have been prioritized but remain in the "idle" state plus the number 613 of active streams (those in the "open" or either "half-closed" state; 614 see Section 5.1.2 of [HTTP2]) MUST NOT exceed the value of the 615 SETTINGS_MAX_CONCURRENT_STREAMS parameter. Servers that receive such 616 a PRIORITY_UPDATE MUST respond with a connection error of type 617 PROTOCOL_ERROR. 619 When the PRIORITY_UPDATE frame applies to a push stream, clients 620 SHOULD provide a Prioritized Stream ID that refers to a stream in the 621 "reserved (remote)" or "half-closed (local)" state. Servers can 622 discard frames where the Prioritized Stream ID refers to a stream in 623 the "closed" state. Clients MUST NOT provide a Prioritized Stream ID 624 that refers to a push stream in the "idle" state. Servers that 625 receive a PRIORITY_UPDATE for a push stream in the "idle" state MUST 626 respond with a connection error of type PROTOCOL_ERROR. 628 If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID 629 of 0x0, the recipient MUST respond with a connection error of type 630 PROTOCOL_ERROR. 632 If a client receives a PRIORITY_UPDATE frame, it MUST respond with a 633 connection error of type PROTOCOL_ERROR. 635 7.2. HTTP/3 PRIORITY_UPDATE Frame 637 The HTTP/3 PRIORITY_UPDATE frame (type=0xF0700 or 0xF0701) is used by 638 clients to signal the initial priority of a response, or to 639 reprioritize a response or push stream. It carries the identifier of 640 the element that is being prioritized, and the updated priority in 641 ASCII text, using the same representation as that of the Priority 642 header field value. PRIORITY_UPDATE with a frame type of 0xF0700 is 643 used for request streams, while PRIORITY_UPDATE with a frame type of 644 0xF0701 is used for push streams. 646 The PRIORITY_UPDATE frame MUST be sent on the client control stream 647 (see Section 6.2.1 of [HTTP3]). Receiving a PRIORITY_UPDATE frame on 648 a stream other than the client control stream MUST be treated as a 649 connection error of type H3_FRAME_UNEXPECTED. 651 HTTP/3 PRIORITY_UPDATE Frame { 652 Type (i) = 0xF0700..0xF0701, 653 Length (i), 654 Prioritized Element ID (i), 655 Priority Field Value (..), 656 } 658 Figure 2: HTTP/3 PRIORITY_UPDATE Frame 660 The PRIORITY_UPDATE frame payload has the following fields: 662 Prioritized Element ID: The stream ID or push ID that is the target 663 of the priority update. 665 Priority Field Value: The priority update value in ASCII text, 666 encoded using Structured Fields. This is the same representation 667 as the Priority header field value. 669 The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST 670 reference a request stream. If a server receives a PRIORITY_UPDATE 671 (type=0xF0700) for a Stream ID that is not a request stream, this 672 MUST be treated as a connection error of type H3_ID_ERROR. The 673 Stream ID MUST be within the client-initiated bidirectional stream 674 limit. If a server receives a PRIORITY_UPDATE (type=0xF0700) with a 675 Stream ID that is beyond the stream limits, this SHOULD be treated as 676 a connection error of type H3_ID_ERROR. Generating an error is not 677 mandatory because HTTP/3 implementations might have practical 678 barriers to determining the active stream concurrency limit that is 679 applied by the QUIC layer. 681 The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference 682 a promised push stream. If a server receives a PRIORITY_UPDATE 683 (type=0xF0701) with a Push ID that is greater than the maximum Push 684 ID or which has not yet been promised, this MUST be treated as a 685 connection error of type H3_ID_ERROR. 687 PRIORITY_UPDATE frames of either type are only sent by clients. If a 688 client receives a PRIORITY_UPDATE frame, this MUST be treated as a 689 connection error of type H3_FRAME_UNEXPECTED. 691 8. Merging Client- and Server-Driven Parameters 693 It is not always the case that the client has the best understanding 694 of how the HTTP responses deserve to be prioritized. The server 695 might have additional information that can be combined with the 696 client's indicated priority in order to improve the prioritization of 697 the response. For example, use of an HTML document might depend 698 heavily on one of the inline images; existence of such dependencies 699 is typically best known to the server. Or, a server that receives 700 requests for a font [RFC8081] and images with the same urgency might 701 give higher precedence to the font, so that a visual client can 702 render textual information at an early moment. 704 An origin can use the Priority response header field to indicate its 705 view on how an HTTP response should be prioritized. An intermediary 706 that forwards an HTTP response can use the parameters found in the 707 Priority response header field, in combination with the client 708 Priority request header field, as input to its prioritization 709 process. No guidance is provided for merging priorities, this is 710 left as an implementation decision. 712 Absence of a priority parameter in an HTTP response indicates the 713 server's disinterest in changing the client-provided value. This is 714 different from the logic being defined for the request header field, 715 in which omission of a priority parameter implies the use of their 716 default values (see Section 4). 718 As a non-normative example, when the client sends an HTTP request 719 with the urgency parameter set to 5 and the incremental parameter set 720 to true 722 :method = GET 723 :scheme = https 724 :authority = example.net 725 :path = /menu.png 726 priority = u=5, i 728 and the origin responds with 730 :status = 200 731 content-type = image/png 732 priority = u=1 734 the intermediary might alter its understanding of the urgency from 5 735 to 1, because it prefers the server-provided value over the client's. 736 The incremental value continues to be true, the value specified by 737 the client, as the server did not specify the incremental(i) 738 parameter. 740 9. Client Scheduling 742 A client MAY use priority values to make local processing or 743 scheduling choices about the requests it initiates. 745 10. Server Scheduling 747 Priority signals are input to a prioritization process. They do not 748 guarantee any particular processing or transmission order for one 749 response relative to any other response. An endpoint cannot force a 750 peer to process concurrent request in a particular order using 751 priority. Expressing priority is therefore only a suggestion. 753 A server can use priority signals along with other inputs to make 754 scheduling decisions. No guidance is provided about how this can or 755 should be done. Factors such as implementation choices or deployment 756 environment also play a role. Any given connection is likely to have 757 many dynamic permutations. For these reasons, there is no unilateral 758 perfect scheduler and this document only provides some basic 759 recommendations for implementations. 761 Clients cannot depend on particular treatment based on priority 762 signals. Servers can use other information to prioritize responses. 764 It is RECOMMENDED that, when possible, servers respect the urgency 765 parameter (Section 4.1), sending higher urgency responses before 766 lower urgency responses. 768 The incremental parameter indicates how a client processes response 769 bytes as they arrive. It is RECOMMENDED that, when possible, servers 770 respect the incremental parameter (Section 4.2). Non-incremental 771 resources can only be used when all of the response payload has been 772 received. Therefore, non-incremental responses of the same urgency 773 SHOULD be served in their entirety, one-by-one, based on the stream 774 ID, which corresponds to the order in which clients make requests. 775 Doing so ensures that clients can use request ordering to influence 776 response order. 778 Incremental responses of the same urgency SHOULD be served by sharing 779 bandwidth amongst them. Incremental resources are used as parts, or 780 chunks, of the response payload are received. A client might benefit 781 more from receiving a portion of all these resources rather than the 782 entirety of a single resource. How large a portion of the resource 783 is needed to be useful in improving performance varies. Some 784 resource types place critical elements early, others can use 785 information progressively. This scheme provides no explicit mandate 786 about how a server should use size, type or any other input to decide 787 how to prioritize. 789 There can be scenarios where a server will need to schedule multiple 790 incremental and non-incremental responses at the same urgency level. 791 Strictly abiding the scheduling guidance based on urgency and request 792 generation order might lead to sub-optimal results at the client, as 793 early non-incremental responses might prevent serving of incremental 794 responses issued later. The following are examples of such 795 challenges. 797 1. At the same urgency level, a non-incremental request for a large 798 resource followed by an incremental request for a small resource. 800 2. At the same urgency level, an incremental request of 801 indeterminate length followed by a non-incremental large 802 resource. 804 It is RECOMMENDED that servers avoid such starvation where possible. 805 The method to do so is an implementation decision. For example, a 806 server might pre-emptively send responses of a particular incremental 807 type based on other information such as content size. 809 Optimal scheduling of server push is difficult, especially when 810 pushed resources contend with active concurrent requests. Servers 811 can consider many factors when scheduling, such as the type or size 812 of resource being pushed, the priority of the request that triggered 813 the push, the count of active concurrent responses, the priority of 814 other active concurrent responses, etc. There is no general guidance 815 on the best way to apply these. A server that is too simple could 816 easily push at too high a priority and block client requests, or push 817 at too low a priority and delay the response, negating intended goals 818 of server push. 820 Priority signals are a factor for server push scheduling. The 821 concept of parameter value defaults applies slightly differently 822 because there is no explicit client-signalled initial priority. A 823 server can apply priority signals provided in an origin response; see 824 the merging guidance given in Section 8. In the absence of origin 825 signals, applying default parameter values could be suboptimal. By 826 whatever means a server decides to schedule a pushed response, it can 827 signal the intended priority to the client by including the Priority 828 field in a PUSH_PROMISE or HEADERS frame. 830 10.1. Intermediaries with Multiple Backend Connections 832 An intermediary serving an HTTP connection might split requests over 833 multiple backend connections. When it applies prioritization rules 834 strictly, low priority requests cannot make progress while requests 835 with higher priorities are inflight. This blocking can propagate to 836 backend connections, which the peer might interpret as a connection 837 stall. Endpoints often implement protections against stalls, such as 838 abruptly closing connections after a certain time period. To reduce 839 the possibility of this occurring, intermediaries can avoid strictly 840 following prioritization and instead allocate small amounts of 841 bandwidth for all the requests that they are forwarding, so that 842 every request can make some progress over time. 844 Similarly, servers SHOULD allocate some amount of bandwidths to 845 streams acting as tunnels. 847 11. Scheduling and the CONNECT Method 849 When a request stream carries the CONNECT method, the scheduling 850 guidance in this document applies to the frames on the stream. A 851 client that issues multiple CONNECT requests can set the incremental 852 parameter to true, servers that implement the recommendation in 853 Section 10 will schedule these fairly. 855 12. Retransmission Scheduling 857 Transport protocols such as TCP and QUIC provide reliability by 858 detecting packet losses and retransmitting lost information. While 859 this document specifies HTTP-layer prioritization, its effectiveness 860 can be further enhanced if the transport layer factors priority into 861 scheduling both new data and retransmission data. The remainder of 862 this section discusses considerations when using QUIC. 864 Section 13.3 of [QUIC] states "Endpoints SHOULD prioritize 865 retransmission of data over sending new data, unless priorities 866 specified by the application indicate otherwise". When an HTTP/3 867 application uses the priority scheme defined in this document and the 868 QUIC transport implementation supports application indicated stream 869 priority, a transport that considers the relative priority of streams 870 when scheduling both new data and retransmission data might better 871 match the expectations of the application. However, there are no 872 requirements on how a transport chooses to schedule based on this 873 information because the decision depends on several factors and 874 trade-offs. It could prioritize new data for a higher urgency stream 875 over retransmission data for a lower priority stream, or it could 876 prioritize retransmission data over new data irrespective of 877 urgencies. 879 Section 6.2.4 of [QUIC-RECOVERY], also highlights consideration of 880 application priorities when sending probe packets after Probe Timeout 881 timer expiration. A QUIC implementation supporting application- 882 indicated priorities might use the relative priority of streams when 883 choosing probe data. 885 13. Fairness 887 As a general guideline, a server SHOULD NOT use priority information 888 for making scheduling decisions across multiple connections, unless 889 it knows that those connections originate from the same client. Due 890 to this, priority information conveyed over a non-coalesced HTTP 891 connection (e.g., HTTP/1.1) might go unused. 893 The remainder of this section discusses scenarios where unfairness is 894 problematic and presents possible mitigations, or where unfairness is 895 desirable. 897 13.1. Coalescing Intermediaries 899 When an intermediary coalesces HTTP requests coming from multiple 900 clients into one HTTP/2 or HTTP/3 connection going to the backend 901 server, requests that originate from one client might have higher 902 precedence than those coming from others. 904 It is sometimes beneficial for the server running behind an 905 intermediary to obey to the value of the Priority header field. As 906 an example, a resource-constrained server might defer the 907 transmission of software update files that would have the background 908 urgency being associated. However, in the worst case, the asymmetry 909 between the precedence declared by multiple clients might cause 910 responses going to one user agent to be delayed totally after those 911 going to another. 913 In order to mitigate this fairness problem, a server could use 914 knowledge about the intermediary as another signal in its 915 prioritization decisions. For instance, if a server knows the 916 intermediary is coalescing requests, then it could avoid serving the 917 responses in their entirety and instead distribute bandwidth (for 918 example, in a round-robin manner). This can work if the constrained 919 resource is network capacity between the intermediary and the user 920 agent, as the intermediary buffers responses and forwards the chunks 921 based on the prioritization scheme it implements. 923 A server can determine if a request came from an intermediary through 924 configuration, or by consulting if that request contains one of the 925 following header fields: 927 * Forwarded [FORWARDED], X-Forwarded-For 929 * Via (see Section 7.6.3 of [HTTP]) 931 13.2. HTTP/1.x Back Ends 933 It is common for CDN infrastructure to support different HTTP 934 versions on the front end and back end. For instance, the client- 935 facing edge might support HTTP/2 and HTTP/3 while communication to 936 back end servers is done using HTTP/1.1. Unlike with connection 937 coalescing, the CDN will "de-mux" requests into discrete connections 938 to the back end. HTTP/1.1 and older do not support response 939 multiplexing in a single connection, so there is not a fairness 940 problem. However, back end servers MAY still use client headers for 941 request scheduling. Back end servers SHOULD only schedule based on 942 client priority information where that information can be scoped to 943 individual end clients. Authentication and other session information 944 might provide this linkability. 946 13.3. Intentional Introduction of Unfairness 948 It is sometimes beneficial to deprioritize the transmission of one 949 connection over others, knowing that doing so introduces a certain 950 amount of unfairness between the connections and therefore between 951 the requests served on those connections. 953 For example, a server might use a scavenging congestion controller on 954 connections that only convey background priority responses such as 955 software update images. Doing so improves responsiveness of other 956 connections at the cost of delaying the delivery of updates. 958 14. Why use an End-to-End Header Field? 960 Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- 961 hop frame, the Priority header field is defined as end-to-end. 963 The rationale is that the Priority header field transmits how each 964 response affects the client's processing of those responses, rather 965 than how relatively urgent each response is to others. The way a 966 client processes a response is a property associated to that client 967 generating that request. Not that of an intermediary. Therefore, it 968 is an end-to-end property. How these end-to-end properties carried 969 by the Priority header field affect the prioritization between the 970 responses that share a connection is a hop-by-hop issue. 972 Having the Priority header field defined as end-to-end is important 973 for caching intermediaries. Such intermediaries can cache the value 974 of the Priority header field along with the response, and utilize the 975 value of the cached header field when serving the cached response, 976 only because the header field is defined as end-to-end rather than 977 hop-by-hop. 979 It should also be noted that the use of a header field carrying a 980 textual value makes the prioritization scheme extensible; see the 981 discussion below. 983 15. Security Considerations 985 [RFC7540] stream prioritization relies on dependencies. 986 Considerations are presented to implementations, describing how 987 limiting state or work commitments can avoid some types of problems. 988 In addition, [CVE-2019-9513] aka "Resource Loop", is an example of a 989 DoS attack that abuses stream dependencies. Extensible priorities 990 does not use dependencies, which avoids these issues. 992 Section 7 describes considerations for server buffering of 993 PRIORITY_UPDATE frames. 995 Section 10 presents examples where servers that prioritize responses 996 in a certain way might be starved of the ability to transmit payload. 998 The security considerations from [STRUCTURED-FIELDS] apply to 999 processing of priority parameters defined in Section 4. 1001 16. IANA Considerations 1003 This specification registers the following entry in the the Hypertext 1004 Transfer Protocol (HTTP) Field Name Registry established by [HTTP]: 1006 Field name: Priority 1008 Status: permanent 1010 Specification document(s): This document 1012 This specification registers the following entry in the HTTP/2 1013 Settings registry established by [RFC7540]: 1015 Name: SETTINGS_NO_RFC7540_PRIORITIES 1017 Code: 0x9 1019 Initial value: 0 1021 Specification: This document 1023 This specification registers the following entry in the HTTP/2 Frame 1024 Type registry established by [RFC7540]: 1026 Frame Type: PRIORITY_UPDATE 1027 Code: 0x10 1029 Specification: This document 1031 This specification registers the following entries in the HTTP/3 1032 Frame Type registry established by [HTTP3]: 1034 Frame Type: PRIORITY_UPDATE 1036 Code: 0xF0700 and 0xF0701 1038 Specification: This document 1040 Upon publication, please create the HTTP Priority Parameters registry 1041 at https://iana.org/assignments/http-priority 1042 (https://iana.org/assignments/http-priority) and populate it with the 1043 types defined in Section 4; see Section 4.3.1 for its associated 1044 procedures. 1046 17. References 1048 17.1. Normative References 1050 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1051 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1052 httpbis-semantics-19, 12 September 2021, 1053 . 1056 [HTTP2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol 1057 Version 2 (HTTP/2)", Work in Progress, Internet-Draft, 1058 draft-ietf-httpbis-http2bis-05, 26 September 2021, 1059 . 1062 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 1063 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1064 quic-http-34, 2 February 2021, 1065 . 1068 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1069 Multiplexed and Secure Transport", RFC 9000, 1070 DOI 10.17487/RFC9000, May 2021, 1071 . 1073 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1074 Requirement Levels", BCP 14, RFC 2119, 1075 DOI 10.17487/RFC2119, March 1997, 1076 . 1078 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1079 Writing an IANA Considerations Section in RFCs", BCP 26, 1080 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1081 . 1083 [STRUCTURED-FIELDS] 1084 Nottingham, M. and P-H. Kamp, "Structured Field Values for 1085 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 1086 . 1088 17.2. Informative References 1090 [CACHING] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1091 Caching", Work in Progress, Internet-Draft, draft-ietf- 1092 httpbis-cache-19, 12 September 2021, 1093 . 1096 [CVE-2019-9513] 1097 Common Vulnerabilities and Exposures, "CVE-2019-9513", 1 1098 March 2019, . 1101 [FORWARDED] 1102 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1103 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1104 . 1106 [I-D.lassey-priority-setting] 1107 Lassey, B. and L. Pardue, "Declaring Support for HTTP/2 1108 Priorities", Work in Progress, Internet-Draft, draft- 1109 lassey-priority-setting-00, 25 July 2019, 1110 . 1113 [QUIC-RECOVERY] 1114 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1115 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 1116 May 2021, . 1118 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1119 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1120 DOI 10.17487/RFC7540, May 2015, 1121 . 1123 [RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081, 1124 DOI 10.17487/RFC8081, February 2017, 1125 . 1127 Appendix A. Acknowledgements 1129 Roy Fielding presented the idea of using a header field for 1130 representing priorities in http://tools.ietf.org/agenda/83/slides/ 1131 slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/ 1132 slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3- 1133 prioritization-proposal (https://github.com/pmeenan/http3- 1134 prioritization-proposal), Patrick Meenan advocated for representing 1135 the priorities using a tuple of urgency and concurrency. The ability 1136 to disable HTTP/2 prioritization is inspired by 1137 [I-D.lassey-priority-setting], authored by Brad Lassey and Lucas 1138 Pardue, with modifications based on feedback that was not 1139 incorporated into an update to that document. 1141 The motivation for defining an alternative to HTTP/2 priorities is 1142 drawn from discussion within the broad HTTP community. Special 1143 thanks to Roberto Peon, Martin Thomson and Netflix for text that was 1144 incorporated explicitly in this document. 1146 In addition to the people above, this document owes a lot to the 1147 extensive discussion in the HTTP priority design team, consisting of 1148 Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, 1149 Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy 1150 Fielding. 1152 Yang Chi contributed the section on retransmission scheduling. 1154 Appendix B. Change Log 1156 B.1. Since draft-ietf-httpbis-priority-06 1158 * Focus on editorial changes 1160 * Clarify rules about Sf-Dictionary handling in headers 1162 * Split policy for parameter IANA registry into two sections based 1163 on key length 1165 B.2. Since draft-ietf-httpbis-priority-05 1167 * Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to 1168 SETTINGS_NO_RFC7540_PRIORITIES 1170 * Clarify that senders of the HTTP/2 setting can use any alternative 1171 (#1679, #1705) 1173 B.3. Since draft-ietf-httpbis-priority-04 1175 * Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to 1176 SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601) 1178 * Reoriented text towards RFC7540bis (#1561, #1601) 1180 * Clarify intermediary behavior (#1562) 1182 B.4. Since draft-ietf-httpbis-priority-03 1184 * Add statement about what this scheme applies to. Clarify 1185 extensions can use it but must define how themselves (#1550, 1186 #1559) 1188 * Describe scheduling considerations for the CONNECT method (#1495, 1189 #1544) 1191 * Describe scheduling considerations for retransmitted data (#1429, 1192 #1504) 1194 * Suggest intermediaries might avoid strict prioritization (#1562) 1196 B.5. Since draft-ietf-httpbis-priority-02 1198 * Describe considerations for server push prioritization (#1056, 1199 #1345) 1201 * Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, 1202 #1344) 1204 * Add a Parameters registry (#1371) 1206 B.6. Since draft-ietf-httpbis-priority-01 1208 * PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, 1209 #1271) 1211 * Add section to describe server scheduling considerations (#1215, 1212 #1232, #1266) 1214 * Remove specific instructions related to intermediary fairness 1215 (#1022, #1264) 1217 B.7. Since draft-ietf-httpbis-priority-00 1219 * Move text around (#1217, #1218) 1221 * Editorial change to the default urgency. The value is 3, which 1222 was always the intent of previous changes. 1224 B.8. Since draft-kazuho-httpbis-priority-04 1226 * Minimize semantics of Urgency levels (#1023, #1026) 1228 * Reduce guidance about how intermediary implements merging priority 1229 signals (#1026) 1231 * Remove mention of CDN-Loop (#1062) 1233 * Editorial changes 1235 * Make changes due to WG adoption 1237 * Removed outdated Consideration (#118) 1239 B.9. Since draft-kazuho-httpbis-priority-03 1241 * Changed numbering from [-1,6] to [0,7] (#78) 1243 * Replaced priority scheme negotiation with HTTP/2 priority 1244 deprecation (#100) 1246 * Shorten parameter names (#108) 1248 * Expand on considerations (#105, #107, #109, #110, #111, #113) 1250 B.10. Since draft-kazuho-httpbis-priority-02 1252 * Consolidation of the problem statement (#61, #73) 1254 * Define SETTINGS_PRIORITIES for negotiation (#58, #69) 1256 * Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) 1258 * Explain fairness issue and mitigations (#56) 1260 B.11. Since draft-kazuho-httpbis-priority-01 1261 * Explain how reprioritization might be supported. 1263 B.12. Since draft-kazuho-httpbis-priority-00 1265 * Expand urgency levels from 3 to 8. 1267 Authors' Addresses 1269 Kazuho Oku 1270 Fastly 1272 Email: kazuhooku@gmail.com 1274 Lucas Pardue 1275 Cloudflare 1277 Email: lucaspardue.24.7@gmail.com