]> Fastly

kazuhooku@gmail.com

httpbis internet-draft This document specifies the Protocol for Transposed Transactions over HTTP (PTTH), an HTTP extension that allows a backend server to establish an HTTP connection to a reverse proxy and transpose HTTP request flow. The reverse proxy then forwards incoming requests to the backend server over the transposed connection. This extension lets backend servers behind restrictive firewalls accept HTTP traffic through reverse proxies without changing firewall settings and with virtually zero overhead. Discussion Venues Discussion of this document takes place on the Protocol for Transposed Transactions over HTTP Working Group mailing list (ptth@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction In scalable HTTP deployments—such as those using CDNs and dynamic backend server pools—clients send requests to reverse proxies, which then forward them to backend servers. Backend servers frequently reside behind firewalls that block inbound TCP or QUIC connections, requiring special network or firewall configuration to permit proxy-initiated traffic. To overcome these restrictions, some organizations use VPNs, but VPNs introduce operational complexity, hamper scalability, and impose performance overhead. PTTH enables a backend server to establish an HTTP connection to a reverse proxy and transpose the flow of HTTP requests so that the proxy sends incoming requests back over the same connection. An HTTP request is used for authenticating the backend server and for negotiating the scope of requests forwarded to the transposed connection, providing flexibility to deployments. Because PTTH transposes the direction of communication rather than encapsulating traffic, it incurs virtually zero overhead and delivers high efficiency. TODO: expand

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Protocol To set up a transposed connection, the backend server connects to the reverse proxy and sends an HTTP request including a URI specifying the transposed endpoint and credentials that authenticate the backend server. The exact form of the URI specifying the transposed endpoint is unspecified; it is up to each reverse proxy deployment. Similarly, the authentication scheme is unspecified. Deployments can use either a TLS- or an HTTP-based authentication scheme, or something else. The method being used to establish the transposed connection is different between HTTP versions. However, the HTTP header fields are version-independent, and therefore the parameters for negotiating PTTH can be defined in a version-neutral manner. PTTH cannot originate over HTTP/2. To establish a transposed HTTP/2 channel, HTTP/1.1 upgrade is used, with the ALPN specifying HTTP/2.

HTTP/1.1 and HTTP/2 To establish a transposed HTTP/1.1 or HTTP/2 channel, the backend server connects to the reverse proxy using HTTP/1.1 (), and uses the HTTP upgrade mechanism ( Section 7.8) to negotiate the transposition. The method of the upgrade request SHALL be "GET", accompanied by an "Upgrade: ptth" header field. The request MUST also include the ALPN header field () specifying the HTTP versions that the backend server is willing to use on the transposed connection. Once the transposed connection is established successfully, the reverse proxy responds with a 101 (Switching Protocols) response, alongside an ALPN response header specifying the HTTP version being chosen. After a 101 response is sent, HTTP requests are sent in the direction from the reverse proxy to the backend server. shows an exchange of HTTP/1.1 upgrade request and response establishing the transposed connection. In this example, the Basic HTTP Authentication Scheme is used to authenticate the backend server. As for the application protocol to be used on the transposed connection, the backend server is offering both HTTP/2 and HTTP/1.1, and the reverse proxy selects HTTP/2.

Establishing a transposed connection over HTTP/1.1

As the parameters for the transposed connection are exchanged using the upgrade request, they cannot be changed once the transposed connection is established. To change those parameters, a new HTTP/1.1 connection should be established and transposed.

HTTP/3 In HTTP/3 (), the OPTIONS method () is used to transpose HTTP request flow on the HTTP/3 connection. As the flow of the existing connection is transposed, neither the :protocol pseudo-header field nor the ALPN header field is used. The target of the OPTIONS request is the endpoint that tranposes the connection; therefore, the asterisk ("*") request is never used for establishing PTTH. Once the reverse proxy responds with a 2xx response, it starts forwarding HTTP requests on the server-initiated, bidirectional QUIC streams. Note that, due to packet reordering, backend servers might receive these requests before receiving a 200 response for the OPTIONS request. Similarly to when HTTP/1.1 is used, establishment of a new HTTP/3 connection is required if a transposed HTTP/3 connection with different set of parameters is needed. Once the connection is transposed, the reverse proxy MAY reset incoming requests that it receives using a H3_REQUEST_REJECTED error (). TODO: Discuss the downsides of transposing an HTTP/3 connection; notes:

• No issues with SETTINGS; none of the HTTP/3 settings are specific to clients or servers.
• No issues with QPACK; one set of QPACK streams can handle requests flying in both directions.
• We need to consider how to handle quarter stream IDs of HTTP/3 datagrams; but that issue not orthogonal to sending HTTP requests in both directions. The issue arises for any design that establishes the QUIC connection in the reverse direction. Maybe the answer here is to use stream_id / 4 + (2 << 60) as the quarter stream IDs for datagrams belonging to the transposed requests.
• Otherwise, the design does not interfere with WebTransport over HTTP/3; for both client- and server-initiated bidirectional streams, WebTransport streams can be identified by their signal vallues (0x41), and if they are associated to client- or server-initiated requests can be determined by their Session ID (i.e., the stream ID of the CONNECT stream).
• Rather than using OPTIONS, do we want to use an extended CONNECT? While the use of OPTIONS might be fine, HTTP requests without a special pseudo-header is end-to-end per definition. Using an extended CONNECT is a straightforward way to constrain the setup of a transposed connection to hop-by-hop.

Establishing Authority In HTTP, only the URI's authority may process or delegate the request (). This authority model of HTTP remains unchanged under PTTH:

• When the backend server connects to the reverse proxy and requests the transposition of the connection, the backend identifies the reverse proxy using a target URI whose authority component identifies the reverse proxy.
• When the reverse proxy forwards requests to the backend over a transposed connection, it is merely exercising its rights as the authoritative server. This behavior is identical to forwarding requests over connections the reverse proxy initiated, using whatever authentication scheme it chooses. PTTH differs only in how the backend connections are established.

Security Considerations TODO

IANA Considerations Once approved, this document will request IANA to register the following entry to the "HTTP Upgrade Tokens" registry maintained at https://www.iana.org/assignments/http-upgrade-tokens:

Value:

ptth

Description:

Establishes a transposed HTTP/1.1 connection.

Expected Version Tokens:

None

Reference:

this document

References Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. Informative References This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.

Acknowledgments TODO.