--- 1/draft-ietf-httpbis-priority-07.txt 2021-11-08 09:13:36.240042080 -0800 +++ 2/draft-ietf-httpbis-priority-08.txt 2021-11-08 09:13:36.296043481 -0800 @@ -1,19 +1,19 @@ HTTP K. Oku Internet-Draft Fastly Intended status: Standards Track L. Pardue -Expires: 28 April 2022 Cloudflare - 25 October 2021 +Expires: 12 May 2022 Cloudflare + 8 November 2021 Extensible Prioritization Scheme for HTTP - draft-ietf-httpbis-priority-07 + draft-ietf-httpbis-priority-08 Abstract This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing @@ -43,21 +43,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 April 2022. + This Internet-Draft will expire on 12 May 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -67,61 +67,62 @@ provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5 2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6 2.1.1. Advice when Using Extensible Priorities as the Alternative . . . . . . . . . . . . . . . . . . . . . 7 - 3. Applicability of the Extensible Priority Scheme . . . . . . . 7 + 3. Applicability of the Extensible Priority Scheme . . . . . . . 8 4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10 - 4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 10 - 5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 11 + 4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 11 + 5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 12 6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12 7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12 7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13 - 7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 14 - 8. Merging Client- and Server-Driven Parameters . . . . . . . . 15 - 9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 16 + 7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 15 + 8. Merging Client- and Server-Driven Parameters . . . . . . . . 16 + 9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 17 10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Intermediaries with Multiple Backend Connections . . . . 18 + 10.1. Intermediaries with Multiple Backend Connections . . . . 19 11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19 - 12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 19 + 12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 20 13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20 13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21 13.3. Intentional Introduction of Unfairness . . . . . . . . . 21 - 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 21 + 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 22 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 24 17.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 - Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 - B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 25 - B.2. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26 - B.3. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26 - B.4. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 26 - B.5. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 26 - B.6. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 26 - B.7. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27 - B.8. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27 - B.9. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 27 - B.10. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 27 - B.11. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 27 - B.12. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28 + Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 + B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26 + B.2. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26 + B.3. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26 + B.4. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26 + B.5. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27 + B.6. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27 + B.7. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27 + B.8. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27 + B.9. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27 + B.10. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28 + B.11. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28 + B.12. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28 + B.13. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction It is common for representations of an HTTP [HTTP] resource to have relationships to one or more other resources. Clients will often discover these relationships while processing a retrieved representation, which may lead to further retrieval requests. Meanwhile, the nature of the relationship determines whether the client is blocked from continuing to process locally available @@ -271,42 +272,49 @@ least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. 2.1. Disabling RFC 7540 Priorities The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]). The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this - document in order to allow endpoints to explicitly opt out of using - HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints - are encouraged to use alternative priority signals (for example, - Section 5 or Section 7.1) but there is no requirement to use a - specific signal type. - + document in order to allow endpoints to omit or ignore HTTP/2 + priority signals (see Section 5.3.2 of [HTTP2]), as described below. The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any value other than 0 or 1 MUST be treated as a connection error (see Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. The initial value is 0. - Endpoints MUST send this SETTINGS parameter as part of the first - SETTINGS frame. A sender MUST NOT change the - SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first - SETTINGS frame. Detection of a change by a receiver MUST be treated - as a connection error of type PROTOCOL_ERROR. + If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in + the first SETTINGS frame. Senders MUST NOT change the + SETTINGS_NO_RFC7540_PRIORITIES value after the first SETTINGS frame. + Receivers that detect a change MAY treat it as a connection error of + type PROTOCOL_ERROR. - The SETTINGS frame precedes any HTTP/2 priority signal sent from a - client, so a server can determine if it needs to allocate any - resource to signal handling before they arrive. A server that - receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore - HTTP/2 priority signals. + Clients can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to + indicate that they are not using HTTP/2 priority signals. The + SETTINGS frame precedes any HTTP/2 priority signal sent from clients, + so servers can determine whether they need to allocate any resources + to signal handling before signals arrive. A server that receives + SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 MUST ignore HTTP/2 + priority signals. + + Servers can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to + indicate that they will ignore HTTP/2 priority signals sent by + clients. + + Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to + use alternative priority signals (for example, Section 5 or + Section 7.1) but there is no requirement to use a specific signal + type. 2.1.1. Advice when Using Extensible Priorities as the Alternative Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see Section 5 and Section 7.1). When the client receives the first SETTINGS frame that contains the SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals. If the value was 0 or if the settings parameter was absent, it SHOULD stop sending @@ -328,28 +336,32 @@ 4. Priority Parameters The priority information is a sequence of key-value pairs, providing room for future extensions. Each key-value pair represents a priority parameter. The Priority HTTP header field (Section 5) is an end-to-end way to transmit this set of parameters when a request or a response is issued. In order to reprioritize a request, HTTP-version-specific PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by - clients to transmit the same information on a single hop. If - intermediaries want to specify prioritization on a multiplexed HTTP - connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT - change the Priority header field. + clients to transmit the same information on a single hop. - In both cases, the set of priority parameters is encoded as a - Structured Fields Dictionary (see Section 3.2 of - [STRUCTURED-FIELDS]). + Intermediaries can consume and produce priority signals in a + PRIORITY_UPDATE frame or Priority header field. Sending a + PRIORITY_UPDATE frame preserves the signal from the client, but + provides a signal that overrides for the next hop; see Section 14. + Replacing or adding a Priority header field overrides any signal from + a client and can affect prioritization for all subsequent recipients. + + For both the Priority header field and the PRIORITY_UPDATE frame, the + set of priority parameters is encoded as a Structured Fields + Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]). This document defines the urgency(u) and incremental(i) parameters. When receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values were specified. Note that handling of omitted parameters is different when processing an HTTP response; see Section 8. Receivers parse the Dictionary as defined in Section 4.2 of [STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed, this document places the additional requirement that unknown priority @@ -531,23 +543,23 @@ PRIORITY_UPDATE frames are sent by clients on the control stream, allowing them to be sent independent from the stream that carries the response. This means they can be used to reprioritize a response or a push stream; or signal the initial priority of a response instead of the Priority header field. A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field. Omitting a parameter is a signal to use the parameter's default value. Failure to parse the Priority - Field Value MUST be treated as a connection error. In HTTP/2 the + Field Value MAY be treated as a connection error. In HTTP/2 the error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type - H3_FRAME_ERROR. + H3_GENERAL_PROTOCOL_ERROR. A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open (except for HTTP/2 push streams; see Section 7.1). Furthermore, HTTP/3 offers no guaranteed ordering across streams, which could cause the frame to be received earlier than intended. Either case leads to a race condition where a server receives a PRIORITY_UPDATE frame that references a request stream that is yet to be opened. To solve this condition, for the purposes of scheduling, the most recently received PRIORITY_UPDATE frame can be considered as the most up-to-date information that overrides any other signal. @@ -1148,130 +1160,140 @@ Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy Fielding. Yang Chi contributed the section on retransmission scheduling. Appendix B. Change Log B.1. Since draft-ietf-httpbis-priority-06 + * Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES + that changes value (#1714, #1725) + + * Clarify how intermediaries might use frames vs. headers (#1715, + #1735) + + * Relax requirement when receiving a PRIORITY_UPDATE with an invalid + structured field value (#1741, #1756) + +B.2. Since draft-ietf-httpbis-priority-06 + * Focus on editorial changes * Clarify rules about Sf-Dictionary handling in headers * Split policy for parameter IANA registry into two sections based on key length -B.2. Since draft-ietf-httpbis-priority-05 +B.3. Since draft-ietf-httpbis-priority-05 * Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to SETTINGS_NO_RFC7540_PRIORITIES * Clarify that senders of the HTTP/2 setting can use any alternative (#1679, #1705) -B.3. Since draft-ietf-httpbis-priority-04 +B.4. Since draft-ietf-httpbis-priority-04 * Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601) * Reoriented text towards RFC7540bis (#1561, #1601) * Clarify intermediary behavior (#1562) -B.4. Since draft-ietf-httpbis-priority-03 +B.5. Since draft-ietf-httpbis-priority-03 * Add statement about what this scheme applies to. Clarify extensions can use it but must define how themselves (#1550, #1559) * Describe scheduling considerations for the CONNECT method (#1495, #1544) * Describe scheduling considerations for retransmitted data (#1429, #1504) * Suggest intermediaries might avoid strict prioritization (#1562) -B.5. Since draft-ietf-httpbis-priority-02 +B.6. Since draft-ietf-httpbis-priority-02 * Describe considerations for server push prioritization (#1056, #1345) * Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, #1344) * Add a Parameters registry (#1371) -B.6. Since draft-ietf-httpbis-priority-01 +B.7. Since draft-ietf-httpbis-priority-01 * PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, #1271) * Add section to describe server scheduling considerations (#1215, #1232, #1266) * Remove specific instructions related to intermediary fairness (#1022, #1264) -B.7. Since draft-ietf-httpbis-priority-00 +B.8. Since draft-ietf-httpbis-priority-00 * Move text around (#1217, #1218) * Editorial change to the default urgency. The value is 3, which was always the intent of previous changes. -B.8. Since draft-kazuho-httpbis-priority-04 - +B.9. Since draft-kazuho-httpbis-priority-04 * Minimize semantics of Urgency levels (#1023, #1026) * Reduce guidance about how intermediary implements merging priority signals (#1026) * Remove mention of CDN-Loop (#1062) * Editorial changes * Make changes due to WG adoption * Removed outdated Consideration (#118) -B.9. Since draft-kazuho-httpbis-priority-03 +B.10. Since draft-kazuho-httpbis-priority-03 * Changed numbering from [-1,6] to [0,7] (#78) * Replaced priority scheme negotiation with HTTP/2 priority deprecation (#100) * Shorten parameter names (#108) * Expand on considerations (#105, #107, #109, #110, #111, #113) -B.10. Since draft-kazuho-httpbis-priority-02 +B.11. Since draft-kazuho-httpbis-priority-02 * Consolidation of the problem statement (#61, #73) * Define SETTINGS_PRIORITIES for negotiation (#58, #69) * Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) * Explain fairness issue and mitigations (#56) -B.11. Since draft-kazuho-httpbis-priority-01 +B.12. Since draft-kazuho-httpbis-priority-01 + * Explain how reprioritization might be supported. -B.12. Since draft-kazuho-httpbis-priority-00 +B.13. Since draft-kazuho-httpbis-priority-00 * Expand urgency levels from 3 to 8. Authors' Addresses Kazuho Oku Fastly Email: kazuhooku@gmail.com - Lucas Pardue Cloudflare Email: lucaspardue.24.7@gmail.com