draft-ietf-httpbis-priority-08.txt   draft-ietf-httpbis-priority-09.txt 
HTTP K. Oku HTTP K. Oku
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track L. Pardue Intended status: Standards Track L. Pardue
Expires: 12 May 2022 Cloudflare Expires: 14 May 2022 Cloudflare
8 November 2021 10 November 2021
Extensible Prioritization Scheme for HTTP Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-08 draft-ietf-httpbis-priority-09
Abstract Abstract
This document describes a scheme that allows an HTTP client to This document describes a scheme that allows an HTTP client to
communicate its preferences for how the upstream server prioritizes communicate its preferences for how the upstream server prioritizes
responses to its requests, and also allows a server to hint to a responses to its requests, and also allows a server to hint to a
downstream intermediary how its responses should be prioritized when downstream intermediary how its responses should be prioritized when
they are forwarded. This document defines the Priority header field they are forwarded. This document defines the Priority header field
for communicating the initial priority in an HTTP version-independent for communicating the initial priority in an HTTP version-independent
manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 May 2022. This Internet-Draft will expire on 14 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 14 skipping to change at page 3, line 14
13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21 13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21
13.3. Intentional Introduction of Unfairness . . . . . . . . . 21 13.3. Intentional Introduction of Unfairness . . . . . . . . . 21
14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 22 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 22
15. Security Considerations . . . . . . . . . . . . . . . . . . . 22 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. Normative References . . . . . . . . . . . . . . . . . . 24 17.1. Normative References . . . . . . . . . . . . . . . . . . 24
17.2. Informative References . . . . . . . . . . . . . . . . . 24 17.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26 B.1. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 26
B.2. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26 B.2. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26
B.3. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26 B.3. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
B.4. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26 B.4. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26
B.5. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27 B.5. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 27
B.6. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27 B.6. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27
B.7. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27 B.7. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27
B.8. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27 B.8. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27
B.9. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27 B.9. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27
B.10. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28 B.10. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 28
B.11. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28 B.11. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28
B.12. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28 B.12. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28
B.13. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28 B.13. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 B.14. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
It is common for representations of an HTTP [HTTP] resource to have It is common for representations of an HTTP [HTTP] resource to have
relationships to one or more other resources. Clients will often relationships to one or more other resources. Clients will often
discover these relationships while processing a retrieved discover these relationships while processing a retrieved
representation, which may lead to further retrieval requests. representation, which may lead to further retrieval requests.
Meanwhile, the nature of the relationship determines whether the Meanwhile, the nature of the relationship determines whether the
client is blocked from continuing to process locally available client is blocked from continuing to process locally available
resources. An example of this is visual rendering of an HTML resources. An example of this is visual rendering of an HTML
skipping to change at page 8, line 30 skipping to change at page 8, line 30
The Priority HTTP header field (Section 5) is an end-to-end way to 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 transmit this set of parameters when a request or a response is
issued. In order to reprioritize a request, HTTP-version-specific issued. In order to reprioritize a request, HTTP-version-specific
PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by
clients to transmit the same information on a single hop. clients to transmit the same information on a single hop.
Intermediaries can consume and produce priority signals in a Intermediaries can consume and produce priority signals in a
PRIORITY_UPDATE frame or Priority header field. Sending a PRIORITY_UPDATE frame or Priority header field. Sending a
PRIORITY_UPDATE frame preserves the signal from the client, but PRIORITY_UPDATE frame preserves the signal from the client, but
provides a signal that overrides for the next hop; see Section 14. provides a signal that overrides that for the next hop; see
Replacing or adding a Priority header field overrides any signal from Section 14. Replacing or adding a Priority header field overrides
a client and can affect prioritization for all subsequent recipients. 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 For both the Priority header field and the PRIORITY_UPDATE frame, the
set of priority parameters is encoded as a Structured Fields set of priority parameters is encoded as a Structured Fields
Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]). Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]).
This document defines the urgency(u) and incremental(i) parameters. This document defines the urgency(u) and incremental(i) parameters.
When receiving an HTTP request that does not carry these priority When receiving an HTTP request that does not carry these priority
parameters, a server SHOULD act as if their default values were parameters, a server SHOULD act as if their default values were
specified. Note that handling of omitted parameters is different specified. Note that handling of omitted parameters is different
when processing an HTTP response; see Section 8. when processing an HTTP response; see Section 8.
skipping to change at page 26, line 20 skipping to change at page 26, line 20
In addition to the people above, this document owes a lot to the In addition to the people above, this document owes a lot to the
extensive discussion in the HTTP priority design team, consisting of extensive discussion in the HTTP priority design team, consisting of
Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku,
Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy
Fielding. Fielding.
Yang Chi contributed the section on retransmission scheduling. Yang Chi contributed the section on retransmission scheduling.
Appendix B. Change Log Appendix B. Change Log
B.1. Since draft-ietf-httpbis-priority-06 _RFC EDITOR: please remove this section before publication_
B.1. Since draft-ietf-httpbis-priority-08
* Changelog fixups
B.2. Since draft-ietf-httpbis-priority-07
* Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES * Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES
that changes value (#1714, #1725) that changes value (#1714, #1725)
* Clarify how intermediaries might use frames vs. headers (#1715, * Clarify how intermediaries might use frames vs. headers (#1715,
#1735) #1735)
* Relax requirement when receiving a PRIORITY_UPDATE with an invalid * Relax requirement when receiving a PRIORITY_UPDATE with an invalid
structured field value (#1741, #1756) structured field value (#1741, #1756)
B.2. Since draft-ietf-httpbis-priority-06 B.3. Since draft-ietf-httpbis-priority-06
* Focus on editorial changes * Focus on editorial changes
* Clarify rules about Sf-Dictionary handling in headers * Clarify rules about Sf-Dictionary handling in headers
* Split policy for parameter IANA registry into two sections based * Split policy for parameter IANA registry into two sections based
on key length on key length
B.3. Since draft-ietf-httpbis-priority-05 B.4. Since draft-ietf-httpbis-priority-05
* Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to * Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to
SETTINGS_NO_RFC7540_PRIORITIES SETTINGS_NO_RFC7540_PRIORITIES
* Clarify that senders of the HTTP/2 setting can use any alternative * Clarify that senders of the HTTP/2 setting can use any alternative
(#1679, #1705) (#1679, #1705)
B.4. Since draft-ietf-httpbis-priority-04 B.5. Since draft-ietf-httpbis-priority-04
* Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to * Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to
SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601) SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601)
* Reoriented text towards RFC7540bis (#1561, #1601) * Reoriented text towards RFC7540bis (#1561, #1601)
* Clarify intermediary behavior (#1562) * Clarify intermediary behavior (#1562)
B.5. Since draft-ietf-httpbis-priority-03 B.6. Since draft-ietf-httpbis-priority-03
* Add statement about what this scheme applies to. Clarify * Add statement about what this scheme applies to. Clarify
extensions can use it but must define how themselves (#1550, extensions can use it but must define how themselves (#1550,
#1559) #1559)
* Describe scheduling considerations for the CONNECT method (#1495, * Describe scheduling considerations for the CONNECT method (#1495,
#1544) #1544)
* Describe scheduling considerations for retransmitted data (#1429, * Describe scheduling considerations for retransmitted data (#1429,
#1504) #1504)
* Suggest intermediaries might avoid strict prioritization (#1562) * Suggest intermediaries might avoid strict prioritization (#1562)
B.6. Since draft-ietf-httpbis-priority-02 B.7. Since draft-ietf-httpbis-priority-02
* Describe considerations for server push prioritization (#1056, * Describe considerations for server push prioritization (#1056,
#1345) #1345)
* Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, * Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261,
#1344) #1344)
* Add a Parameters registry (#1371) * Add a Parameters registry (#1371)
B.7. Since draft-ietf-httpbis-priority-01 B.8. Since draft-ietf-httpbis-priority-01
* PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, * PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,
#1271) #1271)
* Add section to describe server scheduling considerations (#1215, * Add section to describe server scheduling considerations (#1215,
#1232, #1266) #1232, #1266)
* Remove specific instructions related to intermediary fairness * Remove specific instructions related to intermediary fairness
(#1022, #1264) (#1022, #1264)
B.8. Since draft-ietf-httpbis-priority-00 B.9. Since draft-ietf-httpbis-priority-00
* Move text around (#1217, #1218) * Move text around (#1217, #1218)
* Editorial change to the default urgency. The value is 3, which * Editorial change to the default urgency. The value is 3, which
was always the intent of previous changes. was always the intent of previous changes.
B.9. Since draft-kazuho-httpbis-priority-04 B.10. Since draft-kazuho-httpbis-priority-04
* Minimize semantics of Urgency levels (#1023, #1026) * Minimize semantics of Urgency levels (#1023, #1026)
* Reduce guidance about how intermediary implements merging priority * Reduce guidance about how intermediary implements merging priority
signals (#1026) signals (#1026)
* Remove mention of CDN-Loop (#1062) * Remove mention of CDN-Loop (#1062)
* Editorial changes * Editorial changes
* Make changes due to WG adoption * Make changes due to WG adoption
* Removed outdated Consideration (#118) * Removed outdated Consideration (#118)
B.10. Since draft-kazuho-httpbis-priority-03 B.11. Since draft-kazuho-httpbis-priority-03
* Changed numbering from [-1,6] to [0,7] (#78) * Changed numbering from [-1,6] to [0,7] (#78)
* Replaced priority scheme negotiation with HTTP/2 priority * Replaced priority scheme negotiation with HTTP/2 priority
deprecation (#100) deprecation (#100)
* Shorten parameter names (#108) * Shorten parameter names (#108)
* Expand on considerations (#105, #107, #109, #110, #111, #113) * Expand on considerations (#105, #107, #109, #110, #111, #113)
B.11. Since draft-kazuho-httpbis-priority-02 B.12. Since draft-kazuho-httpbis-priority-02
* Consolidation of the problem statement (#61, #73) * Consolidation of the problem statement (#61, #73)
* Define SETTINGS_PRIORITIES for negotiation (#58, #69) * Define SETTINGS_PRIORITIES for negotiation (#58, #69)
* Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) * Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
* Explain fairness issue and mitigations (#56) * Explain fairness issue and mitigations (#56)
B.12. Since draft-kazuho-httpbis-priority-01 B.13. Since draft-kazuho-httpbis-priority-01
* Explain how reprioritization might be supported. * Explain how reprioritization might be supported.
B.13. Since draft-kazuho-httpbis-priority-00 B.14. Since draft-kazuho-httpbis-priority-00
* Expand urgency levels from 3 to 8. * Expand urgency levels from 3 to 8.
Authors' Addresses Authors' Addresses
Kazuho Oku Kazuho Oku
Fastly Fastly
Email: kazuhooku@gmail.com Email: kazuhooku@gmail.com
Lucas Pardue Lucas Pardue
Cloudflare Cloudflare
Email: lucaspardue.24.7@gmail.com Email: lucaspardue.24.7@gmail.com
 End of changes. 20 change blocks. 
35 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/