draft-ietf-httpbis-priority-11.txt   draft-ietf-httpbis-priority-12.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 June 2022 Cloudflare Expires: 22 July 2022 Cloudflare
9 December 2021 18 January 2022
Extensible Prioritization Scheme for HTTP Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-11 draft-ietf-httpbis-priority-12
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 June 2022. This Internet-Draft will expire on 22 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as extracted from this document must include Revised BSD License text 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 Revised BSD License. provided without warranty as described in the Revised BSD License.
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? . . . . . . . . . . . . . 21 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 21
15. Security Considerations . . . . . . . . . . . . . . . . . . . 22 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. Normative References . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . 26
B.1. Since draft-ietf-httpbis-priority-10 . . . . . . . . . . 26 B.1. Since draft-ietf-httpbis-priority-11 . . . . . . . . . . 26
B.2. Since draft-ietf-httpbis-priority-09 . . . . . . . . . . 26 B.2. Since draft-ietf-httpbis-priority-10 . . . . . . . . . . 26
B.3. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 26 B.3. Since draft-ietf-httpbis-priority-09 . . . . . . . . . . 26
B.4. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26 B.4. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 26
B.5. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26 B.5. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26
B.6. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 27 B.6. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
B.7. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 27 B.7. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 27
B.8. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27 B.8. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 27
B.9. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27 B.9. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27
B.10. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27 B.10. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27
B.11. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 28 B.11. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27
B.12. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 28 B.12. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 28
B.13. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28 B.13. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 28
B.14. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28 B.14. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28
B.15. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 29 B.15. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28
B.16. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 29 B.16. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 29
B.17. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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
skipping to change at page 4, line 14 skipping to change at page 4, line 8
HTTP/2 [HTTP2] and HTTP/3 [HTTP3] support multiplexing of requests HTTP/2 [HTTP2] and HTTP/3 [HTTP3] support multiplexing of requests
and responses in a single connection. An important feature of any and responses in a single connection. An important feature of any
implementation of a protocol that provides multiplexing is the implementation of a protocol that provides multiplexing is the
ability to prioritize the sending of information. For example, to ability to prioritize the sending of information. For example, to
provide meaningful presentation of an HTML document at the earliest provide meaningful presentation of an HTML document at the earliest
moment, it is important for an HTTP server to prioritize the HTTP moment, it is important for an HTTP server to prioritize the HTTP
responses, or the chunks of those HTTP responses, that it sends to a responses, or the chunks of those HTTP responses, that it sends to a
client. client.
A server that operates in ignorance of how clients issue requests and HTTP/2 and HTTP/3 servers can schedule transmission of concurrent
consume responses can cause suboptimal client application response data by any means they choose. Servers can ignore client
performance. Priority signals allow clients to communicate their priority signals and still successfully serve HTTP responses.
view of request priority. Servers have their own needs that are However, servers that operate in ignorance of how clients issue
independent from client needs, so they often combine priority signals requests and consume responses can cause suboptimal client
with other available information in order to inform scheduling of application performance. Priority signals allow clients to
response data. communicate their view of request priority. Servers have their own
needs that are independent of client needs, so they often combine
priority signals with other available information in order to inform
scheduling of response data.
RFC 7540 [RFC7540] stream priority allowed a client to send a series RFC 7540 [RFC7540] stream priority allowed a client to send a series
of priority signals that communicate to the server a "priority tree"; of priority signals that communicate to the server a "priority tree";
the structure of this tree represents the client's preferred relative the structure of this tree represents the client's preferred relative
ordering and weighted distribution of the bandwidth among HTTP ordering and weighted distribution of the bandwidth among HTTP
responses. Servers could use these priority signals as input into responses. Servers could use these priority signals as input into
prioritization decision making. prioritization decision-making.
The design and implementation of RFC 7540 stream priority was The design and implementation of RFC 7540 stream priority was
observed to have shortcomings, explained in Section 2. HTTP/2 observed to have shortcomings, explained in Section 2. HTTP/2
[HTTP2] has consequently deprecated the use of these stream priority [HTTP2] has consequently deprecated the use of these stream priority
signals. The prioritization scheme and priority signals defined signals. The prioritization scheme and priority signals defined
herein can act as a substitute for RFC 7540 stream priority. herein can act as a substitute for RFC 7540 stream priority.
This document describes an extensible scheme for prioritizing HTTP This document describes an extensible scheme for prioritizing HTTP
responses that uses absolute values. Section 4 defines priority responses that uses absolute values. Section 4 defines priority
parameters, which are a standardized and extensible format of parameters, which are a standardized and extensible format of
priority information. Section 5 defines the Priority HTTP header priority information. Section 5 defines the Priority HTTP header
field, a protocol-version-independent and end-to-end priority signal. field, a protocol-version-independent and end-to-end priority signal.
Clients can send this header field to signal their view of how Clients can send this header field to signal their view of how
responses should be prioritized. Similarly, servers behind an responses should be prioritized. Similarly, servers behind an
intermediary can use it to signal priority to the intermediary. intermediary can use it to signal priority to the intermediary.
After sending a request, a client can change the priority of the After sending a request, a client can change their view of response
response (see Section 6) using HTTP-version-specific frames defined priority (see Section 6) by sending HTTP-version-specific frames
in Section 7.1 and Section 7.2. defined in Section 7.1 and Section 7.2.
Header field and frame priority signals are input to a server's Header field and frame priority signals are input to a server's
response prioritization process. They are only a suggestion and do response prioritization process. They are only a suggestion and do
not guarantee any particular processing or transmission order for one not guarantee any particular processing or transmission order for one
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.
1.1. Notational Conventions 1.1. Notational Conventions
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 both the HTTP/2 stream The term control stream is used to describe both the HTTP/2 stream
with identifier 0x0, and the HTTP/3 control stream; see Section 6.2.1 with identifier 0x0 and the HTTP/3 control stream; see Section 6.2.1
of [HTTP3]. of [HTTP3].
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
skipping to change at page 6, line 8 skipping to change at page 6, line 8
experience above other images. With RFC 7540 it is difficult for experience above other images. With RFC 7540 it is difficult for
servers to interpret signals from clients for prioritization as the servers to interpret signals from clients for prioritization as the
same conditions could result in very different signaling from same conditions could result in very different signaling from
different clients. This document describes signaling that is simpler different clients. This document describes signaling that is simpler
and more constrained, requiring less interpretation and allowing less and more constrained, requiring less interpretation and allowing less
variation. variation.
RFC 7540 does not define a method that can be used by a server to RFC 7540 does not define a method that can be used by a server to
provide a priority signal for intermediaries. provide a priority signal for intermediaries.
RFC 7540 priority is expressed relative to other requests on the same RFC 7540 priority is expressed relative to other requests sharing the
connection. Many requests are generated without knowledge of how same connection at the same time. It is difficult to incorporate
other requests might share a connection, which makes this difficult such design into applications that generate requests without
to use reliably, especially in protocols that do not have strong knowledge of how other requests might share a connection, or into
ordering guarantees, like HTTP/3 [HTTP3]. protocols that do not have strong ordering guarantees across streams,
like HTTP/3 [HTTP3].
Multiple experiments from independent research ([MARX], [MEENAN]) Experiments from independent research ([MARX]) have shown that
have shown that simpler schemes can reach at least equivalent simpler schemes can reach at least equivalent performance
performance characteristics compared to the more complex RFC 7540 characteristics compared to the more complex RFC 7540 setups seen in
setups seen in practice, at least for the web use case. 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
an alternative to RFC 7540 stream priority (see Section 5.3 of an alternative to RFC 7540 stream priority (see Section 5.3 of
[HTTP2]). [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.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
sending PRIORITY_UPDATE frames (Section 7.1), since those frames are sending PRIORITY_UPDATE frames (Section 7.1), since those frames are
likely to be ignored. However, the client MAY continue sending the 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 is primarily focused on The priority scheme defined by this document is primarily focused on
the prioritization of HTTP response messages (see Section 3.4 of the prioritization of HTTP response messages (see Section 3.4 of
[HTTP]). It defines new priority parameters (Section 4) and their [HTTP]). It defines new priority parameters (Section 4) and a means
conveyors (Section 5 and Section 7) intended to communicate the of conveying those parameters (Section 5 and Section 7), which is
priority of responses to a server that is responsible for intended to communicate the priority of responses to a server that is
prioritizing them. Section 10 provides considerations for servers responsible for prioritizing them. Section 10 provides
about acting on those signals in combination with other inputs and considerations for servers about acting on those signals in
factors. combination with other inputs and factors.
The CONNECT method (see Section 9.3.6 of [HTTP]) can be used to The CONNECT method (see Section 9.3.6 of [HTTP]) can be used to
establish tunnels. Signaling applies similarly to tunnels; establish tunnels. Signaling applies similarly to tunnels;
additional considerations for server prioritization are given in additional considerations for server prioritization are given in
Section 11. Section 11.
Section 9 describes how clients can optionally apply elements of this Section 9 describes how clients can optionally apply elements of this
scheme locally to the request messages that they generate. scheme locally to the request messages that they generate.
Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream
skipping to change at page 8, line 13 skipping to change at page 8, line 13
define themselves how this priority scheme is to be applied. define themselves how this priority scheme is to be applied.
4. Priority Parameters 4. Priority Parameters
The priority information is a sequence of key-value pairs, providing The priority information is a sequence of key-value pairs, providing
room for future extensions. Each key-value pair represents a room for future extensions. Each key-value pair represents a
priority parameter. priority parameter.
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 priority parameters when a request or a response transmit this set of priority parameters when a request or a response
is issued. In order to reprioritize a request (Section 6), HTTP- is issued. After sending a request, a client can change their view
version-specific PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) of response priority (Section 6) by sending HTTP-version-specific
are used by clients to transmit the same information on a single hop. PRIORITY_UPDATE frames defined in Section 7.1 and Section 7.2.
Frames transmit priority parameters on a single hop only.
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 carried by
provides a signal that overrides that for the next hop; see the Priority header field, but provides a signal that overrides that
Section 14. Replacing or adding a Priority header field overrides for the next hop; see Section 14. Replacing or adding a Priority
any signal from a client and can affect prioritization for all header field overrides any signal from a client and can affect
subsequent recipients. 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) priority This document defines the urgency(u) and incremental(i) priority
parameters. When receiving an HTTP request that does not carry these parameters. When receiving an HTTP request that does not carry these
priority parameters, a server SHOULD act as if their default values priority parameters, a server SHOULD act as if their default values
were specified. were specified.
skipping to change at page 11, line 35 skipping to change at page 11, line 35
Reference: [to a specification defining this priority parameter] Reference: [to a specification defining this priority parameter]
See the registry at https://iana.org/assignments/http-priority See the registry at https://iana.org/assignments/http-priority
(https://iana.org/assignments/http-priority) for details on where to (https://iana.org/assignments/http-priority) for details on where to
send registration requests. send registration requests.
5. The Priority HTTP Header Field 5. The Priority HTTP Header Field
The Priority HTTP header field carries priority parameters (see The Priority HTTP header field carries priority parameters (see
Section 4). It can appear in requests and responses. It is an end- Section 4). It can appear in requests and responses. It is an end-
to-end signal of the request priority from the client or the response to-end signal that indicates the endpoint's view of how HTTP
priority from the server. Section 8 describes how intermediaries can responses should be prioritized. Section 8 describes how
combine the priority information sent from clients and servers. intermediaries can combine the priority information sent from clients
Clients cannot interpret the appearance or omission of a Priority and servers. Clients cannot interpret the appearance or omission of
response header field as acknowledgement that any prioritization has a Priority response header field as acknowledgement that any
occurred. Guidance for how endpoints can act on Priority header prioritization has occurred. Guidance for how endpoints can act on
values is given in Section 10 and Section 9. Priority header values is given in Section 9 and Section 10.
Priority is a Dictionary (Section 3.2 of [STRUCTURED-FIELDS]): Priority is a Dictionary (Section 3.2 of [STRUCTURED-FIELDS]):
Priority = sf-dictionary Priority = sf-dictionary
An HTTP request with a Priority header field might be cached and re- An HTTP request with a Priority header field might be cached and re-
used for subsequent requests; see [CACHING]. When an origin server used for subsequent requests; see [CACHING]. When an origin server
generates the Priority response header field based on properties of generates the Priority response header field based on properties of
an HTTP request it receives, the server is expected to control the an HTTP request it receives, the server is expected to control the
cacheability or the applicability of the cached response, by using cacheability or the applicability of the cached response, by using
header fields that control the caching behavior (e.g., Cache-Control, header fields that control the caching behavior (e.g., Cache-Control,
skipping to change at page 12, line 35 skipping to change at page 12, line 35
This document specifies a new PRIORITY_UPDATE frame for HTTP/2 This document specifies a new PRIORITY_UPDATE frame for HTTP/2
[HTTP2] and HTTP/3 [HTTP3]. It carries priority parameters and [HTTP2] and HTTP/3 [HTTP3]. It carries priority parameters and
references the target of the prioritization based on a version- references the target of the prioritization based on a version-
specific identifier. In HTTP/2, this identifier is the Stream ID; in specific identifier. In HTTP/2, this identifier is the Stream ID; in
HTTP/3, the identifier is either the Stream ID or Push ID. Unlike HTTP/3, the identifier is either the Stream ID or Push ID. Unlike
the Priority header field, the PRIORITY_UPDATE frame is a hop-by-hop the Priority header field, the PRIORITY_UPDATE frame is a hop-by-hop
signal. signal.
PRIORITY_UPDATE frames are sent by clients on the control stream, PRIORITY_UPDATE frames are sent by clients on the control stream,
allowing them to be sent independent from the stream that carries the allowing them to be sent independent of the stream that carries the
response. This means they can be used to reprioritize a response or response. This means they can be used to reprioritize a response or
a push stream; or signal the initial priority of a response instead a push stream; or signal the initial priority of a response instead
of the Priority header field. of the Priority header field.
A PRIORITY_UPDATE frame communicates a complete set of all priority A PRIORITY_UPDATE frame communicates a complete set of all priority
parameters in the Priority Field Value field. Omitting a priority parameters in the Priority Field Value field. Omitting a priority
parameter is a signal to use its default value. Failure to parse the parameter is a signal to use its default value. Failure to parse the
Priority Field Value MAY be treated as a connection error. In HTTP/2 Priority 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 the error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type
H3_GENERAL_PROTOCOL_ERROR. H3_GENERAL_PROTOCOL_ERROR.
skipping to change at page 13, line 11 skipping to change at page 13, line 11
Furthermore, HTTP/3 offers no guaranteed ordering across streams, Furthermore, HTTP/3 offers no guaranteed ordering across streams,
which could cause the frame to be received earlier than intended. which could cause the frame to be received earlier than intended.
Either case leads to a race condition where a server receives a Either case leads to a race condition where a server receives a
PRIORITY_UPDATE frame that references a request stream that is yet to PRIORITY_UPDATE frame that references a request stream that is yet to
be opened. To solve this condition, for the purposes of scheduling, be opened. To solve this condition, for the purposes of scheduling,
the most recently received PRIORITY_UPDATE frame can be considered as the most recently received PRIORITY_UPDATE frame can be considered as
the most up-to-date information that overrides any other signal. the most up-to-date information that overrides any other signal.
Servers SHOULD buffer the most recently received PRIORITY_UPDATE Servers SHOULD buffer the most recently received PRIORITY_UPDATE
frame and apply it once the referenced stream is opened. Holding frame and apply it once the referenced stream is opened. Holding
PRIORITY_UPDATE frames for each stream requires server resources, PRIORITY_UPDATE frames for each stream requires server resources,
which can can be bounded by local implementation policy. Although which can be bounded by local implementation policy. Although there
there is no limit to the number of PRIORITY_UPDATES that can be sent, is no limit to the number of PRIORITY_UPDATE frames that can be sent,
storing only the most recently received frame limits resource storing only the most recently received frame limits resource
commitment. commitment.
7.1. HTTP/2 PRIORITY_UPDATE Frame 7.1. HTTP/2 PRIORITY_UPDATE Frame
The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to
signal the initial priority of a response, or to reprioritize a signal the initial priority of a response, or to reprioritize a
response or push stream. It carries the stream ID of the response response or push stream. It carries the stream ID of the response
and the priority in ASCII text, using the same representation as the and the priority in ASCII text, using the same representation as the
Priority header field value. Priority header field value.
The Stream Identifier field (see Section 5.1.1 of [HTTP2]) in the The Stream Identifier field (see Section 5.1.1 of [HTTP2]) in the
PRIORITY_UPDATE frame header MUST be zero (0x0). Receiving a PRIORITY_UPDATE frame header MUST be zero (0x0). Receiving a
PRIORITY_UPDATE frame with a field of any other value MUST be treated PRIORITY_UPDATE frame with a field of any other value MUST be treated
as a connection error of type PROTOCOL_ERROR. as a connection error of type PROTOCOL_ERROR.
HTTP/2 PRIORITY_UPDATE Frame { HTTP/2 PRIORITY_UPDATE Frame {
Length (24), Length (24),
Type (i) = 10, Type (8) = 0x10,
Unused Flags (8). Unused Flags (8).
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Reserved (1), Reserved (1),
Prioritized Stream ID (31), Prioritized Stream ID (31),
Priority Field Value (..), Priority Field Value (..),
} }
Figure 1: HTTP/2 PRIORITY_UPDATE Frame Payload Figure 1: HTTP/2 PRIORITY_UPDATE Frame Payload
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4 of [HTTP2]. The frame payload of fields are described in Section 4 of [HTTP2]. The PRIORITY_UPDATE
PRIORITY_UPDATE frame payload contains the following additional frame payload contains the following additional fields:
fields:
Reserved: A reserved 1-bit field. The semantics of this bit are Reserved: A reserved 1-bit field. The semantics of this bit are
undefined, and the bit MUST remain unset (0x0) when sending and undefined. It MUST remain unset (0x0) when sending and MUST be
MUST be ignored when receiving. ignored when receiving.
Prioritized Stream ID: A 31-bit stream identifier for the stream Prioritized Stream ID: A 31-bit stream identifier for the stream
that is the target of the priority update. that is the target of the priority update.
Priority Field Value: The priority update value in ASCII text, Priority Field Value: The priority update value in ASCII text,
encoded using Structured Fields. This is the same representation encoded using Structured Fields. This is the same representation
as the Priority header field value. as the Priority header field value.
When the PRIORITY_UPDATE frame applies to a request stream, clients When the PRIORITY_UPDATE frame applies to a request stream, clients
SHOULD provide a Prioritized Stream ID that refers to a stream in the SHOULD provide a Prioritized Stream ID that refers to a stream in the
skipping to change at page 14, line 39 skipping to change at page 14, line 37
discard frames where the Prioritized Stream ID refers to a stream in discard frames where the Prioritized Stream ID refers to a stream in
the "closed" state. Clients MUST NOT provide a Prioritized Stream ID the "closed" state. Clients MUST NOT provide a Prioritized Stream ID
that refers to a push stream in the "idle" state. Servers that that refers to a push stream in the "idle" state. Servers that
receive a PRIORITY_UPDATE for a push stream in the "idle" state MUST receive a PRIORITY_UPDATE for a push stream in the "idle" state MUST
respond with a connection error of type PROTOCOL_ERROR. respond with a connection error of type PROTOCOL_ERROR.
If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID
of 0x0, the recipient MUST respond with a connection error of type of 0x0, the recipient MUST respond with a connection error of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
If a client receives a PRIORITY_UPDATE frame, it MUST respond with a Servers MUST NOT send PRIORITY_UPDATE frames. If a client receives a
connection error of type PROTOCOL_ERROR. PRIORITY_UPDATE frame, it MUST respond with a connection error of
type PROTOCOL_ERROR.
7.2. HTTP/3 PRIORITY_UPDATE Frame 7.2. HTTP/3 PRIORITY_UPDATE Frame
The HTTP/3 PRIORITY_UPDATE frame (type=0xF0700 or 0xF0701) is used by The HTTP/3 PRIORITY_UPDATE frame (type=0xF0700 or 0xF0701) is used by
clients to signal the initial priority of a response, or to clients to signal the initial priority of a response, or to
reprioritize a response or push stream. It carries the identifier of reprioritize a response or push stream. It carries the identifier of
the element that is being prioritized, and the updated priority in the element that is being prioritized and the updated priority in
ASCII text, using the same representation as that of the Priority ASCII text that uses the same representation as that of the Priority
header field value. PRIORITY_UPDATE with a frame type of 0xF0700 is header field value. PRIORITY_UPDATE with a frame type of 0xF0700 is
used for request streams, while PRIORITY_UPDATE with a frame type of used for request streams, while PRIORITY_UPDATE with a frame type of
0xF0701 is used for push streams. 0xF0701 is used for push streams.
The PRIORITY_UPDATE frame MUST be sent on the client control stream The PRIORITY_UPDATE frame MUST be sent on the client control stream
(see Section 6.2.1 of [HTTP3]). Receiving a PRIORITY_UPDATE frame on (see Section 6.2.1 of [HTTP3]). Receiving a PRIORITY_UPDATE frame on
a stream other than the client control stream MUST be treated as a a stream other than the client control stream MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED. connection error of type H3_FRAME_UNEXPECTED.
HTTP/3 PRIORITY_UPDATE Frame { HTTP/3 PRIORITY_UPDATE Frame {
skipping to change at page 15, line 46 skipping to change at page 15, line 46
mandatory because HTTP/3 implementations might have practical mandatory because HTTP/3 implementations might have practical
barriers to determining the active stream concurrency limit that is barriers to determining the active stream concurrency limit that is
applied by the QUIC layer. applied by the QUIC layer.
The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference
a promised push stream. If a server receives a PRIORITY_UPDATE a promised push stream. If a server receives a PRIORITY_UPDATE
(type=0xF0701) with a Push ID that is greater than the maximum Push (type=0xF0701) with a Push ID that is greater than the maximum Push
ID or which has not yet been promised, this MUST be treated as a ID or which has not yet been promised, this MUST be treated as a
connection error of type H3_ID_ERROR. connection error of type H3_ID_ERROR.
PRIORITY_UPDATE frames of either type are only sent by clients. If a Servers MUST NOT send PRIORITY_UPDATE frames of either type. If a
client receives a PRIORITY_UPDATE frame, this MUST be treated as a client receives a PRIORITY_UPDATE frame, this MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED. connection error of type H3_FRAME_UNEXPECTED.
8. Merging Client- and Server-Driven Priority Parameters 8. Merging Client- and Server-Driven Priority Parameters
It is not always the case that the client has the best understanding It is not always the case that the client has the best understanding
of how the HTTP responses deserve to be prioritized. The server of how the HTTP responses deserve to be prioritized. The server
might have additional information that can be combined with the might have additional information that can be combined with the
client's indicated priority in order to improve the prioritization of client's indicated priority in order to improve the prioritization of
the response. For example, use of an HTML document might depend the response. For example, use of an HTML document might depend
skipping to change at page 16, line 23 skipping to change at page 16, line 23
is typically best known to the server. Or, a server that receives is typically best known to the server. Or, a server that receives
requests for a font [RFC8081] and images with the same urgency might requests for a font [RFC8081] and images with the same urgency might
give higher precedence to the font, so that a visual client can give higher precedence to the font, so that a visual client can
render textual information at an early moment. render textual information at an early moment.
An origin can use the Priority response header field to indicate its An origin can use the Priority response header field to indicate its
view on how an HTTP response should be prioritized. An intermediary view on how an HTTP response should be prioritized. An intermediary
that forwards an HTTP response can use the priority parameters found that forwards an HTTP response can use the priority parameters found
in the Priority response header field, in combination with the client in the Priority response header field, in combination with the client
Priority request header field, as input to its prioritization Priority request header field, as input to its prioritization
process. No guidance is provided for merging priorities, this is process. No guidance is provided for merging priorities; this is
left as an implementation decision. left as an implementation decision.
Absence of a priority parameter in an HTTP response indicates the Absence of a priority parameter in an HTTP response indicates the
server's disinterest in changing the client-provided value. This is server's disinterest in changing the client-provided value. This is
different from the the request header field, in which omission of a different from the request header field, in which omission of a
priority parameter implies the use of their default values (see priority parameter implies the use of their default values (see
Section 4). Section 4).
As a non-normative example, when the client sends an HTTP request As a non-normative example, when the client sends an HTTP request
with the urgency parameter set to 5 and the incremental parameter set with the urgency parameter set to 5 and the incremental parameter set
to true to true
:method = GET :method = GET
:scheme = https :scheme = https
:authority = example.net :authority = example.net
skipping to change at page 17, line 17 skipping to change at page 17, line 17
A client MAY use priority values to make local processing or A client MAY use priority values to make local processing or
scheduling choices about the requests it initiates. scheduling choices about the requests it initiates.
10. Server Scheduling 10. Server Scheduling
It is generally beneficial for an HTTP server to send all responses It is generally beneficial for an HTTP server to send all responses
as early as possible. However, when serving multiple requests on a as early as possible. However, when serving multiple requests on a
single connection, there could be competition between the requests single connection, there could be competition between the requests
for resources such as connection bandwidth. This section describes for resources such as connection bandwidth. This section describes
considerations regarding how servers can schedule the order in which considerations regarding how servers can schedule the order in which
the competing responses will be sent, when such competition exists. the competing responses will be sent when such competition exists.
Server scheduling is a prioritization process based on many inputs, Server scheduling is a prioritization process based on many inputs,
with priority signals being only one form of input. Factors such as with priority signals being only one form of input. Factors such as
implementation choices or deployment environment also play a role. implementation choices or deployment environment also play a role.
Any given connection is likely to have many dynamic permutations. Any given connection is likely to have many dynamic permutations.
For these reasons, there is no unilateral perfect scheduler. This For these reasons, it is not possible to describe a universal
document provides some basic, non-exhaustive, recommendations for how scheduling algorithm. This document provides some basic, non-
servers might act on priority parameters. It does not describe in exhaustive recommendations for how servers might act on priority
detail how servers might combine priority signals with other factors. parameters. It does not describe in detail how servers might combine
Endpoints cannot depend on particular treatment based on priority priority signals with other factors. Endpoints cannot depend on
signals. Expressing priority is only a suggestion. particular treatment based on priority signals. Expressing priority
is only a suggestion.
It is RECOMMENDED that, when possible, servers respect the urgency It is RECOMMENDED that, when possible, servers respect the urgency
parameter (Section 4.1), sending higher urgency responses before parameter (Section 4.1), sending higher urgency responses before
lower urgency responses. lower urgency responses.
The incremental parameter indicates how a client processes response The incremental parameter indicates how a client processes response
bytes as they arrive. It is RECOMMENDED that, when possible, servers bytes as they arrive. It is RECOMMENDED that, when possible, servers
respect the incremental parameter (Section 4.2). respect the incremental parameter (Section 4.2).
Non-incremental responses of the same urgency SHOULD be served by Non-incremental responses of the same urgency SHOULD be served by
prioritizing bandwidth allocation in ascending order of the stream prioritizing bandwidth allocation in ascending order of the stream
ID, which corresponds to the order in which clients make requests. ID, which corresponds to the order in which clients make requests.
Doing so ensures that clients can use request ordering to influence Doing so ensures that clients can use request ordering to influence
response order. response order.
Incremental responses of the same urgency SHOULD be served by sharing Incremental responses of the same urgency SHOULD be served by sharing
bandwidth amongst them. Incremental resources are used as parts, or bandwidth among them. Payload of incremental responses are used in
chunks, of the response payload are received. A client might benefit parts, or chunks, as they are received. A client might benefit more
more from receiving a portion of all these resources rather than the from receiving a portion of all these resources rather than the
entirety of a single resource. How large a portion of the resource entirety of a single resource. How large a portion of the resource
is needed to be useful in improving performance varies. Some is needed to be useful in improving performance varies. Some
resource types place critical elements early, others can use resource types place critical elements early; others can use
information progressively. This scheme provides no explicit mandate information progressively. This scheme provides no explicit mandate
about how a server should use size, type or any other input to decide about how a server should use size, type or any other input to decide
how to prioritize. how to prioritize.
There can be scenarios where a server will need to schedule multiple There can be scenarios where a server will need to schedule multiple
incremental and non-incremental responses at the same urgency level. incremental and non-incremental responses at the same urgency level.
Strictly abiding the scheduling guidance based on urgency and request Strictly abiding the scheduling guidance based on urgency and request
generation order might lead to sub-optimal results at the client, as generation order might lead to suboptimal results at the client, as
early non-incremental responses might prevent serving of incremental early non-incremental responses might prevent serving of incremental
responses issued later. The following are examples of such responses issued later. The following are examples of such
challenges. challenges.
1. At the same urgency level, a non-incremental request for a large 1. At the same urgency level, a non-incremental request for a large
resource followed by an incremental request for a small resource. resource followed by an incremental request for a small resource.
2. At the same urgency level, an incremental request of 2. At the same urgency level, an incremental request of
indeterminate length followed by a non-incremental large indeterminate length followed by a non-incremental large
resource. resource.
skipping to change at page 20, line 41 skipping to change at page 20, line 41
13.1. Coalescing Intermediaries 13.1. Coalescing Intermediaries
When an intermediary coalesces HTTP requests coming from multiple When an intermediary coalesces HTTP requests coming from multiple
clients into one HTTP/2 or HTTP/3 connection going to the backend clients into one HTTP/2 or HTTP/3 connection going to the backend
server, requests that originate from one client might carry signals server, requests that originate from one client might carry signals
indicating higher priority than those coming from others. indicating higher priority than those coming from others.
It is sometimes beneficial for the server running behind an It is sometimes beneficial for the server running behind an
intermediary to obey Priority header field values. As an example, a intermediary to obey Priority header field values. As an example, a
resource-constrained server might defer the transmission of software resource-constrained server might defer the transmission of software
update files that would have the background urgency being associated. update files that have the background urgency. However, in the worst
However, in the worst case, the asymmetry between the priority case, the asymmetry between the priority declared by multiple clients
declared by multiple clients might cause responses going to one user might cause responses going to one user agent to be delayed totally
agent to be delayed totally after those going to another. after those going to another.
In order to mitigate this fairness problem, a server could use In order to mitigate this fairness problem, a server could use
knowledge about the intermediary as another input in its knowledge about the intermediary as another input in its
prioritization decisions. For instance, if a server knows the prioritization decisions. For instance, if a server knows the
intermediary is coalescing requests, then it could avoid serving the intermediary is coalescing requests, then it could avoid serving the
responses in their entirety and instead distribute bandwidth (for responses in their entirety and instead distribute bandwidth (for
example, in a round-robin manner). This can work if the constrained example, in a round-robin manner). This can work if the constrained
resource is network capacity between the intermediary and the user resource is network capacity between the intermediary and the user
agent, as the intermediary buffers responses and forwards the chunks agent, as the intermediary buffers responses and forwards the chunks
based on the prioritization scheme it implements. based on the prioritization scheme it implements.
skipping to change at page 22, line 6 skipping to change at page 22, line 6
connections that only convey background priority responses such as connections that only convey background priority responses such as
software update images. Doing so improves responsiveness of other software update images. Doing so improves responsiveness of other
connections at the cost of delaying the delivery of updates. connections at the cost of delaying the delivery of updates.
14. Why use an End-to-End Header Field? 14. Why use an End-to-End Header Field?
In contrast to the prioritization scheme of HTTP/2 that uses a hop- In contrast to the prioritization scheme of HTTP/2 that uses a hop-
by-hop frame, the Priority header field is defined as end-to-end. by-hop frame, the Priority header field is defined as end-to-end.
The way that a client processes a response is a property associated The way that a client processes a response is a property associated
with the client generating that request. Not that of an with the client generating that request, not that of an intermediary.
intermediary. Therefore, it is an end-to-end property. How these Therefore, it is an end-to-end property. How these end-to-end
end-to-end properties carried by the Priority header field affect the properties carried by the Priority header field affect the
prioritization between the responses that share a connection is a prioritization between the responses that share a connection is a
hop-by-hop issue. hop-by-hop issue.
Having the Priority header field defined as end-to-end is important Having the Priority header field defined as end-to-end is important
for caching intermediaries. Such intermediaries can cache the value for caching intermediaries. Such intermediaries can cache the value
of the Priority header field along with the response, and utilize the of the Priority header field along with the response and utilize the
value of the cached header field when serving the cached response, value of the cached header field when serving the cached response,
only because the header field is defined as end-to-end rather than only because the header field is defined as end-to-end rather than
hop-by-hop. hop-by-hop.
15. Security Considerations 15. Security Considerations
Section 7 describes considerations for server buffering of Section 7 describes considerations for server buffering of
PRIORITY_UPDATE frames. PRIORITY_UPDATE frames.
Section 10 presents examples where servers that prioritize responses Section 10 presents examples where servers that prioritize responses
in a certain way might be starved of the ability to transmit payload. in a certain way might be starved of the ability to transmit payload.
The security considerations from [STRUCTURED-FIELDS] apply to The security considerations from [STRUCTURED-FIELDS] apply to
processing of priority parameters defined in Section 4. processing of priority parameters defined in Section 4.
16. IANA Considerations 16. IANA Considerations
This specification registers the following entry in the the Hypertext This specification registers the following entry in the Hypertext
Transfer Protocol (HTTP) Field Name Registry established by [HTTP]: Transfer Protocol (HTTP) Field Name Registry established by [HTTP]:
Field name: Priority Field name: Priority
Status: permanent Status: permanent
Specification document(s): This document Specification document(s): This document
This specification registers the following entry in the HTTP/2 This specification registers the following entry in the HTTP/2
Settings registry established by [RFC7540]: Settings registry established by [RFC7540]:
skipping to change at page 25, line 20 skipping to change at page 25, line 20
priority-setting-00>. priority-setting-00>.
[MARX] Marx, R., Decker, T.D., Quax, P., and W. Lamotte, "Of the [MARX] Marx, R., Decker, T.D., Quax, P., and W. Lamotte, "Of the
Utmost Importance: Resource Prioritization in HTTP/3 over Utmost Importance: Resource Prioritization in HTTP/3 over
QUIC", DOI 10.5220/0008191701300143, QUIC", DOI 10.5220/0008191701300143,
SCITEPRESS Proceedings of the 15th International SCITEPRESS Proceedings of the 15th International
Conference on Web Information Systems and Technologies Conference on Web Information Systems and Technologies
(pages 130-143), September 2019, (pages 130-143), September 2019,
<https://www.doi.org/10.5220/0008191701300143>. <https://www.doi.org/10.5220/0008191701300143>.
[MEENAN] Meenan, P., "Better HTTP/2 Prioritization for a Faster
Web", 14 May 2019, <https://blog.cloudflare.com/better-
http-2-prioritization-for-a-faster-web/>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/rfc/rfc9002>. May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081, [RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081,
DOI 10.17487/RFC8081, February 2017, DOI 10.17487/RFC8081, February 2017,
<https://www.rfc-editor.org/rfc/rfc8081>. <https://www.rfc-editor.org/rfc/rfc8081>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Roy Fielding presented the idea of using a header field for Roy Fielding presented the idea of using a header field for
representing priorities in http://tools.ietf.org/agenda/83/slides/ representing priorities in
slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/ https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf
slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3- (https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf).
prioritization-proposal (https://github.com/pmeenan/http3- In https://github.com/pmeenan/http3-prioritization-proposal
prioritization-proposal), Patrick Meenan advocated for representing (https://github.com/pmeenan/http3-prioritization-proposal), Patrick
the priorities using a tuple of urgency and concurrency. The ability Meenan advocated for representing the priorities using a tuple of
to disable HTTP/2 prioritization is inspired by urgency and concurrency. The ability to disable HTTP/2
[I-D.lassey-priority-setting], authored by Brad Lassey and Lucas prioritization is inspired by [I-D.lassey-priority-setting], authored
Pardue, with modifications based on feedback that was not by Brad Lassey and Lucas Pardue, with modifications based on feedback
incorporated into an update to that document. that was not incorporated into an update to that document.
The motivation for defining an alternative to HTTP/2 priorities is The motivation for defining an alternative to HTTP/2 priorities is
drawn from discussion within the broad HTTP community. Special drawn from discussion within the broad HTTP community. Special
thanks to Roberto Peon, Martin Thomson and Netflix for text that was thanks to Roberto Peon, Martin Thomson and Netflix for text that was
incorporated explicitly in this document. incorporated explicitly in this document.
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
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
B.1. Since draft-ietf-httpbis-priority-10 B.1. Since draft-ietf-httpbis-priority-11
* Changes to address Last Call/IESG feedback
B.2. Since draft-ietf-httpbis-priority-10
* Editorial changes * Editorial changes
* Add clearer IANA instructions for Priority Parameter initial * Add clearer IANA instructions for Priority Parameter initial
population population
B.2. Since draft-ietf-httpbis-priority-09 B.3. Since draft-ietf-httpbis-priority-09
* Editorial changes * Editorial changes
B.3. Since draft-ietf-httpbis-priority-08 B.4. Since draft-ietf-httpbis-priority-08
* Changelog fixups * Changelog fixups
B.4. Since draft-ietf-httpbis-priority-07 B.5. 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.5. Since draft-ietf-httpbis-priority-06 B.6. 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.6. Since draft-ietf-httpbis-priority-05 B.7. 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.7. Since draft-ietf-httpbis-priority-04 B.8. 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.8. Since draft-ietf-httpbis-priority-03 B.9. 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.9. Since draft-ietf-httpbis-priority-02 B.10. 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 Priority Parameters registry (#1371) * Add a Priority Parameters registry (#1371)
B.10. Since draft-ietf-httpbis-priority-01 B.11. 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.11. Since draft-ietf-httpbis-priority-00 B.12. 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.12. Since draft-kazuho-httpbis-priority-04 B.13. 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.13. Since draft-kazuho-httpbis-priority-03 B.14. 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.14. Since draft-kazuho-httpbis-priority-02 B.15. 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.15. Since draft-kazuho-httpbis-priority-01 B.16. Since draft-kazuho-httpbis-priority-01
* Explain how reprioritization might be supported. * Explain how reprioritization might be supported.
B.16. Since draft-kazuho-httpbis-priority-00 B.17. 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. 52 change blocks. 
130 lines changed or deleted 137 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/