idnits 2.17.1 draft-kazuho-httpbis-priority-02.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 (July 23, 2019) is 1731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 536 -- Looks like a reference, but probably isn't: '2' on line 537 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-11 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-22 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: January 24, 2020 Cloudflare 6 July 23, 2019 8 The Priority HTTP Header Field 9 draft-kazuho-httpbis-priority-02 11 Abstract 13 This document describes the Priority HTTP header field. This header 14 field can be used by endpoints to specify the absolute precedence of 15 an HTTP response in an HTTP-version-independent way. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 24, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 53 2. The Priority HTTP Header Field . . . . . . . . . . . . . . . 4 54 2.1. urgency . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1.1. prerequisite . . . . . . . . . . . . . . . . . . . . 5 56 2.1.2. default . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1.3. supplementary . . . . . . . . . . . . . . . . . . . . 5 58 2.1.4. background . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. progressive . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Merging Client- and Server-Driven Parameters . . . . . . . . 7 61 4. Coexistence with HTTP/2 Priorities . . . . . . . . . . . . . 7 62 4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter . . 8 63 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Why use an End-to-End Header Field? . . . . . . . . . . . 8 65 5.2. Why do Urgencies Have Meanings? . . . . . . . . . . . . . 9 66 5.3. Reprioritization . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 73 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12 74 B.1. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 12 75 B.2. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 It is common for an HTTP ([RFC7230]) resource representation to have 81 relationships to one or more other resources. Clients will often 82 discover these relationships while processing a retrieved 83 representation, leading to further retrieval requests. Meanwhile, 84 the nature of the relationship determines whether the client is 85 blocked from continuing to process locally available resources. For 86 example, visual rendering of an HTML document could be blocked by the 87 retrieval of a CSS file that the document refers to. In contrast, 88 inline images do not block rendering and get drawn progressively as 89 the chunks of the images arrive. 91 To provide meaningful representation of a document at the earliest 92 moment, it is important for an HTTP server to prioritize the HTTP 93 responses, or the chunks of those HTTP responses, that it sends. 95 HTTP/2 ([RFC7540]) provides such a prioritization scheme. A client 96 sends a series of PRIORITY frames to communicate to the server a 97 "priority tree"; this represents the client's preferred ordering and 98 weighted distribution of the bandwidth among the HTTP responses. 99 However, the design has shortcomings: 101 o Its complexity has led to varying levels of support by HTTP/2 102 clients and servers. 104 o It is hard to coordinate with server-driven prioritization. For 105 example, a server, with knowledge of the document structure, might 106 want to prioritize the delivery of images that are critical to 107 user experience above other images, but below the CSS files. But 108 with the HTTP/2 prioritization scheme, it is impossible for the 109 server to determine how such images should be prioritized against 110 other responses that use the client-driven prioritization tree, 111 because every client builds the HTTP/2 prioritization tree in a 112 different way. 114 o It does not define a method that can be used by a server to 115 express the priority of a response. Without such a method, 116 intermediaries cannot coordinate client-driven and server-driven 117 priorities. 119 o The design cannot be ported cleanly to HTTP/3 120 ([I-D.ietf-quic-http]). One of the primary goals of HTTP/3 is to 121 minimize head-of-line blocking. Transmitting the evolving 122 representation of a "prioritization tree" from the client to the 123 server requires head-of-line blocking. 125 Based on these observations, this document defines the Priority HTTP 126 header field that can be used by both the client and the server to 127 specify the precedence of HTTP responses in a standardized, 128 extensible, protocol-version- independent, end-to-end format. This 129 header-based prioritization scheme can act as a substitute for the 130 HTTP/2 frame-based prioritization scheme (see Section 4). 132 1.1. Notational Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 The terms sh-token and sh-boolean are imported from 139 [I-D.ietf-httpbis-header-structure]. 141 Example HTTP requests and responses use the HTTP/2-style formatting 142 from [RFC7540]. 144 2. The Priority HTTP Header Field 146 The Priority HTTP header field can appear in requests and responses. 147 A client uses it to specify the priority of the response. A server 148 uses it to inform the client that the priority was overwritten. An 149 intermediary can use the Priority information from client requests 150 and server responses to correct or amend the precedence to suit it 151 (see Section 3). 153 The value of the Priority header field is a Structured Headers 154 [I-D.ietf-httpbis-header-structure] Dictionary. Each dictionary 155 member represents a parameter of the Priority header field. This 156 document defines the "urgency" and "progressive" parameters. Values 157 of these parameters MUST always be present. When any of the defined 158 parameters are omitted, or if the Priority header field is not used, 159 their default values SHOULD be applied. 161 Unknown parameters MUST be ignored. 163 2.1. urgency 165 The "urgency" parameter takes an integer between -1 and 6 as shown 166 below: 168 +-----------------+-------------------------------+ 169 | Urgency | Definition | 170 +-----------------+-------------------------------+ 171 | -1 | prerequisite (Section 2.1.1) | 172 | 0 | default (Section 2.1.2) | 173 | between 1 and 5 | supplementary (Section 2.1.3) | 174 | 6 | background (Section 2.1.4) | 175 +-----------------+-------------------------------+ 177 Table 1: Urgencies 179 The value is encoded as an sh-integer. The default value is zero. 181 A server SHOULD transmit HTTP responses in the order of their urgency 182 values. The lower the value, the higher the precedence. 184 The following example shows a request for a CSS file with the urgency 185 set to "-1": 187 :method = GET 188 :scheme = https 189 :authority = example.net 190 :path = /style.css 191 priority = urgency=-1 192 The definition of the urgencies and their expected use-case are 193 described below. Endpoints SHOULD respect the definition of the 194 values when assigning urgencies. 196 2.1.1. prerequisite 198 The prerequisite urgency (value -1) indicates that the response 199 prevents other responses with an urgency of prerequisite or default 200 from being used. 202 For example, use of an external stylesheet can block a web browser 203 from rendering the HTML. In such case, the stylesheet is given the 204 prerequisite urgency. 206 2.1.2. default 208 The default urgency (value 0) indicates a response that is to be used 209 as it is delivered to the client, but one that does not block other 210 responses from being used. 212 For example, when a user using a web browser navigates to a new HTML 213 document, the request for that HTML is given the default urgency. 214 When that HTML document uses a custom font, the request for that 215 custom font SHOULD also be given the default urgency. This is 216 because the availability of the custom font is likely a precondition 217 for the user to use that portion of the HTML document, which is to be 218 rendered by that font. 220 2.1.3. supplementary 222 The supplementary urgency indicates a response that is helpful to the 223 client using a composition of responses, even though the response 224 itself is not mandatory for using those responses. 226 For example, inline images (i.e., images being fetched and displayed 227 as part of the document) are visually important elements of an HTML 228 document. As such, users will typically not be prevented from using 229 the document, at least to some degree, before any or all of these 230 images are loaded. Display of those images are thus considered to be 231 an improvement for visual clients rather than a prerequisite for all 232 user agents. Therefore, such images will be given the supplementary 233 urgency. 235 Values between 1 and 5 are used to represent this urgency, to provide 236 flexibility to the endpoints for giving some responses more or less 237 precedence than others that belong to the supplementary group. 238 Section 3 explains how these values might be used. 240 Clients SHOULD NOT use values 1 and 5. Servers MAY use these values 241 to prioritize a response above or below other supplementary 242 responses. 244 Clients MAY use values 2 to indicate that a request is given 245 relatively high priority, or 4 to indicate relatively low priority, 246 within the supplementary urgency group. 248 For example, an image certain to be visible at the top of the page, 249 might be assigned a value of 2 instead of 3, as it will have a high 250 visual impact for the user. Conversely, an asynchronously loaded 251 JavaScript file might be assigned an urgency value of 4, as it is 252 less likely to have a visual impact. 254 When none of the considerations above is applicable, the value of 3 255 SHOULD be used. 257 2.1.4. background 259 The background urgency (value 6) is used for responses of which the 260 delivery can be postponed without having an impact on using other 261 responses. 263 As an example, the download of a large file in a web browser would be 264 assigned the background urgency so it would not impact further page 265 loads on the same connection. 267 2.2. progressive 269 The "progressive" parameter takes an sh-boolean as the value that 270 indicates if a response can be processed progressively, i.e. provide 271 some meaningful output as chunks of the response arrive. 273 The default value of the "progressive" parameter is "0". 275 A server SHOULD distribute the bandwidth of a connection between 276 progressive responses that share the same urgency. 278 A server SHOULD transmit non-progressive responses one by one, 279 preferably in the order the requests were generated. Doing so 280 maximizes the chance of the client making progress in using the 281 composition of the HTTP responses at the earliest moment. 283 The following example shows a request for a JPEG file with the 284 urgency parameter set to "3" and the progressive parameter set to 285 "1". 287 :method = GET 288 :scheme = https 289 :authority = example.net 290 :path = /image.jpg 291 priority = urgency=3, progressive=?1 293 3. Merging Client- and Server-Driven Parameters 295 It is not always the case that the client has the best understanding 296 of how the HTTP responses deserve to be prioritized. For example, 297 use of an HTML document might depend heavily on one of the inline 298 images. Existence of such dependencies is typically best known to 299 the server. 301 By using the "Priority" response header, a server can override the 302 prioritization hints provided by the client. When used, the 303 parameters found in the response header field overrides those 304 specified by the client. 306 For example, when the client sends an HTTP request with 308 :method = GET 309 :scheme = https 310 :authority = example.net 311 :path = /menu.png 312 priority = urgency=3, progressive=?1 314 and the origin responds with 316 :status = 200 317 content-type = image/png 318 priority = urgency=1 320 the intermediary's understanding of the urgency is promoted from "3" 321 to "1", because the server-provided value overrides the value 322 provided by the client. The progressiveness continues to be "1", the 323 value specified by the client, as the server did not specify the 324 "progressive" parameter. 326 4. Coexistence with HTTP/2 Priorities 328 Standard HTTP/2 ([RFC7540]) endpoints use frame-based prioritization, 329 whereby a client sends priority information in dedicated fields 330 present in HEADERS and PRIORITY frames. A client might instead 331 choose to use header-based prioritization as specified in this 332 document. 334 4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter 336 To improve communication of the client's intended prioritization 337 scheme, this document specifies a new HTTP/2 SETTINGS parameter with 338 the name "SETTINGS_HEADER_BASED_PRIORITY". The value of the 339 parameter MUST be 0 or 1; the initial value is 0. Frame-based 340 prioritization is respected when the value is 0, or when the server 341 does not recognize the setting. 343 An HTTP/2 client that uses header-based priority SHOULD send a 344 "SETTINGS_HEADER_BASED_PRIORITY" parameter with a value of 1 when 345 connecting to a server. 347 An intermediary SHOULD send a "SETTINGS_HEADER_BASED_PRIORITY" 348 parameter with a value of 1 for a connection it establishes when, and 349 only when, all the requests to be sent over that connection originate 350 from a client that utilizes this header-based prioritization scheme. 351 Otherwise this settings parameter SHOULD be set to 0. 353 A client or intermediary MUST NOT send a 354 "SETTINGS_HEADER_BASED_PRIORITY" parameter with the value of 0 after 355 previously sending a value of 1. 357 A server MUST NOT send a "SETTINGS_HEADER_BASED_PRIORITY" parameter. 358 Upon receipt, a client that supports header-based prioritization MUST 359 close the connection with a protocol error. Non-supporting clients 360 will ignore this extension element (see [RFC7540], Section 5.5). 362 5. Considerations 364 5.1. Why use an End-to-End Header Field? 366 Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- 367 hop frame, the Priority header field is defined as end-to-end. 369 The rationale is that the Priority header field transmits how each 370 response affects the client's processing of those responses, rather 371 than how relatively urgent each response is to others. The way a 372 client processes a response is a property associated to that client 373 generating that request. Not that of an intermediary. Therefore, it 374 is an end-to-end property. How these end-to-end properties carried 375 by the Priority header field affect the prioritization between the 376 responses that share a connection is a hop-by-hop issue. 378 Having the Priority header field defined as end-to-end is important 379 for caching intermediaries. Such intermediaries can cache the value 380 of the Priority header field along with the response, and utilize the 381 value of the cached header field when serving the cached response, 382 only because the header field is defined as end-to-end rather than 383 hop-by-hop. 385 It should also be noted that the use of a header field carrying a 386 textual value makes the prioritization scheme extensible; see the 387 discussion below. 389 5.2. Why do Urgencies Have Meanings? 391 One of the aims of this specification is to define a mechanism for 392 merging client- and server-provided hints for prioritizing the 393 responses. For that to work, each urgency level needs to have a 394 well-defined meaning. As an example, a server can assign the highest 395 precedence among the supplementary responses to an HTTP response 396 carrying an icon, because the meaning of "urgency=1" is shared among 397 the endpoints. 399 This specification restricts itself to defining a minimum set of 400 urgency levels in order to provide sufficient granularity for 401 prioritizing responses for ordinary web browsing, at minimal 402 complexity. 404 However, that does not mean that the prioritization scheme would 405 forever be stuck to the eight levels. The design provides 406 extensibility. If deemed necessary, it would be possible to 407 subdivide any of the eight urgency levels that are currently defined. 408 Or, a graphical user-agent could send a "visible" parameter to 409 indicate if the resource being requested is within the viewport. 411 A server can combine the hints provided in the Priority header field 412 with other information in order to improve the prioritization of 413 responses. For example, a server that receives requests for a font 414 [RFC8081] and images with the same urgency might give higher 415 precedence to the font, so that a visual client can render textual 416 information at an early moment. 418 5.3. Reprioritization 420 Once a client sends a request, it cannot reprioritize the 421 corresponding response by using the Priority header field. This is 422 because an HTTP header field can only be sent as part of an HTTP 423 message. 425 Therefore, to support reprioritization, it is necessary to define a 426 HTTP-version-dependent mechanism for transmitting the priority 427 parameters. 429 One approach that we can use in HTTP/2 ([RFC7540]) is to use a frame 430 that carries the priority parameters. 432 0 1 2 3 433 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 434 +---------------------------------------------------------------+ 435 |R| Stream ID (31) | 436 +---------------------------------------------------------------+ 437 | Priority Field Value (*) ... 438 +---------------------------------------------------------------+ 440 Figure 1: Reprioritization frame payload 442 The Reprioritization frame would be sent on stream 0. This frame 443 carries the stream ID of the response that is being reprioritized, 444 and the updated priority in ASCII text, using the same 445 represententation as that of the Priority header field value. 447 As an example, a web browser might issue a prefetch request for an 448 HTML on stream 31, with the urgency parameter of the Priority request 449 header field set to "background". Then, when the user navigates to 450 the HTML while prefetch is in action, it would send a 451 reprioritization frame with the stream ID set to 31, and the priority 452 field value set to "urgency=0". 454 6. Security Considerations 456 TBD 458 7. IANA Considerations 460 This specification registers the following entry in the Permanent 461 Message Header Field Names registry established by [RFC3864]: 463 Header field name: Priority 465 Applicable protocol: http 467 Status: standard 469 Author/change controller: IETF 471 Specification document(s): This document 473 Related information: n/a 475 This specification registers the following entry in the HTTP/2 476 Settings registry established by [RFC7540]: 478 Name: SETTINGS_HEADER_BASED_PRIORITY: 480 Code: 0xTBD 482 Initial value: 0 484 Specification: This document 486 8. References 488 8.1. Normative References 490 [I-D.ietf-httpbis-header-structure] 491 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 492 draft-ietf-httpbis-header-structure-11 (work in progress), 493 July 2019. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 501 Protocol (HTTP/1.1): Message Syntax and Routing", 502 RFC 7230, DOI 10.17487/RFC7230, June 2014, 503 . 505 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 506 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 507 DOI 10.17487/RFC7540, May 2015, 508 . 510 8.2. Informative References 512 [I-D.ietf-quic-http] 513 Bishop, M., "Hypertext Transfer Protocol Version 3 514 (HTTP/3)", draft-ietf-quic-http-22 (work in progress), 515 July 2019. 517 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 518 Procedures for Message Header Fields", BCP 90, RFC 3864, 519 DOI 10.17487/RFC3864, September 2004, 520 . 522 [RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081, 523 DOI 10.17487/RFC8081, February 2017, 524 . 526 8.3. URIs 528 [1] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf 530 [2] https://github.com/pmeenan/http3-prioritization-proposal 532 Appendix A. Acknowledgements 534 Roy Fielding presented the idea of using a header field for 535 representing priorities in http://tools.ietf.org/agenda/83/slides/ 536 slides-83-httpbis-5.pdf [1]. In https://github.com/pmeenan/http3- 537 prioritization-proposal [2], Patrick Meenan advocates for 538 representing the priorities using a tuple of urgency and concurrency. 540 Many thanks to Robin Marx, Patrick Meenan and Ian Swett for their 541 feedback. 543 Appendix B. Change Log 545 B.1. Since draft-kazuho-httpbis-priority-01 547 o Explain how reprioritization might be supported. 549 B.2. Since draft-kazuho-httpbis-priority-00 551 o Expand urgency levels from 3 to 8. 553 Authors' Addresses 555 Kazuho Oku 556 Fastly 558 Email: kazuhooku@gmail.com 560 Lucas Pardue 561 Cloudflare 563 Email: lucaspardue.24.7@gmail.com