draft-ietf-httpbis-priority-00.txt   draft-ietf-httpbis-priority-01.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: September 6, 2020 Cloudflare Expires: January 14, 2021 Cloudflare
March 05, 2020 July 13, 2020
Extensible Prioritization Scheme for HTTP Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-00 draft-ietf-httpbis-priority-01
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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 September 6, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8 3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8
4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 8 4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 8
5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 8 5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 8
5.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 9 5.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 9
5.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 10 5.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 10
6. Merging Client- and Server-Driven Parameters . . . . . . . . 11 6. Merging Client- and Server-Driven Parameters . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1.1. Coalescing Intermediaries . . . . . . . . . . . . . . 12 8.1. Coalescing Intermediaries . . . . . . . . . . . . . . . . 13
7.1.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . 13 8.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 13
7.1.3. Intentional Introduction of Unfairness . . . . . . . 14 8.3. Intentional Introduction of Unfairness . . . . . . . . . 14
8. Considerations . . . . . . . . . . . . . . . . . . . . . . . 14 9. Why use an End-to-End Header Field? . . . . . . . . . . . . . 14
8.1. Why use an End-to-End Header Field? . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
B.1. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 18 B.1. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 18
B.2. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 18 B.2. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 19
B.3. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 18 B.3. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 19
B.4. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 18 B.4. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 19
B.5. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 18 B.5. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 B.6. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 5, line 30 skipping to change at page 5, line 30
2.1. Disabling HTTP/2 Priorities 2.1. Disabling HTTP/2 Priorities
The problems and insights set out above are motivation for allowing The problems and insights set out above are motivation for allowing
endpoints to opt out of using the HTTP/2 priority scheme, in favor of endpoints to opt out of using the HTTP/2 priority scheme, in favor of
using an alternative such as the scheme defined in this using an alternative such as the scheme defined in this
specification. The SETTINGS_DEPRECATE_HTTP2_PRIORITIES setting specification. The SETTINGS_DEPRECATE_HTTP2_PRIORITIES setting
described below enables endpoints to understand their peer's described below enables endpoints to understand their peer's
intention. The value of the parameter MUST be 0 or 1. Any value intention. The value of the parameter MUST be 0 or 1. Any value
other than 0 or 1 MUST be treated as a connection error (see other than 0 or 1 MUST be treated as a connection error (see
[RFC7540]; Section 5.4.1) of type PROTOCOL_ERROR. [RFC7540], Section 5.4.1) of type PROTOCOL_ERROR.
Endpoints MUST send this SETTINGS parameter as part of the first Endpoints MUST send this SETTINGS parameter as part of the first
SETTINGS frame. When the peer receives the first SETTINGS frame, it SETTINGS frame. When the peer receives the first SETTINGS frame, it
learns the sender has deprecated the HTTP/2 priority scheme if it learns the sender has deprecated the HTTP/2 priority scheme if it
receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the
value of 1. value of 1.
A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES
parameter value after the first SETTINGS frame. Detection of a parameter value after the first SETTINGS frame. Detection of a
change by a receiver MUST be treated as a connection error of type change by a receiver MUST be treated as a connection error of type
skipping to change at page 6, line 45 skipping to change at page 6, line 45
Unknown parameters, parameters with out-of-range values or values of Unknown parameters, parameters with out-of-range values or values of
unexpected types MUST be ignored. unexpected types MUST be ignored.
3.1. Urgency 3.1. Urgency
The urgency parameter ("u") takes an integer between 0 and 7, in The urgency parameter ("u") takes an integer between 0 and 7, in
descending order of priority. This range provides sufficient descending order of priority. This range provides sufficient
granularity for prioritizing responses for ordinary web browsing, at granularity for prioritizing responses for ordinary web browsing, at
minimal complexity. minimal complexity.
The value is encoded as an sh-integer. The default value is 1. The value is encoded as an sh-integer. The default value is 3.
This parameter indicates the sender's recommendation, based on the This parameter indicates the sender's recommendation, based on the
expectation that the server would transmit HTTP responses in the expectation that the server would transmit HTTP responses in the
order of their urgency values if possible. The smaller the value, order of their urgency values if possible. The smaller the value,
the higher the precedence. the higher the precedence.
The following example shows a request for a CSS file with the urgency The following example shows a request for a CSS file with the urgency
set to "0": set to "0":
:method = GET :method = GET
skipping to change at page 12, line 27 skipping to change at page 12, line 27
:status = 200 :status = 200
content-type = image/png content-type = image/png
priority = u=1 priority = u=1
the intermediary might alter its understanding of the urgency from the intermediary might alter its understanding of the urgency from
"5" to "1", because it prefers the server-provided value over the "5" to "1", because it prefers the server-provided value over the
client's. The incremental value continues to be "true", the value client's. The incremental value continues to be "true", the value
specified by the client, as the server did not specify the specified by the client, as the server did not specify the
incremental("i") parameter. incremental("i") parameter.
7. Security Considerations 7. Client Scheduling
7.1. Fairness A client MAY use priority values to make local scheduling choices
about the requests it initiates.
8. 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. TODO: Discuss if we should add a signal that mitigates this issue.
For example, we might add a SETTINGS parameter that indicates the For example, we might add a SETTINGS parameter that indicates the
next hop that the connection is NOT coalesced (see next hop that the connection is NOT coalesced (see
https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99). https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99).
7.1.1. Coalescing Intermediaries 8.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
transmission of software update files that would have the background transmission of software update files that would have the background
skipping to change at page 13, line 39 skipping to change at page 13, line 46
Responding to requests coming through an intermediary in a round- Responding to requests coming through an intermediary in a round-
robin manner works well when the network bottleneck exists between robin manner works well when the network bottleneck exists between
the intermediary and the end client, as the intermediary would be the intermediary and the end client, as the intermediary would be
buffering the responses and then be forwarding the chunks of those buffering the responses and then be forwarding the chunks of those
buffered responses based on the prioritization scheme it implements. buffered responses based on the prioritization scheme it implements.
A sophisticated server MAY use a weighted round-robin reflecting the A sophisticated server MAY use a weighted round-robin reflecting the
urgencies expressed in the requests, so that less urgent responses urgencies expressed in the requests, so that less urgent responses
would receive less bandwidth in case the bottleneck exists between would receive less bandwidth in case the bottleneck exists between
the server and the intermediary. the server and the intermediary.
7.1.2. HTTP/1.x Back Ends 8.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
fairness issue in protocol. However, back end servers MAY still use fairness issue in protocol. However, back end servers MAY still use
client headers for request scheduling. Back end servers SHOULD only client headers for request scheduling. Back end servers SHOULD only
schedule based on client priority information where that information schedule based on client priority information where that information
can be scoped to individual end clients. Authentication and other can be scoped to individual end clients. Authentication and other
session information might provide this linkability. session information might provide this linkability.
7.1.3. Intentional Introduction of Unfairness 8.3. Intentional Introduction of Unfairness
It is sometimes beneficial to deprioritize the transmission of one It is sometimes beneficial to deprioritize the transmission of one
connection over others, knowing that doing so introduces a certain connection over others, knowing that doing so introduces a certain
amount of unfairness between the connections and therefore between amount of unfairness between the connections and therefore between
the requests served on those connections. the requests served on those connections.
For example, a server might use a scavenging congestion controller on For example, a server might use a scavenging congestion controller on
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.
Also, a client MAY use the priority values for making local 9. Why use an End-to-End Header Field?
scheduling choices for the requests it initiates.
8. Considerations
8.1. Why use an End-to-End Header Field?
Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- Contrary to the prioritization scheme of HTTP/2 that uses a hop-by-
hop frame, the Priority header field is defined as end-to-end. hop frame, the Priority header field is defined as end-to-end.
The rationale is that the Priority header field transmits how each The rationale is that the Priority header field transmits how each
response affects the client's processing of those responses, rather response affects the client's processing of those responses, rather
than how relatively urgent each response is to others. The way a than how relatively urgent each response is to others. The way a
client processes a response is a property associated to that client client processes a response is a property associated to that client
generating that request. Not that of an intermediary. Therefore, it generating that request. Not that of an intermediary. Therefore, it
is an end-to-end property. How these end-to-end properties carried is an end-to-end property. How these end-to-end properties carried
skipping to change at page 14, line 47 skipping to change at page 15, line 5
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.
It should also be noted that the use of a header field carrying a It should also be noted that the use of a header field carrying a
textual value makes the prioritization scheme extensible; see the textual value makes the prioritization scheme extensible; see the
discussion below. discussion below.
9. IANA Considerations 10. Security Considerations
[CVE-2019-9513] aka "Resource Loop", is a DoS attack based on
manipulation of the HTTP/2 priority tree. Extensible priorities does
not use stream dependencies, which mitigates this vulnerability.
TBD: depending on the outcome of reprioritization discussions,
following paragraphs may change or be removed.
[RFC7540], Section 5.3.4 describes a scenario where closure of
streams in the priority tree could cause suboptimal prioritization.
To avoid this, [RFC7540] states that "an endpoint SHOULD retain
stream prioritization state for a period after streams become
closed". Retaining state for streams no longer counted towards
stream concurrency consumes server resources. Furthermore, [RFC7540]
identifies that reprioritization of a closed stream could affect
dependents; it recommends updating the priority tree if sufficient
state is stored, which will also consume server resources. To limit
this commitment, it is stated that "The amount of prioritization
state that is retained MAY be limited" and "If a limit is applied,
endpoints SHOULD maintain state for at least as many streams as
allowed by their setting for SETTINGS_MAX_CONCURRENT_STREAMS.".
Extensible priorities does not use stream dependencies, which
minimizes most of the resource concerns related to this scenario.
[RFC7540], Section 5.3.4 also presents considerations about the state
required to store priority information about streams in an "idle"
state. This state can be limited by adopting the guidance about
concurrency limits described above. Extensible priorities is subject
to a similar consideration because PRIORITY_UPDATE frames may arrive
before the request that they reference. A server is required to
store the information in order to apply the most up-to-date signal to
the request. However, HTTP/3 implementations might have practical
barriers to determining reasonable stream concurrency limits
depending on the information that is available to them from the QUIC
transport layer. TODO: so what can we suggest?
11. IANA Considerations
This specification registers the following entry in the Permanent This specification registers the following entry in the Permanent
Message Header Field Names registry established by [RFC3864]: Message Header Field Names registry established by [RFC3864]:
Header field name: Priority Header field name: Priority
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document Specification document(s): This document
Related information: n/a Related information: n/a
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]:
Name: SETTINGS_DEPRECATE_HTTP2_PRIORITIES Name: SETTINGS_DEPRECATE_HTTP2_PRIORITIES
skipping to change at page 15, line 43 skipping to change at page 16, line 39
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: 0xF Code: 0xF
Specification: This document Specification: This document
10. References 12. References
10.1. Normative References 12.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-27 (work in progress), (HTTP/3)", draft-ietf-quic-http-29 (work in progress),
February 2020. June 2020.
[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-27 (work and Secure Transport", draft-ietf-quic-transport-29 (work
in progress), February 2020. in progress), June 2020.
[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>.
[STRUCTURED-HEADERS] [STRUCTURED-HEADERS]
Nottingham, M. and P. Kamp, "Structured Headers for HTTP", Nottingham, M. and P. Kamp, "Structured Field Values for
draft-ietf-httpbis-header-structure-15 (work in progress), HTTP", draft-ietf-httpbis-header-structure-19 (work in
January 2020. progress), June 2020.
10.2. Informative References 12.2. Informative References
[CVE-2019-9513] [CVE-2019-9513]
Common Vulnerabilities and Exposures, "CVE-2019-9513", Common Vulnerabilities and Exposures, "CVE-2019-9513",
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", draft-lassey-priority-setting-00 (work in
progress), July 2019. progress), July 2019.
skipping to change at page 17, line 13 skipping to change at page 18, line 9
<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>.
10.3. URIs 12.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] https://httpwg.org/ [2] https://httpwg.org/
[3] https://github.com/httpwg/http-extensions/labels/priorities [3] https://github.com/httpwg/http-extensions/labels/priorities
[4] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf [4] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf
[5] https://github.com/pmeenan/http3-prioritization-proposal [5] https://github.com/pmeenan/http3-prioritization-proposal
skipping to change at page 18, line 4 skipping to change at page 18, line 45
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-kazuho-httpbis-priority-04
B.1. Since draft-ietf-httpbis-priority-00
o Move text around (#1217, #1218)
o Editorial change to the default urgency. The value is 3, which
was always the intent of previous changes.
B.2. Since draft-kazuho-httpbis-priority-04
o Minimize semantics of Urgency levels (#1023, #1026) o Minimize semantics of Urgency levels (#1023, #1026)
o Reduce guidance about how intermediary implements merging priority o Reduce guidance about how intermediary implements merging priority
signals (#1026) signals (#1026)
o Remove mention of CDN-Loop (#1062) o Remove mention of CDN-Loop (#1062)
o Editorial changes o Editorial changes
o Make changes due to WG adoption o Make changes due to WG adoption
o Removed outdated Consideration (#118) o Removed outdated Consideration (#118)
B.2. Since draft-kazuho-httpbis-priority-03 B.3. Since draft-kazuho-httpbis-priority-03
o Changed numbering from "[-1,6]" to "[0,7]" (#78) o Changed numbering from "[-1,6]" to "[0,7]" (#78)
o Replaced priority scheme negotiation with HTTP/2 priority o Replaced priority scheme negotiation with HTTP/2 priority
deprecation (#100) deprecation (#100)
o Shorten parameter names (#108) o Shorten parameter names (#108)
o Expand on considerations (#105, #107, #109, #110, #111, #113) o Expand on considerations (#105, #107, #109, #110, #111, #113)
B.3. Since draft-kazuho-httpbis-priority-02 B.4. Since draft-kazuho-httpbis-priority-02
o Consolidation of the problem statement (#61, #73) o Consolidation of the problem statement (#61, #73)
o Define SETTINGS_PRIORITIES for negotiation (#58, #69) o Define SETTINGS_PRIORITIES for negotiation (#58, #69)
o Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) o Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
o Explain fairness issue and mitigations (#56) o Explain fairness issue and mitigations (#56)
B.4. Since draft-kazuho-httpbis-priority-01 B.5. Since draft-kazuho-httpbis-priority-01
o Explain how reprioritization might be supported. o Explain how reprioritization might be supported.
B.5. Since draft-kazuho-httpbis-priority-00 B.6. Since draft-kazuho-httpbis-priority-00
o Expand urgency levels from 3 to 8. o 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. 27 change blocks. 
55 lines changed or deleted 99 lines changed or added

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