draft-ietf-httpbis-priority-02.txt   draft-ietf-httpbis-priority-03.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: April 4, 2021 Cloudflare Expires: 15 July 2021 Cloudflare
October 01, 2020 11 January 2021
Extensible Prioritization Scheme for HTTP Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-02 draft-ietf-httpbis-priority-03
Abstract Abstract
This document describes a scheme for prioritizing HTTP responses. This document describes a scheme for prioritizing HTTP responses.
This scheme expresses the priority of each HTTP response using This scheme expresses the priority of each HTTP response using
absolute values, rather than as a relative relationship between a absolute values, rather than as a relative relationship between a
group of HTTP responses. group of HTTP responses.
This document defines the Priority header field for communicating the This document defines the Priority header field for communicating the
initial priority in an HTTP version-independent manner, as well as initial priority in an HTTP version-independent manner, as well as
HTTP/2 and HTTP/3 frames for reprioritizing the responses. These HTTP/2 and HTTP/3 frames for reprioritizing the responses. These
share a common format structure that is designed to provide future share a common format structure that is designed to provide future
extensibility. extensibility.
Note to Readers Note to Readers
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. https://lists.w3.org/Archives/Public/ietf-http-wg/
(https://lists.w3.org/Archives/Public/ietf-http-wg/).
Working Group information can be found at https://httpwg.org/ [2]; Working Group information can be found at https://httpwg.org/
source code and issues list for this draft can be found at (https://httpwg.org/); source code and issues list for this draft can
https://github.com/httpwg/http-extensions/labels/priorities [3]. be found at https://github.com/httpwg/http-extensions/labels/
priorities (https://github.com/httpwg/http-extensions/labels/
priorities).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 4, 2021. This Internet-Draft will expire on 15 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Motivation for Replacing HTTP/2 Priorities . . . . . . . . . 4 2. Motivation for Replacing HTTP/2 Priorities . . . . . . . . . 4
2.1. Disabling HTTP/2 Priorities . . . . . . . . . . . . . . . 5 2.1. Disabling HTTP/2 Priorities . . . . . . . . . . . . . . . 5
3. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 6 3. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 6
3.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8 3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8
4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 8 3.3.1. Registration . . . . . . . . . . . . . . . . . . . . 9
5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 9 4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 9
6. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 9 5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 10
6.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 10 6. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 10
6.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 11 6.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 11
7. Merging Client- and Server-Driven Parameters . . . . . . . . 12 6.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 12
8. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 13 7. Merging Client- and Server-Driven Parameters . . . . . . . . 13
9. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 13 8. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 14
10. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 15 10. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 15 10.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 16
10.3. Intentional Introduction of Unfairness . . . . . . . . . 16 10.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 17
11. Why use an End-to-End Header Field? . . . . . . . . . . . . . 16 10.3. Intentional Introduction of Unfairness . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Why use an End-to-End Header Field? . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
B.1. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 20 B.1. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 22
B.2. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 20 B.2. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 22
B.3. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 21 B.3. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 22
B.4. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 21 B.4. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 22
B.5. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 21 B.5. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 23
B.6. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 21 B.6. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 23
B.7. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 21 B.7. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 B.8. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
It is common for an HTTP ([RFC7230]) resource representation to have It is common for an HTTP ([RFC7230]) resource representation 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, leading to further retrieval requests. Meanwhile, representation, leading to further retrieval requests. Meanwhile,
the nature of the relationship determines whether the client is the nature of the relationship determines whether the client is
blocked from continuing to process locally available resources. For blocked from continuing to process locally available resources. For
example, visual rendering of an HTML document could be blocked by the example, visual rendering of an HTML document could be blocked by the
skipping to change at page 8, line 20 skipping to change at page 8, line 37
"true". "true".
:method = GET :method = GET
:scheme = https :scheme = https
:authority = example.net :authority = example.net
:path = /image.jpg :path = /image.jpg
priority = u=5, i priority = u=5, i
3.3. Defining New Parameters 3.3. Defining New Parameters
When attempting to extend priorities, care must be taken to ensure When attempting to define new parameters, care must be taken so that
any use of existing parameters leaves them either unchanged or they do not adversely interfere with prioritization performed by
modified in a way that is backwards compatible for peers that are existing endpoints or intermediaries that do not understand the newly
unaware of the extended meaning. defined parameter. Since unknown parameters are ignored, new
parameters should not change the interpretation of or modify the
predefined parameters in a way that is not backwards compatible or
fallback safe.
For example, if there is a need to provide more granularity than For example, if there is a need to provide more granularity than
eight urgency levels, it would be possible to subdivide the range eight urgency levels, it would be possible to subdivide the range
using an additional parameter. Implementations that do not recognize using an additional parameter. Implementations that do not recognize
the parameter can safely continue to use the less granular eight the parameter can safely continue to use the less granular eight
levels. levels.
Alternatively, the urgency can be augmented. For example, a Alternatively, the urgency can be augmented. For example, a
graphical user agent could send a "visible" parameter to indicate if graphical user agent could send a "visible" parameter to indicate if
the resource being requested is within the viewport. the resource being requested is within the viewport.
Generic parameters are preferred over vendor-specific, application-
specific or deployment-specific values. If a generic value cannot be
agreed upon in the community, the parameter's name should be
correspondingly specific (e.g., with a prefix that identifies the
vendor, application or deployment).
3.3.1. Registration
New Priority parameters can be defined by registering them in the
HTTP Priority Parameters Registry.
Registration requests are reviewed and approved by a Designated
Expert, as per [RFC8126], Section 4.5. A specification document is
appreciated, but not required.
The Expert(s) should consider the following factors when evaluating
requests:
* Community feedback
* If the parameters are sufficiently well-defined and adhere to the
guidance provided in Section 3.3.
Registration requests should use the following template:
* Name: [a name for the Priority Parameter that matches key]
* Description: [a description of the parameter semantics and value]
* Reference: [to a specification defining this parameter]
See the registry at https://iana.org/assignments/http-priority
(https://iana.org/assignments/http-priority) for details on where to
send registration requests.
4. The Priority HTTP Header Field 4. The Priority HTTP Header Field
The Priority HTTP header field can appear in requests and responses. The Priority HTTP header field can appear in requests and responses.
A client uses it to specify the priority of the response. A server A client uses it to specify the priority of the response. A server
uses it to inform the client that the priority was overwritten. An uses it to inform the client that the priority was overwritten. An
intermediary can use the Priority information from client requests intermediary can use the Priority information from client requests
and server responses to correct or amend the precedence to suit it and server responses to correct or amend the precedence to suit it
(see Section 7). (see Section 7).
The Priority header field is an end-to-end signal of the request The Priority header field is an end-to-end signal of the request
skipping to change at page 9, line 46 skipping to change at page 11, line 6
of the Priority header field. of the Priority header field.
A PRIORITY_UPDATE frame communicates a complete set of all parameters A PRIORITY_UPDATE frame communicates a complete set of all parameters
in the Priority Field Value field. Omitting a parameter is a signal in the Priority Field Value field. Omitting a parameter is a signal
to use the parameter's default value. Failure to parse the Priority to use the parameter's default value. Failure to parse the Priority
Field Value MUST be treated as a connection error. In HTTP/2 the Field Value MUST be treated as a connection error. In HTTP/2 the
error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type
H3_FRAME_ERROR. H3_FRAME_ERROR.
A client MAY send a PRIORITY_UPDATE frame before the stream that it A client MAY send a PRIORITY_UPDATE frame before the stream that it
references is open. Furthermore, HTTP/3 offers no guaranteed references is open (except for HTTP/2 push streams; see Section 6.1).
ordering across streams, which could cause the frame to be received Furthermore, HTTP/3 offers no guaranteed ordering across streams,
earlier than intended. Either case leads to a race condition where a which could cause the frame to be received earlier than intended.
server receives a PRIORITY_UPDATE frame that references a request Either case leads to a race condition where a server receives a
stream that is yet to be opened. To solve this condition, for the PRIORITY_UPDATE frame that references a request stream that is yet to
purposes of scheduling, the most recently received PRIORITY_UPDATE be opened. To solve this condition, for the purposes of scheduling,
frame can be considered as the most up-to-date information that the most recently received PRIORITY_UPDATE frame can be considered as
overrides any other signal. Servers SHOULD buffer the most recently the most up-to-date information that overrides any other signal.
received PRIORITY_UPDATE frame and apply it once the referenced Servers SHOULD buffer the most recently received PRIORITY_UPDATE
stream is opened. Holding PRIORITY_UPDATE frames for each stream frame and apply it once the referenced stream is opened. Holding
requires server resources, which can can be bound by local PRIORITY_UPDATE frames for each stream requires server resources,
implementation policy. (TODO: consider resolving #1261, and adding which can can be bound by local implementation policy. Although
more text about bounds). Although there is no limit to the number there is no limit to the number of PRIORITY_UPDATES that can be sent,
PRIORITY_UPDATES that can be sent, storing only the most recently storing only the most recently received frame limits resource
received frame limits resource commitment. commitment.
6.1. HTTP/2 PRIORITY_UPDATE Frame 6.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 ([RFC7540], Section 4.1) in the The Stream Identifier field ([RFC7540], Section 4.1) in the
skipping to change at page 10, line 35 skipping to change at page 11, line 43
as a connection error of type PROTOCOL_ERROR. as a connection error of type PROTOCOL_ERROR.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+ +---------------------------------------------------------------+
|R| Prioritized Stream ID (31) | |R| 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 PRIORITY_UPDATE frame payload has the following fields: The PRIORITY_UPDATE frame payload has the following fields:
R: A reserved 1-bit field. The semantics of this bit are undefined, R: A reserved 1-bit field. The semantics of this bit are undefined,
and the bit MUST remain unset (0x0) when sending and MUST be and the bit MUST remain unset (0x0) when sending and 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. encoded using Structured Fields.
The Prioritized Stream ID MUST be within the stream limit. If a When the PRIORITY_UPDATE frame applies to a request stream, clients
server receives a PRIORITY_UPDATE with a Prioritized Stream ID that SHOULD provide a Prioritized Stream ID that refers to a stream in the
is beyond the stream limits, this SHOULD be treated as a connection "open", "half-closed (local)", or "idle" state. Servers can discard
error of type PROTOCOL_ERROR. frames where the Prioritized Stream ID refers to a stream in the
"half-closed (local)" or "closed" state. The number of streams which
have been prioritized but remain in the "idle" state plus the number
of active streams (those in the "open" or either "half-closed" state;
see section 5.1.2 of [RFC7540]) MUST NOT exceed the value of the
SETTINGS_MAX_CONCURRENT_STREAMS parameter. Servers that receive such
a PRIORITY_UPDATE MUST respond with a connection error of type
PROTOCOL_ERROR.
When the PRIORITY_UPDATE frame applies to a push stream, clients
SHOULD provide a Prioritized Stream ID that refers to a stream in the
"reserved (remote)" or "half-closed (local)" state. Servers can
discard frames where the Prioritized Stream ID refers to a stream in
the "closed" state. Clients MUST NOT provide a Prioritized Stream ID
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
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 If a client receives a PRIORITY_UPDATE frame, it MUST respond with a
connection error of type PROTOCOL_ERROR. connection error of type PROTOCOL_ERROR.
6.2. HTTP/3 PRIORITY_UPDATE Frame 6.2. HTTP/3 PRIORITY_UPDATE Frame
skipping to change at page 11, line 37 skipping to change at page 13, line 12
frame on a stream other than the client control stream MUST be frame on a stream other than the client control stream MUST be
treated as a connection error of type H3_FRAME_UNEXPECTED. treated as a connection error of type H3_FRAME_UNEXPECTED.
HTTP/3 PRIORITY_UPDATE Frame { HTTP/3 PRIORITY_UPDATE Frame {
Type (i) = 0xF0700..0xF0701, Type (i) = 0xF0700..0xF0701,
Length (i), Length (i),
Prioritized Element ID (i), Prioritized Element ID (i),
Priority Field Value (..), Priority Field Value (..),
} }
Figure 2: HTTP/3 PRIORITY_UPDATE Frame Figure 2: HTTP/3 PRIORITY_UPDATE Frame
The PRIORITY_UPDATE frame payload has the following fields: The PRIORITY_UPDATE frame payload has the following fields:
Prioritized Element ID: The stream ID or push ID that is the target Prioritized Element ID: The stream ID or push ID that is the target
of the priority update. 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. encoded using Structured Fields.
The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST
skipping to change at page 14, line 35 skipping to change at page 16, line 5
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.
It is RECOMMENDED that servers avoid such starvation where possible. It is RECOMMENDED that servers avoid such starvation where possible.
The method to do so is an implementation decision. For example, a The method to do so is an implementation decision. For example, a
server might pre-emptively send responses of a particular incremental server might pre-emptively send responses of a particular incremental
type based on other information such as content size. type based on other information such as content size.
Optimal scheduling of server push is difficult, especially when
pushed resources contend with active concurrent requests. Servers
can consider many factors when scheduling, such as the type or size
of resource being pushed, the priority of the request that triggered
the push, the count of active concurrent responses, the priority of
other active concurrent responses, etc. There is no general guidance
on the best way to apply these. A server that is too simple could
easily push at too high a priority and block client requests, or push
at too low a priority and delay the response, negating intended goals
of server push.
Priority signals are a factor for server push scheduling. The
concept of parameter value defaults applies slightly differently
because there is no explicit client-signalled initial priority. A
server can apply priority signals provided in an origin response; see
the merging guidance given in Section 7. In the absence of origin
signals, applying default parameter values could be suboptimal. How
ever a server decides to schedule a pushed response, it can signal
the intended priority to the client by including the Priority field
in a PUSH_PROMISE or HEADERS frame.
10. Fairness 10. Fairness
As a general guideline, a server SHOULD NOT use priority information As a general guideline, a server SHOULD NOT use priority information
for making schedule decisions across multiple connections, unless it for making schedule decisions across multiple connections, unless it
knows that those connections originate from the same client. Due to knows that those connections originate from the same client. Due to
this, priority information conveyed over a non-coalesced HTTP this, priority information conveyed over a non-coalesced HTTP
connection (e.g., HTTP/1.1) might go unused. connection (e.g., HTTP/1.1) might go unused.
The remainder of this section discusses scenarios where unfairness is The remainder of this section discusses scenarios where unfairness is
problematic and presents possible mitigations, or where unfairness is problematic and presents possible mitigations, or where unfairness is
desirable. desirable.
TODO: Discuss if we should add a signal that mitigates this issue.
For example, we might add a SETTINGS parameter that indicates the
next hop that the connection is NOT coalesced (see
https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99).
10.1. Coalescing Intermediaries 10.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 have higher server, requests that originate from one client might have higher
precedence than those coming from others. precedence 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 to the value of the Priority header field. As intermediary to obey to the value of the Priority header field. As
an example, a resource-constrained server might defer the an example, a resource-constrained server might defer the
skipping to change at page 15, line 34 skipping to change at page 17, line 18
intermediary is coalescing requests, then it could serve the intermediary is coalescing requests, then it could serve the
responses in round-robin manner. This can work if the constrained responses in 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.
A server can determine if a request came from an intermediary through A server can determine if a request came from an intermediary through
configuration, or by consulting if that request contains one of the configuration, or by consulting if that request contains one of the
following header fields: following header fields:
o Forwarded, X-Forwarded-For ([RFC7239]) * Forwarded, X-Forwarded-For ([RFC7239])
o Via ([RFC7230], Section 5.7.1) * Via ([RFC7230], Section 5.7.1)
10.2. HTTP/1.x Back Ends 10.2. HTTP/1.x Back Ends
It is common for CDN infrastructure to support different HTTP It is common for CDN infrastructure to support different HTTP
versions on the front end and back end. For instance, the client- versions on the front end and back end. For instance, the client-
facing edge might support HTTP/2 and HTTP/3 while communication to facing edge might support HTTP/2 and HTTP/3 while communication to
back end servers is done using HTTP/1.1. Unlike with connection back end servers is done using HTTP/1.1. Unlike with connection
coalescing, the CDN will "de-mux" requests into discrete connections coalescing, the CDN will "de-mux" requests into discrete connections
to the back end. As HTTP/1.1 and older do not provide a way to to the back end. As HTTP/1.1 and older do not provide a way to
concurrently transmit multiple responses, there is no immediate concurrently transmit multiple responses, there is no immediate
skipping to change at page 18, line 28 skipping to change at page 20, line 11
This specification registers the following entries in the HTTP/3 This specification registers the following entries in the HTTP/3
Frame Type registry established by [I-D.ietf-quic-http]: Frame Type registry established by [I-D.ietf-quic-http]:
Frame Type: PRIORITY_UPDATE Frame Type: PRIORITY_UPDATE
Code: 0xF0700 and 0xF0701 Code: 0xF0700 and 0xF0701
Specification: This document Specification: This document
Upon publication, please create the HTTP Priority Parameters registry
at https://iana.org/assignments/http-priority
(https://iana.org/assignments/http-priority) and populate it with the
types defined in Section 3; see Section 3.3.1 for its associated
procedures.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-quic-http] [I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-31 (work in progress), (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
September 2020. quic-http-33, 15 December 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-quic-http-33.txt>.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-31 (work and Secure Transport", Work in Progress, Internet-Draft,
in progress), September 2020. draft-ietf-quic-transport-33, 13 December 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-33.txt>.
[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/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[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/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[STRUCTURED-FIELDS] [STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", draft-ietf-httpbis-header-structure-19 (work in HTTP", Work in Progress, Internet-Draft, draft-ietf-
progress), June 2020. httpbis-header-structure-19, 3 June 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-httpbis-
header-structure-19.txt>.
14.2. Informative References 14.2. Informative References
[CVE-2019-9513] [CVE-2019-9513]
Common Vulnerabilities and Exposures, "CVE-2019-9513", Common Vulnerabilities and Exposures, "CVE-2019-9513", 1
March 2019, <https://cve.mitre.org/cgi-bin/ March 2019, <https://cve.mitre.org/cgi-bin/
cvename.cgi?name=CVE-2019-9513>. cvename.cgi?name=CVE-2019-9513>.
[I-D.lassey-priority-setting] [I-D.lassey-priority-setting]
Lassey, B. and L. Pardue, "Declaring Support for HTTP/2 Lassey, B. and L. Pardue, "Declaring Support for HTTP/2
Priorities", draft-lassey-priority-setting-00 (work in Priorities", Work in Progress, Internet-Draft, draft-
progress), July 2019. lassey-priority-setting-00, 25 July 2019,
<http://www.ietf.org/internet-drafts/draft-lassey-
priority-setting-00.txt>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014, RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/info/rfc7239>. <https://www.rfc-editor.org/info/rfc7239>.
[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/info/rfc8081>. <https://www.rfc-editor.org/info/rfc8081>.
14.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] https://httpwg.org/
[3] https://github.com/httpwg/http-extensions/labels/priorities
[4] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf
[5] https://github.com/pmeenan/http3-prioritization-proposal
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 http://tools.ietf.org/agenda/83/slides/
slides-83-httpbis-5.pdf [4]. In https://github.com/pmeenan/http3- slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/
prioritization-proposal [5], Patrick Meenan advocates for slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3-
representing the priorities using a tuple of urgency and concurrency. prioritization-proposal (https://github.com/pmeenan/http3-
The ability to deprecate HTTP/2 prioritization is based on prioritization-proposal), Patrick Meenan advocates for representing
the priorities using a tuple of urgency and concurrency. The ability
to deprecate HTTP/2 prioritization is based on
[I-D.lassey-priority-setting], authored by Brad Lassey and Lucas [I-D.lassey-priority-setting], authored by Brad Lassey and Lucas
Pardue, with modifications based on feedback that was not Pardue, with modifications based on feedback that was not
incorporated into an update to that document. 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.
Appendix B. Change Log Appendix B. Change Log
B.1. Since draft-ietf-httpbis-priority-01 B.1. Since draft-ietf-httpbis-priority-01
o PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, * Describe considerations for server push prioritisation (#1056,
#1345)
* Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261,
#1344)
* Add a Parameters registry (#1371)
B.2. Since draft-ietf-httpbis-priority-01
* PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,
#1271) #1271)
o Add section to describe server scheduling considerations (#1215, * Add section to describe server scheduling considerations (#1215,
#1232, #1266) #1232, #1266)
o Remove specific instructions related to intermediary fairness * Remove specific instructions related to intermediary fairness
(#1022, #1264) (#1022, #1264)
B.2. Since draft-ietf-httpbis-priority-00 B.3. Since draft-ietf-httpbis-priority-00
o Move text around (#1217, #1218) * Move text around (#1217, #1218)
o 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.3. Since draft-kazuho-httpbis-priority-04 B.4. Since draft-kazuho-httpbis-priority-04
* Minimize semantics of Urgency levels (#1023, #1026)
o Minimize semantics of Urgency levels (#1023, #1026)
o Reduce guidance about how intermediary implements merging priority * Reduce guidance about how intermediary implements merging priority
signals (#1026) signals (#1026)
o Remove mention of CDN-Loop (#1062) * Remove mention of CDN-Loop (#1062)
o Editorial changes * Editorial changes
o Make changes due to WG adoption * Make changes due to WG adoption
o Removed outdated Consideration (#118) * Removed outdated Consideration (#118)
B.4. Since draft-kazuho-httpbis-priority-03 B.5. Since draft-kazuho-httpbis-priority-03
o Changed numbering from "[-1,6]" to "[0,7]" (#78) * Changed numbering from "[-1,6]" to "[0,7]" (#78)
o Replaced priority scheme negotiation with HTTP/2 priority * Replaced priority scheme negotiation with HTTP/2 priority
deprecation (#100) deprecation (#100)
o Shorten parameter names (#108) * Shorten parameter names (#108)
o Expand on considerations (#105, #107, #109, #110, #111, #113) * Expand on considerations (#105, #107, #109, #110, #111, #113)
B.5. Since draft-kazuho-httpbis-priority-02 B.6. Since draft-kazuho-httpbis-priority-02
o Consolidation of the problem statement (#61, #73) * Consolidation of the problem statement (#61, #73)
o Define SETTINGS_PRIORITIES for negotiation (#58, #69) * Define SETTINGS_PRIORITIES for negotiation (#58, #69)
o Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) * Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
o Explain fairness issue and mitigations (#56) * Explain fairness issue and mitigations (#56)
B.6. Since draft-kazuho-httpbis-priority-01 B.7. Since draft-kazuho-httpbis-priority-01
o Explain how reprioritization might be supported. * Explain how reprioritization might be supported.
B.7. Since draft-kazuho-httpbis-priority-00 B.8. Since draft-kazuho-httpbis-priority-00
o Expand urgency levels from 3 to 8. * Expand urgency levels from 3 to 8.
Authors' Addresses Authors' Addresses
Kazuho Oku Kazuho Oku
Fastly Fastly
Email: kazuhooku@gmail.com Email: kazuhooku@gmail.com
Lucas Pardue Lucas Pardue
Cloudflare Cloudflare
Email: lucaspardue.24.7@gmail.com Email: lucaspardue.24.7@gmail.com
 End of changes. 57 change blocks. 
135 lines changed or deleted 224 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/