draft-ietf-httpbis-connect-tcp-02.txt | draft-ietf-httpbis-connect-tcp-latest.txt | |||
---|---|---|---|---|
httpbis Working Group B. Schwartz | httpbis Working Group B. Schwartz | |||
Internet-Draft Meta Platforms, Inc. | Internet-Draft Meta Platforms, Inc. | |||
Intended status: Standards Track December 07, 2023 | Intended status: Standards Track April 22, 2024 | |||
Expires: June 9, 2024 | Expires: October 24, 2024 | |||
Template-Driven HTTP CONNECT Proxying for TCP | Template-Driven HTTP CONNECT Proxying for TCP | |||
draft-ietf-httpbis-connect-tcp-02 | draft-ietf-httpbis-connect-tcp-latest | |||
Abstract | Abstract | |||
TCP proxying using HTTP CONNECT has long been part of the core HTTP | TCP proxying using HTTP CONNECT has long been part of the core HTTP | |||
specification. However, this proxying functionality has several | specification. However, this proxying functionality has several | |||
important deficiencies in modern HTTP environments. This | important deficiencies in modern HTTP environments. This | |||
specification defines an alternative HTTP proxy service configuration | specification defines an alternative HTTP proxy service configuration | |||
for TCP connections. This configuration is described by a URI | for TCP connections. This configuration is described by a URI | |||
Template, similar to the CONNECT-UDP and CONNECT-IP protocols. | Template, similar to the CONNECT-UDP and CONNECT-IP protocols. | |||
skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
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 June 9, 2024. | This Internet-Draft will expire on October 24, 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2024 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 19 ¶ | skipping to change at page 2, line 19 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 | 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 | |||
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 5 | 3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Use of Relevant Headers . . . . . . . . . . . . . . . . . 6 | 3.3. Use of Relevant Headers . . . . . . . . . . . . . . . . . 6 | |||
3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6 | 3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6 | |||
3.3.2. Authentication Headers . . . . . . . . . . . . . . . 6 | 3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7 | |||
3.4. Relationship to the Capsule Protocol . . . . . . . . . . 7 | ||||
4. Additional Connection Setup Behaviors . . . . . . . . . . . . 7 | 4. Additional Connection Setup Behaviors . . . . . . . . . . . . 7 | |||
4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 7 | 4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 7 | |||
4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 7 | 4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 8 | |||
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.3. Multi-purpose proxies . . . . . . . . . . . . . . . . . . 9 | 5.3. Multi-purpose proxies . . . . . . . . . . . . . . . . . . 9 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
7. Operational Considerations . . . . . . . . . . . . . . . . . 9 | 7. Operational Considerations . . . . . . . . . . . . . . . . . 10 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 10 | 8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 11 | |||
8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 10 | 8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 11 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 11 | 9.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1. Introduction | 1. Introduction | |||
1.1. History | 1.1. History | |||
HTTP has used the CONNECT method for proxying TCP connections since | HTTP has used the CONNECT method for proxying TCP connections since | |||
HTTP/1.1. When using CONNECT, the request target specifies a host | HTTP/1.1. When using CONNECT, the request target specifies a host | |||
and port number, and the proxy forwards TCP payloads between the | and port number, and the proxy forwards TCP payloads between the | |||
client and this destination ([RFC9110], Section 9.3.6). To date, | client and this destination ([RFC9110], Section 9.3.6). To date, | |||
this is the only mechanism defined for proxying TCP over HTTP. In | this is the only mechanism defined for proxying TCP over HTTP. In | |||
skipping to change at page 4, line 14 ¶ | skipping to change at page 4, line 16 ¶ | |||
3. Specification | 3. Specification | |||
A template-driven TCP transport proxy for HTTP is identified by a URI | A template-driven TCP transport proxy for HTTP is identified by a URI | |||
Template [RFC6570] containing variables named "target_host" and | Template [RFC6570] containing variables named "target_host" and | |||
"tcp_port". The client substitutes the destination host and port | "tcp_port". The client substitutes the destination host and port | |||
number into these variables to produce the request URI. | number into these variables to produce the request URI. | |||
The "target_host" variable MUST be a domain name, an IP address | The "target_host" variable MUST be a domain name, an IP address | |||
literal, or a list of IP addresses. The "tcp_port" variable MUST be | literal, or a list of IP addresses. The "tcp_port" variable MUST be | |||
a single integer. If "target_host" is a list (as in Section 2.4.2 of | a single integer. If "target_host" is a list (as in Section 3.2.1 of | |||
[RFC6570]), the server SHOULD perform the same connection procedure | [RFC6570]), the server SHOULD perform the same connection procedure | |||
as if these addresses had been returned in response to A and AAAA | as if these IP addresses had been returned in response to A and AAAA | |||
queries for a domain name. | queries for a domain name. | |||
3.1. In HTTP/1.1 | 3.1. In HTTP/1.1 | |||
In HTTP/1.1, the client uses the proxy by issuing a request as | In HTTP/1.1, the client uses the proxy by issuing a request as | |||
follows: | follows: | |||
o The method SHALL be "GET". | o The method SHALL be "GET". | |||
o The request SHALL include a single "Host" header field containing | o The request SHALL include a single "Host" header field containing | |||
skipping to change at page 4, line 40 ¶ | skipping to change at page 4, line 42 ¶ | |||
value "Upgrade". (Note that this requirement is case-insensitive | value "Upgrade". (Note that this requirement is case-insensitive | |||
as per Section 7.6.1 of [RFC9110].) | as per Section 7.6.1 of [RFC9110].) | |||
o The request SHALL include an "Upgrade" header field with the value | o The request SHALL include an "Upgrade" header field with the value | |||
"connect-tcp". | "connect-tcp". | |||
o The request's target SHALL correspond to the URI derived from | o The request's target SHALL correspond to the URI derived from | |||
expansion of the proxy's URI Template. | expansion of the proxy's URI Template. | |||
If the request is well-formed and permissible, the proxy MUST attempt | If the request is well-formed and permissible, the proxy MUST attempt | |||
the TCP connection before returning its response header. If the TCP | the TCP connection before sending any response status code other than | |||
connection is successful, the response SHALL be as follows: | "100 (Continue)" (see Section 4.2). If the TCP connection is | |||
successful, the response SHALL be as follows: | ||||
o The HTTP status code SHALL be "101 (Switching Protocols)". | o The HTTP status code SHALL be "101 (Switching Protocols)". | |||
o The response SHALL include a "Connection" header field with the | o The response SHALL include a "Connection" header field with the | |||
value "Upgrade". | value "Upgrade". | |||
o The response SHALL include a single "Upgrade" header field with | o The response SHALL include a single "Upgrade" header field with | |||
the value "connect-tcp". | the value "connect-tcp". | |||
If the request is malformed or impermissible, the proxy MUST return a | If the request is malformed or impermissible, the proxy MUST return a | |||
skipping to change at page 5, line 14 ¶ | skipping to change at page 5, line 20 ¶ | |||
MUST NOT switch protocols to "connect-tcp", and the client MAY reuse | MUST NOT switch protocols to "connect-tcp", and the client MAY reuse | |||
this connection for additional HTTP requests. | this connection for additional HTTP requests. | |||
After a success response is returned, the connection SHALL conform to | After a success response is returned, the connection SHALL conform to | |||
all the usual requirements for classic CONNECT proxies in HTTP/1.1 | all the usual requirements for classic CONNECT proxies in HTTP/1.1 | |||
([RFC9110], Section 9.3.6). Additionally, if the proxy observes a | ([RFC9110], Section 9.3.6). Additionally, if the proxy observes a | |||
connection error from the client (e.g., a TCP RST, TCP timeout, or | connection error from the client (e.g., a TCP RST, TCP timeout, or | |||
TLS error), it SHOULD send a TCP RST to the target. If the proxy | TLS error), it SHOULD send a TCP RST to the target. If the proxy | |||
observes a connection error from the target, it SHOULD send a TLS | observes a connection error from the target, it SHOULD send a TLS | |||
"internal_error" alert to the client, or set the TCP RST bit if TLS | "internal_error" alert to the client, or set the TCP RST bit if TLS | |||
is not in use. | is not in use. These behaviors avoid truncation of transfers between | |||
the client and the target on vulnerable protocols (e.g., HTTP/1.1 | ||||
without TLS) while preserving the confidentiality and integrity | ||||
guarantees of the "https" scheme. | ||||
Client Proxy | Client Proxy | |||
GET /proxy?target_host=192.0.2.1&tcp_port=443 HTTP/1.1 | GET /proxy?target_host=192.0.2.1&tcp_port=443 HTTP/1.1 | |||
Host: example.com | Host: example.com | |||
Connection: Upgrade | Connection: Upgrade | |||
Upgrade: connect-tcp | Upgrade: connect-tcp | |||
** Proxy establishes a TCP connection to 192.0.2.1:443 ** | ** Proxy establishes a TCP connection to 192.0.2.1:443 ** | |||
HTTP/1.1 101 Switching Protocols | HTTP/1.1 101 Switching Protocols | |||
Connection: Upgrade | Connection: Upgrade | |||
Upgrade: connect-tcp | Upgrade: connect-tcp | |||
Templated TCP proxy example in HTTP/1.1 | Templated TCP proxy example in HTTP/1.1 | |||
3.2. In HTTP/2 and HTTP/3 | 3.2. In HTTP/2 and HTTP/3 | |||
In HTTP/2 and HTTP/3, the client uses the proxy by issuing an | In HTTP/2 and HTTP/3, the proxy MUST include | |||
"extended CONNECT" request as follows: | SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame [RFC8441] | |||
[RFC9220]. The client uses the proxy by issuing an "extended | ||||
CONNECT" request as follows: | ||||
o The :method pseudo-header field SHALL be "CONNECT". | o The :method pseudo-header field SHALL be "CONNECT". | |||
o The :protocol pseudo-header field SHALL be "connect-tcp". | o The :protocol pseudo-header field SHALL be "connect-tcp". | |||
o The :authority pseudo-header field SHALL contain the authority of | o The :authority pseudo-header field SHALL contain the authority of | |||
the proxy. | the proxy. | |||
o The :path and :scheme pseudo-header fields SHALL contain the path | o The :path and :scheme pseudo-header fields SHALL contain the path | |||
and scheme of the request URI derived from the proxy's URI | and scheme of the request URI derived from the proxy's URI | |||
Template. | Template. | |||
From this point on, the request and response SHALL conform to all the | From this point on, the request and response SHALL conform to all the | |||
usual requirements for classic CONNECT proxies in this HTTP version | usual requirements for classic CONNECT proxies in this HTTP version | |||
(see Section 8.5 of [RFC9113] and Section 4.4 of [RFC9114]). | (see Section 8.5 of [RFC9113] and Section 4.4 of [RFC9114]). | |||
A templated TCP proxying request that does not conform to all of | ||||
these requirements represents a client error (see [RFC9110], | ||||
Section 15.5) and may be malformed (see Section 8.1.1 of [RFC9113] | ||||
and Section 4.1.2 of [RFC9114]). | ||||
HEADERS | HEADERS | |||
:method = CONNECT | :method = CONNECT | |||
:scheme = https | :scheme = https | |||
:authority = request-proxy.example | :authority = request-proxy.example | |||
:path = /proxy?target_host=192.0.2.1,2001:db8::1&tcp_port=443 | :path = /proxy?target_host=192.0.2.1,2001:db8::1&tcp_port=443 | |||
:protocol = connect-tcp | :protocol = connect-tcp | |||
... | ... | |||
Templated TCP proxy example in HTTP/2 | Templated TCP proxy example in HTTP/2 | |||
skipping to change at page 7, line 11 ¶ | skipping to change at page 7, line 23 ¶ | |||
not use the "407 (Proxy Authentication Required)" response code and | not use the "407 (Proxy Authentication Required)" response code and | |||
related header fields ([RFC9110], Section 11.7) because they do not | related header fields ([RFC9110], Section 11.7) because they do not | |||
traverse HTTP gateways (see Section 7). | traverse HTTP gateways (see Section 7). | |||
Clients SHOULD assume that all proxy resources generated by a single | Clients SHOULD assume that all proxy resources generated by a single | |||
template share a protection space (i.e., a realm) ([RFC9110], | template share a protection space (i.e., a realm) ([RFC9110], | |||
Section 11.5). For many authentication schemes, this will allow the | Section 11.5). For many authentication schemes, this will allow the | |||
client to avoid waiting for a "401 (Unauthorized)" response before | client to avoid waiting for a "401 (Unauthorized)" response before | |||
each new connection through the proxy. | each new connection through the proxy. | |||
3.4. Relationship to the Capsule Protocol | ||||
Unlike the datagram-oriented templated HTTP proxying specifications | ||||
[CONNECT-UDP] [CONNECT-IP], this specification does not make use of | ||||
the Capsule Protocol [RFC9297]. A future specification could define | ||||
a procedure for performing TCP proxying using the Capsule Protocol, | ||||
but no such procedure is defined here. | ||||
When implementing this specification, clients and servers MUST NOT | ||||
send a "Capsule-Protocol: ?1" header field. | ||||
4. Additional Connection Setup Behaviors | 4. Additional Connection Setup Behaviors | |||
This section discusses some behaviors that are permitted or | This section discusses some behaviors that are permitted or | |||
recommended in order to enhance the performance or functionality of | recommended in order to enhance the performance or functionality of | |||
connection setup. | connection setup. | |||
4.1. Latency optimizations | 4.1. Latency optimizations | |||
When using this specification in HTTP/2 or HTTP/3, clients MAY start | When using this specification in HTTP/2 or HTTP/3, clients MAY start | |||
sending TCP stream content optimistically, subject to flow control | sending TCP stream content optimistically, subject to flow control | |||
limits (Section 5.2 of [RFC9113] or Section 4.1 of [RFC9000]). | limits (Section 5.2 of [RFC9113] or Section 4.1 of [RFC9000]). | |||
Proxies MUST buffer this "optimistic" content until the TCP stream | Proxies MUST buffer this "optimistic" content until the TCP stream | |||
becomes writable, and discard it if the TCP connection fails. (This | becomes writable, and discard it if the TCP connection fails. | |||
"optimistic" behavior is not permitted in HTTP/1.1 because it would | (Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this | |||
interfere with reuse of the connection after an error response such | would interfere with reuse of the connection after an error response | |||
as "401 (Unauthorized)".) | such as "401 (Unauthorized)".) | |||
Servers that host a proxy under this specification MAY offer support | Servers that host a proxy under this specification MAY offer support | |||
for TLS early data in accordance with [RFC8470]. Clients MAY send | for TLS early data in accordance with [RFC8470]. Clients MAY send | |||
"connect-tcp" requests in early data, and MAY include "optimistic" | "connect-tcp" requests in early data, and MAY include "optimistic" | |||
TCP content in early data (in HTTP/2 and HTTP/3). At the TLS layer, | TCP content in early data (in HTTP/2 and HTTP/3). At the TLS layer, | |||
proxies MAY ignore, reject, or accept the "early_data" extension | proxies MAY ignore, reject, or accept the "early_data" extension | |||
([RFC8446], Section 4.2.10). At the HTTP layer, proxies MAY process | ([RFC8446], Section 4.2.10). At the HTTP layer, proxies MAY process | |||
the request immediately, return a "425 (Too Early)" response | the request immediately, return a "425 (Too Early)" response | |||
([RFC8470], Section 5.2), or delay some or all processing of the | ([RFC8470], Section 5.2), or delay some or all processing of the | |||
request until the handshake completes. For example, a proxy with | request until the handshake completes. For example, a proxy with | |||
skipping to change at page 7, line 49 ¶ | skipping to change at page 8, line 23 ¶ | |||
the TCP connection until the TLS handshake completes. | the TCP connection until the TLS handshake completes. | |||
4.2. Conveying metadata | 4.2. Conveying metadata | |||
This specification supports the "Expect: 100-continue" request header | This specification supports the "Expect: 100-continue" request header | |||
([RFC9110], Section 10.1.1) in any HTTP version. The "100 | ([RFC9110], Section 10.1.1) in any HTTP version. The "100 | |||
(Continue)" status code confirms receipt of a request at the proxy | (Continue)" status code confirms receipt of a request at the proxy | |||
without waiting for the proxy-destination TCP handshake to succeed or | without waiting for the proxy-destination TCP handshake to succeed or | |||
fail. This might be particularly helpful when the destination host | fail. This might be particularly helpful when the destination host | |||
is not responding, as TCP handshakes can hang for several minutes | is not responding, as TCP handshakes can hang for several minutes | |||
before failing. Implementation of "100 (Continue)" support is | before failing. Clients MAY send "Expect: 100-continue", and proxies | |||
OPTIONAL for clients and REQUIRED for proxies. | MUST respect it by returning "100 (Continue)" if the request is not | |||
immediately rejected. | ||||
Proxies implementing this specification SHOULD include a "Proxy- | Proxies implementing this specification SHOULD include a "Proxy- | |||
Status" response header [RFC9209] in any success or failure response | Status" response header [RFC9209] in any success or failure response | |||
(i.e., status codes 101, 2XX, 4XX, or 5XX) to support advanced client | (i.e., status codes 101, 2XX, 4XX, or 5XX) to support advanced client | |||
behaviors and diagnostics. In HTTP/2 or HTTP/3, proxies MAY | behaviors and diagnostics. In HTTP/2 or HTTP/3, proxies MAY | |||
additionally send a "Proxy-Status" trailer in the event of an unclean | additionally send a "Proxy-Status" trailer in the event of an unclean | |||
shutdown. | shutdown. | |||
5. Applicability | 5. Applicability | |||
skipping to change at page 11, line 14 ¶ | skipping to change at page 11, line 44 ¶ | |||
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., | [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., | |||
and D. Orchard, "URI Template", RFC 6570, | and D. Orchard, "URI Template", RFC 6570, | |||
DOI 10.17487/RFC6570, March 2012, | DOI 10.17487/RFC6570, March 2012, | |||
<https://www.rfc-editor.org/info/rfc6570>. | <https://www.rfc-editor.org/info/rfc6570>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", | ||||
RFC 8441, DOI 10.17487/RFC8441, September 2018, | ||||
<https://www.rfc-editor.org/info/rfc8441>. | ||||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early | [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early | |||
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September | Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September | |||
2018, <https://www.rfc-editor.org/info/rfc8470>. | 2018, <https://www.rfc-editor.org/info/rfc8470>. | |||
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
Multiplexed and Secure Transport", RFC 9000, | Multiplexed and Secure Transport", RFC 9000, | |||
skipping to change at page 11, line 43 ¶ | skipping to change at page 12, line 30 ¶ | |||
DOI 10.17487/RFC9113, June 2022, | DOI 10.17487/RFC9113, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9113>. | <https://www.rfc-editor.org/info/rfc9113>. | |||
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, | [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, | |||
June 2022, <https://www.rfc-editor.org/info/rfc9114>. | June 2022, <https://www.rfc-editor.org/info/rfc9114>. | |||
[RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP | [RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP | |||
Response Header Field", RFC 9209, DOI 10.17487/RFC9209, | Response Header Field", RFC 9209, DOI 10.17487/RFC9209, | |||
June 2022, <https://www.rfc-editor.org/info/rfc9209>. | June 2022, <https://www.rfc-editor.org/info/rfc9209>. | |||
[RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3", | ||||
RFC 9220, DOI 10.17487/RFC9220, June 2022, | ||||
<https://www.rfc-editor.org/info/rfc9220>. | ||||
9.2. Informative References | 9.2. Informative References | |||
[CAPABILITY] | [CAPABILITY] | |||
"Good Practices for Capability URLs", February 2014, | "Good Practices for Capability URLs", February 2014, | |||
<https://www.w3.org/TR/capability-urls/>. | <https://www.w3.org/TR/capability-urls/>. | |||
[CLEAR-SITE-DATA] | [CLEAR-SITE-DATA] | |||
"Clear Site Data", November 2017, | "Clear Site Data", November 2017, | |||
<https://www.w3.org/TR/clear-site-data/>. | <https://www.w3.org/TR/clear-site-data/>. | |||
End of changes. 20 change blocks. | ||||
30 lines changed or deleted | 62 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/ |