idnits 2.17.00 (12 Aug 2021) /tmp/idnits41287/draft-ietf-httpbis-priority-05.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 (24 September 2021) is 239 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 1183, but not defined -- Looks like a reference, but probably isn't: '6' on line 1183 -- Looks like a reference, but probably isn't: '0' on line 1183 -- Looks like a reference, but probably isn't: '7' on line 1183 -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-07) exists of draft-ietf-httpbis-http2bis-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 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 March 2022 Cloudflare 6 24 September 2021 8 Extensible Prioritization Scheme for HTTP 9 draft-ietf-httpbis-priority-05 11 Abstract 13 This document describes a scheme for prioritizing HTTP responses. 14 This scheme expresses the priority of each HTTP response using 15 absolute values, rather than as a relative relationship between a 16 group of HTTP responses. 18 This document defines the Priority header field for communicating the 19 initial priority in an HTTP version-independent manner, as well as 20 HTTP/2 and HTTP/3 frames for reprioritizing the responses. These 21 share a common format structure that is designed to provide future 22 extensibility. 24 Note to Readers 26 _RFC EDITOR: please remove this section before publication_ 28 Discussion of this draft takes place on the HTTP working group 29 mailing list (ietf-http-wg@w3.org), which is archived at 30 https://lists.w3.org/Archives/Public/ietf-http-wg/ 31 (https://lists.w3.org/Archives/Public/ietf-http-wg/). 33 Working Group information can be found at https://httpwg.org/ 34 (https://httpwg.org/); source code and issues list for this draft can 35 be found at https://github.com/httpwg/http-extensions/labels/ 36 priorities (https://github.com/httpwg/http-extensions/labels/ 37 priorities). 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 28 March 2022. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 74 2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 4 75 2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6 76 3. Applicability of the Extensible Priority Scheme . . . . . . . 7 77 4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 7 78 4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 9 81 4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 9 82 5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 10 83 6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 11 84 7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 11 85 7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 12 86 7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13 87 8. Merging Client- and Server-Driven Parameters . . . . . . . . 14 88 9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 15 89 10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 15 90 10.1. Intermediaries with Multiple Backend Connections . . . . 17 91 11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 17 92 12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 18 93 13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 18 95 13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 19 96 13.3. Intentional Introduction of Unfairness . . . . . . . . . 19 98 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 20 99 15. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 101 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 17.1. Normative References . . . . . . . . . . . . . . . . . . 22 103 17.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 105 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 106 B.1. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 24 107 B.2. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 25 108 B.3. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 25 109 B.4. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 25 110 B.5. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 25 111 B.6. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 26 112 B.7. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 26 113 B.8. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 26 114 B.9. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 26 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 117 1. Introduction 119 It is common for an HTTP [HTTP] resource representation to have 120 relationships to one or more other resources. Clients will often 121 discover these relationships while processing a retrieved 122 representation, leading to further retrieval requests. Meanwhile, 123 the nature of the relationship determines whether the client is 124 blocked from continuing to process locally available resources. For 125 example, visual rendering of an HTML document could be blocked by the 126 retrieval of a CSS file that the document refers to. In contrast, 127 inline images do not block rendering and get drawn incrementally as 128 the chunks of the images arrive. 130 To provide meaningful presentation of a document at the earliest 131 moment, it is important for an HTTP server to prioritize the HTTP 132 responses, or the chunks of those HTTP responses, that it sends. 134 RFC 7540 [RFC7540] stream priority allowed a client to send a series 135 of priority signals that communicate to the server a "priority tree"; 136 the structure of this tree represents the client's preferred relative 137 ordering and weighted distribution of the bandwidth among HTTP 138 responses. Servers could use these priority signals as input into 139 prioritization decision making. 141 The design and implementation of RFC 7540 stream priority was 142 observed to have shortcomings, explained in Section 2. HTTP/2 143 [HTTP2] has consequently deprecated the use of these stream priority 144 signals. 146 This document describes an extensible scheme for prioritizing HTTP 147 responses that uses absolute values. Section 4 defines priority 148 parameters, which are a standardized and extensible format of 149 priority information. Section 5 defines the Priority HTTP header 150 field that can be used by both client and server to exchange 151 parameters in order to specify the precedence of HTTP responses in a 152 protocol-version-independent and end-to-end manner. Section 7.1 and 153 Section 7.2 define version-specific frames that carry parameters for 154 reprioritization. This prioritization scheme and its signals can act 155 as a substitute for RFC 7540 stream priority. 157 1.1. Notational Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 The terms sf-integer and sf-boolean are imported from 164 [STRUCTURED-FIELDS]. 166 Example HTTP requests and responses use the HTTP/2-style formatting 167 from [HTTP2]. 169 This document uses the variable-length integer encoding from [QUIC]. 171 The term control stream is used to describe the HTTP/2 stream with 172 identifier 0x0, and HTTP/3 control stream; see Section 6.2.1 of 173 [HTTP3]. 175 The term HTTP/2 priority signal is used to describe the priority 176 information sent from clients to servers in HTTP/2 frames; see 177 Section 5.3.2 of [HTTP2]. 179 2. Motivation for Replacing RFC 7540 Priorities 181 An important feature of any implementation of a protocol that 182 provides multiplexing is the ability to prioritize the sending of 183 information. Prioritization is a difficult problem, so it will 184 always be suboptimal, particularly if one endpoint operates in 185 ignorance of the needs of its peer. Priority signalling allows 186 endpoints to communicate their own view of priority needs, which can 187 be combined with other factors that are considered during the peer's 188 prioritization decision making. 190 RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex 191 system where clients signal stream dependencies and weights to 192 describe an unbalanced tree. It suffered from poor deployment and 193 interoperability and was deprecated in a revision of HTTP/2 [HTTP2]. 194 However, in order to maintain wire compatibility, HTTP/2 priority 195 signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]). 197 Clients can build RFC 7540 trees with rich flexibility but experience 198 has shown this is rarely exercised. Instead they tend to choose a 199 single model optimized for a single use case and experiment within 200 the model constraints, or do nothing at all. Furthermore, many 201 clients build their prioritization tree in a unique way, which makes 202 it difficult for servers to understand their intent and act or 203 intervene accordingly. 205 Many RFC 7540 server implementations do not act on HTTP/2 priority 206 signals. Some instead favor custom server-driven schemes based on 207 heuristics or other hints, such as resource content type or request 208 generation order. For example, a server, with knowledge of the 209 document structure, might want to prioritize the delivery of images 210 that are critical to user experience above other images, but below 211 the CSS files. Since client trees vary, it is impossible for the 212 server to determine how such images should be prioritized against 213 other responses. 215 RFC 7540 allows intermediaries to coalesce multiple client trees into 216 a single tree that is used for a single upstream HTTP/2 connection. 217 However, most intermediaries do not support this. Additionally, RFC 218 7540 does not define a method that can be used by a server to express 219 the priority of a response. Without such a method, intermediaries 220 cannot coordinate client-driven and server-driven priorities. 222 RFC 7540 describes denial-of-service considerations for 223 implementations. On 2019-08-13 Netflix issued an advisory notice 224 about the discovery of several resource exhaustion vectors affecting 225 multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka 226 "Resource Loop", is based on using priority signals to manipulate the 227 server's stored prioritization state. 229 HTTP/2 priority signals are required to be delivered and processed in 230 the order they are sent so that the receiver handling is 231 deterministic. Porting HTTP/2 priority signals to protocols that do 232 not provide ordering guarantees presents challenges. For example, 233 HTTP/3 [HTTP3] lacks global ordering across streams that would carry 234 priority signals. Early attempts to port HTTP/2 priority signals to 235 HTTP/3 required adding additional information to the signals, leading 236 to more complicated processing. Problems found with this approach 237 could not be resolved and definition of a HTTP/3 priority signalling 238 feature was removed before publication. 240 Considering the problems with the deployment of RFC 7540 stream 241 priority, and the difficulties in adapting it to HTTP/3, continuing 242 to base prioritization on this mechanism risks increasing the 243 complexity of systems. Multiple experiments from independent 244 research have shown that simpler schemes can reach at least 245 equivalent performance characteristics compared to the more complex 246 RFC 7540 setups seen in practice, at least for the web use case. 248 2.1. Disabling RFC 7540 Priorities 250 The problems and insights set out above provided the motivation for 251 deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]). 253 The SETTINGS_DEPRECATE_RFC7540_PRIORITIES setting is defined by this 254 document in order to allow endpoints to explicitly opt out of using 255 HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints 256 are expected to use an alternative, such as the scheme defined in 257 this specification. 259 The value of SETTINGS_DEPRECATE_RFC7540_PRIORITIES MUST be 0 or 1. 260 Any value other than 0 or 1 MUST be treated as a connection error 261 (see Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. 263 Endpoints MUST send this SETTINGS parameter as part of the first 264 SETTINGS frame. A sender MUST NOT change the 265 SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter value after the first 266 SETTINGS frame. Detection of a change by a receiver MUST be treated 267 as a connection error of type PROTOCOL_ERROR. 269 Until the client receives the SETTINGS frame from the server, the 270 client SHOULD send both the HTTP/2 priority signals and the signals 271 of this prioritization scheme (see Section 5 and Section 7.1). When 272 the client receives the first SETTINGS frame that contains the 273 SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter with value of 1, it 274 SHOULD stop sending the HTTP/2 priority signals. If the value was 0 275 or if the settings parameter was absent, it SHOULD stop sending 276 PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the 277 Priority header field (Section 5), as it is an end-to-end signal that 278 might be useful to nodes behind the server that the client is 279 directly connected to. 281 The SETTINGS frame precedes any HTTP/2 priority signal sent from a 282 client, so a server can determine if it needs to allocate any 283 resource to signal handling before they arrive. A server that 284 receives SETTINGS_DEPRECATE_RFC7540_PRIORITIES with value of 1 MUST 285 ignore HTTP/2 priority signals. 287 Where both endpoints disable RFC 7540 stream priority, the client is 288 expected to send this scheme's priority signal. Handling of omitted 289 signals is described in Section 4. 291 3. Applicability of the Extensible Priority Scheme 293 The priority scheme defined by this document considers only the 294 prioritization of HTTP messages and tunnels, see Section 9, 295 Section 10, and Section 11. 297 Where HTTP extensions change stream behavior or define new data 298 carriage mechanisms, they can also define how this priority scheme 299 can be applied. 301 4. Priority Parameters 303 The priority information is a sequence of key-value pairs, providing 304 room for future extensions. Each key-value pair represents a 305 priority parameter. 307 The Priority HTTP header field (Section 5) is an end-to-end way to 308 transmit this set of parameters when a request or a response is 309 issued. In order to reprioritize a request, HTTP-version-specific 310 frames (Section 7.1 and Section 7.2) are used by clients to transmit 311 the same information on a single hop. If intermediaries want to 312 specify prioritization on a multiplexed HTTP connection, they SHOULD 313 use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header 314 field. 316 In both cases, the set of priority parameters is encoded as a 317 Structured Fields Dictionary (see Section 3.2 of 318 [STRUCTURED-FIELDS]). 320 This document defines the urgency(u) and incremental(i) parameters. 321 When receiving an HTTP request that does not carry these priority 322 parameters, a server SHOULD act as if their default values were 323 specified. Note that handling of omitted parameters is different 324 when processing an HTTP response; see Section 8. 326 Unknown parameters, parameters with out-of-range values or values of 327 unexpected types MUST be ignored. 329 4.1. Urgency 331 The urgency parameter (u) takes an integer between 0 and 7, in 332 descending order of priority. This range provides sufficient 333 granularity for prioritizing responses for ordinary web browsing, at 334 minimal complexity. 336 The value is encoded as an sf-integer. The default value is 3. 338 This parameter indicates the sender's recommendation, based on the 339 expectation that the server would transmit HTTP responses in the 340 order of their urgency values if possible. The smaller the value, 341 the higher the precedence. 343 The following example shows a request for a CSS file with the urgency 344 set to 0: 346 :method = GET 347 :scheme = https 348 :authority = example.net 349 :path = /style.css 350 priority = u=0 352 A client that fetches a document that likely consists of multiple 353 HTTP resources (e.g., HTML) SHOULD assign the default urgency level 354 to the main resource. This convention allows servers to refine the 355 urgency using knowledge specific to the web-site (see Section 8). 357 The lowest urgency level (7) is reserved for background tasks such as 358 delivery of software updates. This urgency level SHOULD NOT be used 359 for fetching responses that have impact on user interaction. 361 4.2. Incremental 363 The incremental parameter (i) takes an sf-boolean as the value that 364 indicates if an HTTP response can be processed incrementally, i.e. 365 provide some meaningful output as chunks of the response arrive. 367 The default value of the incremental parameter is false (0). 369 A server might distribute the bandwidth of a connection between 370 incremental responses that share the same urgency, hoping that 371 providing those responses in parallel would be more helpful to the 372 client than delivering the responses one by one. 374 If a client makes concurrent requests with the incremental parameter 375 set to false, there is no benefit serving responses in parallel 376 because the client is not going to process those responses 377 incrementally. Serving non-incremental responses one by one, in the 378 order in which those requests were generated is considered to be the 379 best strategy. 381 The following example shows a request for a JPEG file with the 382 urgency parameter set to 5 and the incremental parameter set to true. 384 :method = GET 385 :scheme = https 386 :authority = example.net 387 :path = /image.jpg 388 priority = u=5, i 390 4.3. Defining New Parameters 392 When attempting to define new parameters, care must be taken so that 393 they do not adversely interfere with prioritization performed by 394 existing endpoints or intermediaries that do not understand the newly 395 defined parameter. Since unknown parameters are ignored, new 396 parameters should not change the interpretation of or modify the 397 predefined parameters in a way that is not backwards compatible or 398 fallback safe. 400 For example, if there is a need to provide more granularity than 401 eight urgency levels, it would be possible to subdivide the range 402 using an additional parameter. Implementations that do not recognize 403 the parameter can safely continue to use the less granular eight 404 levels. 406 Alternatively, the urgency can be augmented. For example, a 407 graphical user agent could send a visible parameter to indicate if 408 the resource being requested is within the viewport. 410 Generic parameters are preferred over vendor-specific, application- 411 specific or deployment-specific values. If a generic value cannot be 412 agreed upon in the community, the parameter's name should be 413 correspondingly specific (e.g., with a prefix that identifies the 414 vendor, application or deployment). 416 4.3.1. Registration 418 New Priority parameters can be defined by registering them in the 419 HTTP Priority Parameters Registry. 421 Registration requests are reviewed and approved by a Designated 422 Expert, as per Section 4.5 of [RFC8126]. A specification document is 423 appreciated, but not required. 425 The Expert(s) should consider the following factors when evaluating 426 requests: 428 * Community feedback 430 * If the parameters are sufficiently well-defined and adhere to the 431 guidance provided in Section 4.3. 433 Registration requests should use the following template: 435 * Name: [a name for the Priority Parameter that matches key] 437 * Description: [a description of the parameter semantics and value] 439 * Reference: [to a specification defining this parameter] 441 See the registry at https://iana.org/assignments/http-priority 442 (https://iana.org/assignments/http-priority) for details on where to 443 send registration requests. 445 5. The Priority HTTP Header Field 447 The Priority HTTP header field can appear in requests and responses. 448 A client uses it to specify the priority of the response. A server 449 uses it to inform the client that the priority was overwritten. An 450 intermediary can use the Priority information from client requests 451 and server responses to correct or amend the precedence to suit it 452 (see Section 8). 454 The Priority header field is an end-to-end signal of the request 455 priority from the client or the response priority from the server. 457 As is the ordinary case for HTTP caching [CACHING], a response with a 458 Priority header field might be cached and re-used for subsequent 459 requests. When an origin server generates the Priority response 460 header field based on properties of an HTTP request it receives, the 461 server is expected to control the cacheability or the applicability 462 of the cached response, by using header fields that control the 463 caching behavior (e.g., Cache-Control, Vary). 465 An endpoint that fails to parse the Priority header field SHOULD use 466 default parameter values. 468 6. Reprioritization 470 After a client sends a request, it may be beneficial to change the 471 priority of the response. As an example, a web browser might issue a 472 prefetch request for a JavaScript file with the urgency parameter of 473 the Priority request header field set to u=7 (background). Then, 474 when the user navigates to a page which references the new JavaScript 475 file, while the prefetch is in progress, the browser would send a 476 reprioritization signal with the priority field value set to u=0. 477 The PRIORITY_UPDATE frame (Section 7) can be used for such 478 reprioritization. 480 7. The PRIORITY_UPDATE Frame 482 This document specifies a new PRIORITY_UPDATE frame for HTTP/2 483 [HTTP2] and HTTP/3 [HTTP3]. It carries priority parameters and 484 references the target of the prioritization based on a version- 485 specific identifier. In HTTP/2, this identifier is the Stream ID; in 486 HTTP/3, the identifier is either the Stream ID or Push ID. Unlike 487 the Priority header field, the PRIORITY_UPDATE frame is a hop-by-hop 488 signal. 490 PRIORITY_UPDATE frames are sent by clients on the control stream, 491 allowing them to be sent independent from the stream that carries the 492 response. This means they can be used to reprioritize a response or 493 a push stream; or signal the initial priority of a response instead 494 of the Priority header field. 496 A PRIORITY_UPDATE frame communicates a complete set of all parameters 497 in the Priority Field Value field. Omitting a parameter is a signal 498 to use the parameter's default value. Failure to parse the Priority 499 Field Value MUST be treated as a connection error. In HTTP/2 the 500 error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type 501 H3_FRAME_ERROR. 503 A client MAY send a PRIORITY_UPDATE frame before the stream that it 504 references is open (except for HTTP/2 push streams; see Section 7.1). 505 Furthermore, HTTP/3 offers no guaranteed ordering across streams, 506 which could cause the frame to be received earlier than intended. 507 Either case leads to a race condition where a server receives a 508 PRIORITY_UPDATE frame that references a request stream that is yet to 509 be opened. To solve this condition, for the purposes of scheduling, 510 the most recently received PRIORITY_UPDATE frame can be considered as 511 the most up-to-date information that overrides any other signal. 512 Servers SHOULD buffer the most recently received PRIORITY_UPDATE 513 frame and apply it once the referenced stream is opened. Holding 514 PRIORITY_UPDATE frames for each stream requires server resources, 515 which can can be bound by local implementation policy. Although 516 there is no limit to the number of PRIORITY_UPDATES that can be sent, 517 storing only the most recently received frame limits resource 518 commitment. 520 7.1. HTTP/2 PRIORITY_UPDATE Frame 522 The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to 523 signal the initial priority of a response, or to reprioritize a 524 response or push stream. It carries the stream ID of the response 525 and the priority in ASCII text, using the same representation as the 526 Priority header field value. 528 The Stream Identifier field (see Section 5.1.1 of [HTTP2]) in the 529 PRIORITY_UPDATE frame header MUST be zero (0x0). Receiving a 530 PRIORITY_UPDATE frame with a field of any other value MUST be treated 531 as a connection error of type PROTOCOL_ERROR. 533 HTTP/2 PRIORITY_UPDATE Frame { 534 Length (24), 535 Type (i) = 10, 537 Unused Flags (8). 539 Reserved (1), 540 Stream Identifier (31), 542 Reserved (1), 543 Prioritized Stream ID (31), 544 Priority Field Value (..), 545 } 547 Figure 1: HTTP/2 PRIORITY_UPDATE Frame Payload 549 The Length, Type, Unused Flag(s), Reserved, and Stream Identifier 550 fields are described in Section 4 of [HTTP2]. The frame payload of 551 PRIORITY_UPDATE frame payload contains the following additional 552 fields: 554 Reserved: A reserved 1-bit field. The semantics of this bit are 555 undefined, and the bit MUST remain unset (0x0) when sending and 556 MUST be ignored when receiving. 558 Prioritized Stream ID: A 31-bit stream identifier for the stream 559 that is the target of the priority update. 561 Priority Field Value: The priority update value in ASCII text, 562 encoded using Structured Fields. 564 When the PRIORITY_UPDATE frame applies to a request stream, clients 565 SHOULD provide a Prioritized Stream ID that refers to a stream in the 566 "open", "half-closed (local)", or "idle" state. Servers can discard 567 frames where the Prioritized Stream ID refers to a stream in the 568 "half-closed (local)" or "closed" state. The number of streams which 569 have been prioritized but remain in the "idle" state plus the number 570 of active streams (those in the "open" or either "half-closed" state; 571 see Section 5.1.2 of [HTTP2]) MUST NOT exceed the value of the 572 SETTINGS_MAX_CONCURRENT_STREAMS parameter. Servers that receive such 573 a PRIORITY_UPDATE MUST respond with a connection error of type 574 PROTOCOL_ERROR. 576 When the PRIORITY_UPDATE frame applies to a push stream, clients 577 SHOULD provide a Prioritized Stream ID that refers to a stream in the 578 "reserved (remote)" or "half-closed (local)" state. Servers can 579 discard frames where the Prioritized Stream ID refers to a stream in 580 the "closed" state. Clients MUST NOT provide a Prioritized Stream ID 581 that refers to a push stream in the "idle" state. Servers that 582 receive a PRIORITY_UPDATE for a push stream in the "idle" state MUST 583 respond with a connection error of type PROTOCOL_ERROR. 585 If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID 586 of 0x0, the recipient MUST respond with a connection error of type 587 PROTOCOL_ERROR. 589 If a client receives a PRIORITY_UPDATE frame, it MUST respond with a 590 connection error of type PROTOCOL_ERROR. 592 7.2. HTTP/3 PRIORITY_UPDATE Frame 594 The HTTP/3 PRIORITY_UPDATE frame (type=0xF0700 or 0xF0701) is used by 595 clients to signal the initial priority of a response, or to 596 reprioritize a response or push stream. It carries the identifier of 597 the element that is being prioritized, and the updated priority in 598 ASCII text, using the same representation as that of the Priority 599 header field value. PRIORITY_UPDATE with a frame type of 0xF0700 is 600 used for request streams, while PRIORITY_UPDATE with a frame type of 601 0xF0701 is used for push streams. 603 The PRIORITY_UPDATE frame MUST be sent on the client control stream 604 (see Section 6.2.1 of [HTTP3]). Receiving a PRIORITY_UPDATE frame on 605 a stream other than the client control stream MUST be treated as a 606 connection error of type H3_FRAME_UNEXPECTED. 608 HTTP/3 PRIORITY_UPDATE Frame { 609 Type (i) = 0xF0700..0xF0701, 610 Length (i), 611 Prioritized Element ID (i), 612 Priority Field Value (..), 613 } 615 Figure 2: HTTP/3 PRIORITY_UPDATE Frame 617 The PRIORITY_UPDATE frame payload has the following fields: 619 Prioritized Element ID: The stream ID or push ID that is the target 620 of the priority update. 622 Priority Field Value: The priority update value in ASCII text, 623 encoded using Structured Fields. 625 The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST 626 reference a request stream. If a server receives a PRIORITY_UPDATE 627 (type=0xF0700) for a Stream ID that is not a request stream, this 628 MUST be treated as a connection error of type H3_ID_ERROR. The 629 Stream ID MUST be within the client-initiated bidirectional stream 630 limit. If a server receives a PRIORITY_UPDATE (type=0xF0700) with a 631 Stream ID that is beyond the stream limits, this SHOULD be treated as 632 a connection error of type H3_ID_ERROR. 634 The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference 635 a promised push stream. If a server receives a PRIORITY_UPDATE 636 (type=0xF0701) with a Push ID that is greater than the maximum Push 637 ID or which has not yet been promised, this MUST be treated as a 638 connection error of type H3_ID_ERROR. 640 PRIORITY_UPDATE frames of either type are only sent by clients. If a 641 client receives a PRIORITY_UPDATE frame, this MUST be treated as a 642 connection error of type H3_FRAME_UNEXPECTED. 644 8. Merging Client- and Server-Driven Parameters 646 It is not always the case that the client has the best understanding 647 of how the HTTP responses deserve to be prioritized. The server 648 might have additional information that can be combined with the 649 client's indicated priority in order to improve the prioritization of 650 the response. For example, use of an HTML document might depend 651 heavily on one of the inline images; existence of such dependencies 652 is typically best known to the server. Or, a server that receives 653 requests for a font [RFC8081] and images with the same urgency might 654 give higher precedence to the font, so that a visual client can 655 render textual information at an early moment. 657 An origin can use the Priority response header field to indicate its 658 view on how an HTTP response should be prioritized. An intermediary 659 that forwards an HTTP response can use the parameters found in the 660 Priority response header field, in combination with the client 661 Priority request header field, as input to its prioritization 662 process. No guidance is provided for merging priorities, this is 663 left as an implementation decision. 665 Absence of a priority parameter in an HTTP response indicates the 666 server's disinterest in changing the client-provided value. This is 667 different from the logic being defined for the request header field, 668 in which omission of a priority parameter implies the use of their 669 default values (see Section 4). 671 As a non-normative example, when the client sends an HTTP request 672 with the urgency parameter set to 5 and the incremental parameter set 673 to true 675 :method = GET 676 :scheme = https 677 :authority = example.net 678 :path = /menu.png 679 priority = u=5, i 681 and the origin responds with 683 :status = 200 684 content-type = image/png 685 priority = u=1 687 the intermediary might alter its understanding of the urgency from 5 688 to 1, because it prefers the server-provided value over the client's. 689 The incremental value continues to be true, the value specified by 690 the client, as the server did not specify the incremental(i) 691 parameter. 693 9. Client Scheduling 695 A client MAY use priority values to make local processing or 696 scheduling choices about the requests it initiates. 698 10. Server Scheduling 700 Priority signals are input to a prioritization process. They do not 701 guarantee any particular processing or transmission order for one 702 response relative to any other response. An endpoint cannot force a 703 peer to process concurrent request in a particular order using 704 priority. Expressing priority is therefore only a suggestion. 706 A server can use priority signals along with other inputs to make 707 scheduling decisions. No guidance is provided about how this can or 708 should be done. Factors such as implementation choices or deployment 709 environment also play a role. Any given connection is likely to have 710 many dynamic permutations. For these reasons, there is no unilateral 711 perfect scheduler and this document only provides some basic 712 recommendations for implementations. 714 Clients cannot depend on particular treatment based on priority 715 signals. Servers can use other information to prioritize responses. 717 It is RECOMMENDED that, when possible, servers respect the urgency 718 parameter (Section 4.1), sending higher urgency responses before 719 lower urgency responses. 721 It is RECOMMENDED that, when possible, servers respect the 722 incremental parameter (Section 4.2). Non-incremental responses of 723 the same urgency SHOULD be served one-by-one based on the Stream ID, 724 which corresponds to the order in which clients make requests. Doing 725 so ensures that clients can use request ordering to influence 726 response order. Incremental responses of the same urgency SHOULD be 727 served in round-robin manner. 729 The incremental parameter indicates how a client processes response 730 bytes as they arrive. Non-incremental resources are only used when 731 all of the response payload has been received. Incremental resources 732 are used as parts, or chunks, of the response payload are received. 733 Therefore, the timing of response data reception at the client, such 734 as the time to early bytes or the time to receive the entire payload, 735 plays an important role in perceived performance. Timings depend on 736 resource size but this scheme provides no explicit guidance about how 737 a server should use size as an input to prioritization. Instead, the 738 following examples demonstrate how a server that strictly abides the 739 scheduling guidance based on urgency and request generation order 740 could find that early requests prevent serving of later requests. 742 1. At the same urgency level, a non-incremental request for a large 743 resource followed by an incremental request for a small resource. 745 2. At the same urgency level, an incremental request of 746 indeterminate length followed by a non-incremental large 747 resource. 749 It is RECOMMENDED that servers avoid such starvation where possible. 750 The method to do so is an implementation decision. For example, a 751 server might pre-emptively send responses of a particular incremental 752 type based on other information such as content size. 754 Optimal scheduling of server push is difficult, especially when 755 pushed resources contend with active concurrent requests. Servers 756 can consider many factors when scheduling, such as the type or size 757 of resource being pushed, the priority of the request that triggered 758 the push, the count of active concurrent responses, the priority of 759 other active concurrent responses, etc. There is no general guidance 760 on the best way to apply these. A server that is too simple could 761 easily push at too high a priority and block client requests, or push 762 at too low a priority and delay the response, negating intended goals 763 of server push. 765 Priority signals are a factor for server push scheduling. The 766 concept of parameter value defaults applies slightly differently 767 because there is no explicit client-signalled initial priority. A 768 server can apply priority signals provided in an origin response; see 769 the merging guidance given in Section 8. In the absence of origin 770 signals, applying default parameter values could be suboptimal. How 771 ever a server decides to schedule a pushed response, it can signal 772 the intended priority to the client by including the Priority field 773 in a PUSH_PROMISE or HEADERS frame. 775 10.1. Intermediaries with Multiple Backend Connections 777 An intermediary serving an HTTP connection might split requests over 778 multiple backend connections. When it applies prioritization rules 779 strictly, low priority requests cannot make progress while requests 780 with higher priorities are inflight. This blocking can propagate to 781 backend connections, which the peer might interpret as a connection 782 stall. Endpoints often implement protections against stalls, such as 783 abruptly closing connections after a certain time period. To reduce 784 the possibility of this occurring, intermediaries can avoid strictly 785 following prioritization and instead allocate small amounts of 786 bandwidth for all the requests that they are forwarding, so that 787 every request can make some progress over time. 789 Similarly, servers SHOULD allocate some amount of bandwidths to 790 streams acting as tunnels. 792 11. Scheduling and the CONNECT Method 794 When a request stream carries the CONNECT method, the scheduling 795 guidance in this document applies to the frames on the stream. A 796 client that issues multiple CONNECT requests can set the incremental 797 parameter to true, servers that implement the recommendation in 798 Section 10 will schedule these fairly. 800 12. Retransmission Scheduling 802 Transport protocols such as TCP and QUIC provide reliability by 803 detecting packet losses and retransmitting lost information. While 804 this document specifies HTTP-layer prioritization, its effectiveness 805 can be further enhanced if the transport layer factors priority into 806 scheduling both new data and retransmission data. The remainder of 807 this section discusses considerations when using QUIC. 809 Section 13.3 of [QUIC] states "Endpoints SHOULD prioritize 810 retransmission of data over sending new data, unless priorities 811 specified by the application indicate otherwise". When an HTTP/3 812 application uses the priority scheme defined in this document and the 813 QUIC transport implementation supports application indicated stream 814 priority, a transport that considers the relative priority of streams 815 when scheduling both new data and retransmission data might better 816 match the expectations of the application. However, there are no 817 requirements on how a transport chooses to schedule based on this 818 information because the decision depends on several factors and 819 trade-offs. It could prioritize new data for a higher urgency stream 820 over retransmission data for a lower priority stream, or it could 821 prioritize retransmission data over new data irrespective of 822 urgencies. 824 Section 6.2.4 of [QUIC-RECOVERY], also highlights consideration of 825 application priorities when sending probe packets after PTO timer 826 expiration. An QUIC implementation supporting application-indicated 827 priorities might use the relative priority of streams when choosing 828 probe data. 830 13. Fairness 832 As a general guideline, a server SHOULD NOT use priority information 833 for making schedule decisions across multiple connections, unless it 834 knows that those connections originate from the same client. Due to 835 this, priority information conveyed over a non-coalesced HTTP 836 connection (e.g., HTTP/1.1) might go unused. 838 The remainder of this section discusses scenarios where unfairness is 839 problematic and presents possible mitigations, or where unfairness is 840 desirable. 842 13.1. Coalescing Intermediaries 844 When an intermediary coalesces HTTP requests coming from multiple 845 clients into one HTTP/2 or HTTP/3 connection going to the backend 846 server, requests that originate from one client might have higher 847 precedence than those coming from others. 849 It is sometimes beneficial for the server running behind an 850 intermediary to obey to the value of the Priority header field. As 851 an example, a resource-constrained server might defer the 852 transmission of software update files that would have the background 853 urgency being associated. However, in the worst case, the asymmetry 854 between the precedence declared by multiple clients might cause 855 responses going to one user agent to be delayed totally after those 856 going to another. 858 In order to mitigate this fairness problem, a server could use 859 knowledge about the intermediary as another signal in its 860 prioritization decisions. For instance, if a server knows the 861 intermediary is coalescing requests, then it could serve the 862 responses in round-robin manner. This can work if the constrained 863 resource is network capacity between the intermediary and the user 864 agent, as the intermediary buffers responses and forwards the chunks 865 based on the prioritization scheme it implements. 867 A server can determine if a request came from an intermediary through 868 configuration, or by consulting if that request contains one of the 869 following header fields: 871 * Forwarded [FORWARDED], X-Forwarded-For 873 * Via (see Section 7.6.3 of [HTTP]) 875 13.2. HTTP/1.x Back Ends 877 It is common for CDN infrastructure to support different HTTP 878 versions on the front end and back end. For instance, the client- 879 facing edge might support HTTP/2 and HTTP/3 while communication to 880 back end servers is done using HTTP/1.1. Unlike with connection 881 coalescing, the CDN will "de-mux" requests into discrete connections 882 to the back end. As HTTP/1.1 and older do not provide a way to 883 concurrently transmit multiple responses, there is no immediate 884 fairness issue in protocol. However, back end servers MAY still use 885 client headers for request scheduling. Back end servers SHOULD only 886 schedule based on client priority information where that information 887 can be scoped to individual end clients. Authentication and other 888 session information might provide this linkability. 890 13.3. Intentional Introduction of Unfairness 892 It is sometimes beneficial to deprioritize the transmission of one 893 connection over others, knowing that doing so introduces a certain 894 amount of unfairness between the connections and therefore between 895 the requests served on those connections. 897 For example, a server might use a scavenging congestion controller on 898 connections that only convey background priority responses such as 899 software update images. Doing so improves responsiveness of other 900 connections at the cost of delaying the delivery of updates. 902 14. Why use an End-to-End Header Field? 904 Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- 905 hop frame, the Priority header field is defined as end-to-end. 907 The rationale is that the Priority header field transmits how each 908 response affects the client's processing of those responses, rather 909 than how relatively urgent each response is to others. The way a 910 client processes a response is a property associated to that client 911 generating that request. Not that of an intermediary. Therefore, it 912 is an end-to-end property. How these end-to-end properties carried 913 by the Priority header field affect the prioritization between the 914 responses that share a connection is a hop-by-hop issue. 916 Having the Priority header field defined as end-to-end is important 917 for caching intermediaries. Such intermediaries can cache the value 918 of the Priority header field along with the response, and utilize the 919 value of the cached header field when serving the cached response, 920 only because the header field is defined as end-to-end rather than 921 hop-by-hop. 923 It should also be noted that the use of a header field carrying a 924 textual value makes the prioritization scheme extensible; see the 925 discussion below. 927 15. Security Considerations 929 [CVE-2019-9513] aka "Resource Loop", is a DoS attack based on 930 manipulation of the RFC 7540 priority tree. Extensible priorities 931 does not use stream dependencies, which mitigates this vulnerability. 933 Section 5.3.4 of [RFC7540] describes a scenario where closure of 934 streams in the priority tree could cause suboptimal prioritization. 935 To avoid this, [RFC7540] states that "an endpoint SHOULD retain 936 stream prioritization state for a period after streams become 937 closed". Retaining state for streams no longer counted towards 938 stream concurrency consumes server resources. Furthermore, [RFC7540] 939 identifies that reprioritization of a closed stream could affect 940 dependents; it recommends updating the priority tree if sufficient 941 state is stored, which will also consume server resources. To limit 942 this commitment, it is stated that "The amount of prioritization 943 state that is retained MAY be limited" and "If a limit is applied, 944 endpoints SHOULD maintain state for at least as many streams as 945 allowed by their setting for SETTINGS_MAX_CONCURRENT_STREAMS.". 946 Extensible priorities does not use stream dependencies, which 947 minimizes most of the resource concerns related to this scenario. 949 Section 5.3.4 of [RFC7540] also presents considerations about the 950 state required to store priority information about streams in an 951 "idle" state. This state can be limited by adopting the guidance 952 about concurrency limits described above. Extensible priorities is 953 subject to a similar consideration because PRIORITY_UPDATE frames may 954 arrive before the request that they reference. A server is required 955 to store the information in order to apply the most up-to-date signal 956 to the request. However, HTTP/3 implementations might have practical 957 barriers to determining reasonable stream concurrency limits 958 depending on the information that is available to them from the QUIC 959 transport layer. 961 16. IANA Considerations 963 This specification registers the following entry in the Permanent 964 Message Header Field Names registry established by [RFC3864]: 966 Header field name: Priority 968 Applicable protocol: http 970 Status: standard 972 Author/change controller: IETF 974 Specification document(s): This document 976 Related information: n/a 978 This specification registers the following entry in the HTTP/2 979 Settings registry established by [HTTP2]: 981 Name: SETTINGS_DEPRECATE_RFC7540_PRIORITIES 983 Code: 0x9 985 Initial value: 0 987 Specification: This document 989 This specification registers the following entry in the HTTP/2 Frame 990 Type registry established by [HTTP2]: 992 Frame Type: PRIORITY_UPDATE 993 Code: 0x10 995 Specification: This document 997 This specification registers the following entries in the HTTP/3 998 Frame Type registry established by [HTTP3]: 1000 Frame Type: PRIORITY_UPDATE 1002 Code: 0xF0700 and 0xF0701 1004 Specification: This document 1006 Upon publication, please create the HTTP Priority Parameters registry 1007 at https://iana.org/assignments/http-priority 1008 (https://iana.org/assignments/http-priority) and populate it with the 1009 types defined in Section 4; see Section 4.3.1 for its associated 1010 procedures. 1012 17. References 1014 17.1. Normative References 1016 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1017 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1018 httpbis-semantics-19, 12 September 2021, 1019 . 1022 [HTTP2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol 1023 Version 2 (HTTP/2)", Work in Progress, Internet-Draft, 1024 draft-ietf-httpbis-http2bis-04, 23 September 2021, 1025 . 1028 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 1029 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1030 quic-http-34, 2 February 2021, 1031 . 1034 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1035 Multiplexed and Secure Transport", RFC 9000, 1036 DOI 10.17487/RFC9000, May 2021, 1037 . 1039 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1040 Requirement Levels", BCP 14, RFC 2119, 1041 DOI 10.17487/RFC2119, March 1997, 1042 . 1044 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1045 Writing an IANA Considerations Section in RFCs", BCP 26, 1046 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1047 . 1049 [STRUCTURED-FIELDS] 1050 Nottingham, M. and P-H. Kamp, "Structured Field Values for 1051 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 1052 . 1054 17.2. Informative References 1056 [CACHING] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1057 Caching", Work in Progress, Internet-Draft, draft-ietf- 1058 httpbis-cache-19, 12 September 2021, 1059 . 1062 [CVE-2019-9513] 1063 Common Vulnerabilities and Exposures, "CVE-2019-9513", 1 1064 March 2019, . 1067 [FORWARDED] 1068 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1069 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1070 . 1072 [I-D.lassey-priority-setting] 1073 Lassey, B. and L. Pardue, "Declaring Support for HTTP/2 1074 Priorities", Work in Progress, Internet-Draft, draft- 1075 lassey-priority-setting-00, 25 July 2019, 1076 . 1079 [QUIC-RECOVERY] 1080 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1081 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 1082 May 2021, . 1084 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1085 Procedures for Message Header Fields", BCP 90, RFC 3864, 1086 DOI 10.17487/RFC3864, September 2004, 1087 . 1089 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1090 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1091 DOI 10.17487/RFC7540, May 2015, 1092 . 1094 [RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081, 1095 DOI 10.17487/RFC8081, February 2017, 1096 . 1098 Appendix A. Acknowledgements 1100 Roy Fielding presented the idea of using a header field for 1101 representing priorities in http://tools.ietf.org/agenda/83/slides/ 1102 slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/ 1103 slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3- 1104 prioritization-proposal (https://github.com/pmeenan/http3- 1105 prioritization-proposal), Patrick Meenan advocates for representing 1106 the priorities using a tuple of urgency and concurrency. The ability 1107 to deprecate HTTP/2 prioritization is based on 1108 [I-D.lassey-priority-setting], authored by Brad Lassey and Lucas 1109 Pardue, with modifications based on feedback that was not 1110 incorporated into an update to that document. 1112 The motivation for defining an alternative to HTTP/2 priorities is 1113 drawn from discussion within the broad HTTP community. Special 1114 thanks to Roberto Peon, Martin Thomson and Netflix for text that was 1115 incorporated explicitly in this document. 1117 In addition to the people above, this document owes a lot to the 1118 extensive discussion in the HTTP priority design team, consisting of 1119 Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, 1120 Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy 1121 Fielding. 1123 Appendix B. Change Log 1125 B.1. Since draft-ietf-httpbis-priority-03 1127 * Add statement about what this scheme applies to. Clarify 1128 extensions can use it but must define how themselves (#1550, 1129 #1559) 1131 * Describe scheduling considerations for the CONNECT method (#1495, 1132 #1544) 1134 * Describe scheduling considerations for retransmitted data (#1429, 1135 #1504) 1137 * Suggest intermediaries might avoid strict prioritization (#1562) 1139 B.2. Since draft-ietf-httpbis-priority-02 1141 * Describe considerations for server push prioritization (#1056, 1142 #1345) 1144 * Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, 1145 #1344) 1147 * Add a Parameters registry (#1371) 1149 B.3. Since draft-ietf-httpbis-priority-01 1151 * PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, 1152 #1271) 1154 * Add section to describe server scheduling considerations (#1215, 1155 #1232, #1266) 1157 * Remove specific instructions related to intermediary fairness 1158 (#1022, #1264) 1160 B.4. Since draft-ietf-httpbis-priority-00 1162 * Move text around (#1217, #1218) 1164 * Editorial change to the default urgency. The value is 3, which 1165 was always the intent of previous changes. 1167 B.5. Since draft-kazuho-httpbis-priority-04 1169 * Minimize semantics of Urgency levels (#1023, #1026) 1171 * Reduce guidance about how intermediary implements merging priority 1172 signals (#1026) 1174 * Remove mention of CDN-Loop (#1062) 1176 * Editorial changes 1178 * Make changes due to WG adoption 1179 * Removed outdated Consideration (#118) 1181 B.6. Since draft-kazuho-httpbis-priority-03 1183 * Changed numbering from [-1,6] to [0,7] (#78) 1185 * Replaced priority scheme negotiation with HTTP/2 priority 1186 deprecation (#100) 1188 * Shorten parameter names (#108) 1190 * Expand on considerations (#105, #107, #109, #110, #111, #113) 1192 B.7. Since draft-kazuho-httpbis-priority-02 1194 * Consolidation of the problem statement (#61, #73) 1196 * Define SETTINGS_PRIORITIES for negotiation (#58, #69) 1198 * Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) 1200 * Explain fairness issue and mitigations (#56) 1202 B.8. Since draft-kazuho-httpbis-priority-01 1204 * Explain how reprioritization might be supported. 1206 B.9. Since draft-kazuho-httpbis-priority-00 1208 * Expand urgency levels from 3 to 8. 1210 Authors' Addresses 1212 Kazuho Oku 1213 Fastly 1215 Email: kazuhooku@gmail.com 1217 Lucas Pardue 1218 Cloudflare 1220 Email: lucaspardue.24.7@gmail.com