draft-ietf-httpbis-priority-09.txt   draft-ietf-httpbis-priority-10.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: 14 May 2022 Cloudflare Expires: 23 May 2022 Cloudflare
10 November 2021 19 November 2021
Extensible Prioritization Scheme for HTTP Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-09 draft-ietf-httpbis-priority-10
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 14 May 2022. This Internet-Draft will expire on 23 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5 2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5
2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6 2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6
2.1.1. Advice when Using Extensible Priorities as the 2.1.1. Advice when Using Extensible Priorities as the
Alternative . . . . . . . . . . . . . . . . . . . . . 7 Alternative . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability of the Extensible Priority Scheme . . . . . . . 8 3. Applicability of the Extensible Priority Scheme . . . . . . . 7
4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8 4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 7
4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10 4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10
4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 10
5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 12 5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 11
6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12 6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12
7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12 7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12
7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13 7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13
7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 15 7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 14
8. Merging Client- and Server-Driven Parameters . . . . . . . . 16 8. Merging Client- and Server-Driven Parameters . . . . . . . . 15
9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 17 9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 16
10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17 10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Intermediaries with Multiple Backend Connections . . . . 19 10.1. Intermediaries with Multiple Backend Connections . . . . 18
11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19 11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19
12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 20 12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 19
13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20 13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20
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? . . . . . . . . . . . . . 21
15. Security Considerations . . . . . . . . . . . . . . . . . . . 22 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. Normative References . . . . . . . . . . . . . . . . . . 24 17.1. Normative References . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . . . . 25
B.1. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 26 B.1. Since draft-ietf-httpbis-priority-09 . . . . . . . . . . 25
B.2. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26 B.2. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 25
B.3. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26 B.3. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26
B.4. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26 B.4. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
B.5. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 27 B.5. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26
B.6. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27 B.6. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26
B.7. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27 B.7. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 26
B.8. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27 B.8. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27
B.9. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27 B.9. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27
B.10. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 28 B.10. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27
B.11. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28 B.11. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27
B.12. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28 B.12. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28
B.13. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28 B.13. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28
B.14. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28 B.14. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 B.15. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 4, line 49 skipping to change at page 5, line 11
response relative to any other response. Section 10 and Section 12 response relative to any other response. Section 10 and Section 12
provide consideration and guidance about how servers might act upon provide consideration and guidance about how servers might act upon
signals. signals.
The prioritization scheme and priority signals defined herein can act The prioritization scheme and priority signals defined herein can act
as a substitute for RFC 7540 stream priority. as a substitute for RFC 7540 stream priority.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The terms Dictionary, sf-boolean, sf-dictionary, and sf-integer are The terms Dictionary, sf-boolean, sf-dictionary, and sf-integer are
imported from [STRUCTURED-FIELDS]. imported from [STRUCTURED-FIELDS].
Example HTTP requests and responses use the HTTP/2-style formatting Example HTTP requests and responses use the HTTP/2-style formatting
from [HTTP2]. from [HTTP2].
This document uses the variable-length integer encoding from [QUIC]. This document uses the variable-length integer encoding from [QUIC].
The term control stream is used to describe the HTTP/2 stream with The term control stream is used to describe the HTTP/2 stream with
skipping to change at page 5, line 27 skipping to change at page 5, line 38
The term HTTP/2 priority signal is used to describe the priority The term HTTP/2 priority signal is used to describe the priority
information sent from clients to servers in HTTP/2 frames; see information sent from clients to servers in HTTP/2 frames; see
Section 5.3.2 of [HTTP2]. Section 5.3.2 of [HTTP2].
2. Motivation for Replacing RFC 7540 Priorities 2. Motivation for Replacing RFC 7540 Priorities
RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex
system where clients signal stream dependencies and weights to system where clients signal stream dependencies and weights to
describe an unbalanced tree. It suffered from limited deployment and describe an unbalanced tree. It suffered from limited deployment and
interoperability and was deprecated in a revision of HTTP/2 [HTTP2]. interoperability and was deprecated in a revision of HTTP/2 [HTTP2].
However, in order to maintain wire compatibility, HTTP/2 priority HTTP/2 retains these protocol elements in order to maintain wire
signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]). compatibility (see Section 5.3.2 of [HTTP2]), which means that they
might still be used in the absence of alternative signaling, such as
Clients can build RFC 7540 trees with rich flexibility but experience the scheme this document describes.
has shown this is rarely exercised. Instead they tend to choose a
single model optimized for a single use case and experiment within
the model constraints, or do nothing at all. Furthermore, many
clients build their prioritization tree in a unique way, which makes
it difficult for servers to understand their intent and act or
intervene accordingly.
Many RFC 7540 server implementations do not act on HTTP/2 priority Many RFC 7540 server implementations do not act on HTTP/2 priority
signals. Some instead favor custom server-driven schemes based on signals.
heuristics or other hints, such as resource content type or request
generation order. For example, a server, with knowledge of an HTML
document structure, might want to prioritize the delivery of images
that are critical to user experience above other images, but below
the CSS files. Since client trees vary, it is impossible for the
server to determine how such images should be prioritized against
other responses.
RFC 7540 allows intermediaries to coalesce multiple client trees into
a single tree that is used for a single upstream HTTP/2 connection.
However, most intermediaries do not support this. Additionally, RFC
7540 does not define a method that can be used by a server to express
the priority of a response. Without such a method, intermediaries
cannot coordinate client-driven and server-driven priorities.
RFC 7540 describes denial-of-service considerations for Prioritization can use information that servers have about resources
implementations. On 2019-08-13 Netflix issued an advisory notice or the order in which requests are generated. For example, a server,
about the discovery of several resource exhaustion vectors affecting with knowledge of an HTML document structure, might want to
multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka prioritize the delivery of images that are critical to user
"Resource Loop", is based on using priority signals to manipulate the experience above other images. With RFC 7540 it is difficult for
server's stored prioritization state. servers to interpret signals from clients for prioritization as the
same conditions could result in very different signaling from
different clients. This document describes signaling that is simpler
and more constrained, requiring less interpretation and allowing less
variation.
HTTP/2 priority associated with an HTTP request is signalled as a RFC 7540 does not define a method that can be used by a server to
value relative to those of other requests sharing the same HTTP/2 provide a priority signal for intermediaries.
connection. Therefore, in order to prioritize requests, endpoints
are compelled to have the knowledge of the underlying HTTP version
and how the requests are coalesced. This has been a burden to HTTP
endpoints that generate or forward requests in a version-agnostic
manner.
HTTP/2 priority signals are required to be delivered and processed in RFC 7540 priority is expressed relative to other requests on the same
the order they are sent so that the receiver handling is connection. Many requests are generated without knowledge of how
deterministic. Porting HTTP/2 priority signals to protocols that do other requests might share a connection, which makes this difficult
not provide ordering guarantees presents challenges. For example, to use reliably, especially in protocols that do not have strong
HTTP/3 [HTTP3] lacks global ordering across streams that would carry ordering guarantees, like HTTP/3 [HTTP3].
priority signals. Early attempts to port HTTP/2 priority signals to
HTTP/3 required adding additional information to the signals, leading
to more complicated processing. Problems found with this approach
could not be resolved and definition of a HTTP/3 priority signalling
feature was removed before publication.
Considering the deployment problems and the design restrictions of Multiple experiments from independent research have shown that
RFC 7540 stream priority, as well as the difficulties in adapting it simpler schemes can reach at least equivalent performance
to HTTP/3, continuing to base prioritization on this mechanism risks characteristics compared to the more complex RFC 7540 setups seen in
increasing the complexity of systems. Multiple experiments from practice, at least for the web use case.
independent research have shown that simpler schemes can reach at
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 2.1. Disabling RFC 7540 Priorities
The problems and insights set out above provided the motivation for The problems and insights set out above provided the motivation for
deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]). an alternative to RFC 7540 stream priority (see Section 5.3 of
[HTTP2]).
The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this
document in order to allow endpoints to omit or ignore HTTP/2 document in order to allow endpoints to omit or ignore HTTP/2
priority signals (see Section 5.3.2 of [HTTP2]), as described below. 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 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 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 Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. The initial value
is 0. is 0.
If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in
skipping to change at page 7, line 38 skipping to change at page 7, line 16
indicate that they will ignore HTTP/2 priority signals sent by indicate that they will ignore HTTP/2 priority signals sent by
clients. clients.
Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to
use alternative priority signals (for example, Section 5 or use alternative priority signals (for example, Section 5 or
Section 7.1) but there is no requirement to use a specific signal Section 7.1) but there is no requirement to use a specific signal
type. type.
2.1.1. Advice when Using Extensible Priorities as the Alternative 2.1.1. Advice when Using Extensible Priorities as the Alternative
Until the client receives the SETTINGS frame from the server, the Before receiving a SETTINGS frame from a server, a client does not
know if the server is ignoring HTTP/2 priority signals. Therefore,
until the client receives the SETTINGS frame from the server, the
client SHOULD send both the HTTP/2 priority signals and the signals client SHOULD send both the HTTP/2 priority signals and the signals
of this prioritization scheme (see Section 5 and Section 7.1). When of this prioritization scheme (see Section 5 and Section 7.1).
the client receives the first SETTINGS frame that contains the
Once the client receives the first SETTINGS frame that contains the
SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD 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 stop sending the HTTP/2 priority signals. This avoids sending
the settings parameter was absent, it SHOULD stop sending redundant signals that are known to be ignored.
PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the
Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with
value of 0 or if the settings parameter was absent, it SHOULD stop
sending PRIORITY_UPDATE frames (Section 7.1), since those frames are
likely to be ignored. However, the client MAY continue sending the
Priority header field (Section 5), as it is an end-to-end signal that Priority header field (Section 5), as it is an end-to-end signal that
might be useful to nodes behind the server that the client is might be useful to nodes behind the server that the client is
directly connected to. directly connected to.
3. Applicability of the Extensible Priority Scheme 3. Applicability of the Extensible Priority Scheme
The priority scheme defined by this document considers only the The priority scheme defined by this document considers only the
prioritization of HTTP messages and tunnels, see Section 9, prioritization of HTTP messages and tunnels, see Section 9,
Section 10, and Section 11. Section 10, and Section 11.
skipping to change at page 24, line 39 skipping to change at page 24, line 15
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[STRUCTURED-FIELDS] [STRUCTURED-FIELDS]
Nottingham, M. and P-H. Kamp, "Structured Field Values for Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/rfc/rfc8941>. <https://www.rfc-editor.org/rfc/rfc8941>.
17.2. Informative References 17.2. Informative References
[CACHING] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP [CACHING] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Caching", Work in Progress, Internet-Draft, draft-ietf- Caching", Work in Progress, Internet-Draft, draft-ietf-
httpbis-cache-19, 12 September 2021, httpbis-cache-19, 12 September 2021,
skipping to change at page 26, line 22 skipping to change at page 25, line 45
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
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
B.1. Since draft-ietf-httpbis-priority-08 B.1. Since draft-ietf-httpbis-priority-09
* Editorial changes
B.2. Since draft-ietf-httpbis-priority-08
* Changelog fixups * Changelog fixups
B.2. Since draft-ietf-httpbis-priority-07 B.3. 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.3. Since draft-ietf-httpbis-priority-06 B.4. 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.4. Since draft-ietf-httpbis-priority-05 B.5. 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.5. Since draft-ietf-httpbis-priority-04 B.6. 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.6. Since draft-ietf-httpbis-priority-03 B.7. 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.7. Since draft-ietf-httpbis-priority-02 B.8. 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.8. Since draft-ietf-httpbis-priority-01 B.9. 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.9. Since draft-ietf-httpbis-priority-00 B.10. 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.10. Since draft-kazuho-httpbis-priority-04 B.11. 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.11. Since draft-kazuho-httpbis-priority-03 B.12. 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.12. Since draft-kazuho-httpbis-priority-02 B.13. 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.13. Since draft-kazuho-httpbis-priority-01 B.14. Since draft-kazuho-httpbis-priority-01
* Explain how reprioritization might be supported. * Explain how reprioritization might be supported.
B.14. Since draft-kazuho-httpbis-priority-00 B.15. 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
 End of changes. 41 change blocks. 
116 lines changed or deleted 106 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/