]> Self

joshco@gmail.com

General Internet-Draft This draft defines an HTTP/2 extension to support Symmetric HTTP, which makes a simplifying assumption that the client-side HTTP server is only accessible and addressible by the server that accepted the HTTP/2 connection. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction This extension allows the client or browser to act as a web server which receives HTTP requests from the origin server and send responses back. This is enabled by allowing server initiated streams to the client. Resources on the client side of an HTTP/2 connection are addressed using a URN prefix. The path /foo on the client is addressed as urn:symmetric_http:client/foo To avoid confusion over terminology...

Terminology This document uses the following terminology.

Term	Definition
Client	The HTTP/2 client that initiates an HTTP/2 connection to a server
Server	The HTTP/2 server that accepts an inbound connection from the client
Agent	An HTTP engine that processes incoming requests and generates responses
Client Agent	The Agent on the client
Server Agent	The Agent on the server

Simplifying Assumption A previous draft "Peer-to-peer Extension to HTTP/2" () attempted to create bidirectional HTTP/2 extension, but specified that the client authority needed to be verified out of band. Section 3 of () states:

• a listener or coalescing intermediary has no in- band method of validating that a dialer's authority claims are valid. Therefore, a conforming listener MUST confirm a dialer's authority claims using some out-of-band method.

This document attempts to sidestep that issue by having the client only accessible, or addressable by the HTTP/2 server that it opened an HTTP/2 connected to. As a result, a real-world authority isn't necessary. Instead the client, known only to the server, is simply the "other side" of an HTTP/2 connection, and is specified according to the Client Authority section of this document.

HTTP/2 Extensions This document overrides HTTP/2 section 5.1, where it says:

• "If this stream is initiated by the server, as described in Section 5.1.1, then receiving a HEADERS frame MUST also be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR."

When operating in symmetric HTTP mode, this restriction is removed.

HTTP/2 SETTINGS_SYMMETRIC This document introduces a new HTTP/2 setting SETTINGS_SYMMETRIC. When SETTINGS_SYMMETRIC (0xTBA) is set to 1, it informs the server that the client supports server initiated streams which carry HTTP/2 requests to the client and responses to the server. This setting MUST NOT be emitted by the server. If the client receives this setting from the server, it must respond with a conection error Section 5.4.1) of type PROTOCOL ERROR.

Client Authority

HTTP/2 Authority In the use of symmetric HTTP, when the server sends an HTTP message to the client agent, the authority header is either:

• Omitted
• Set to the value of TBA_TOKEN

Client Known URN In situations where a client needs to provide a URI to the server, for example to register a subscription, it MUST use the following URN as a prefix. For example, if the client wishes to receive HTTP messages as a specific path, /foo, the URI would be: urn:symmetric_http:client/foo

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.

Security Considerations This document defines the client and client agent to be only accessible and addressable from the HTTP/2 server it has connected to. It is not yet known if there are viable exploits that would allow a third party to access the client agent using symmetric HTTP.

IANA Considerations

HTTP/2 Settings Registry Update This document updates the registry for HTTP/2 Settings to add SETTINGS_SYMMETRIC, ID=0xTBA, which can have a value of 1 or 0.

Normative References This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. This document introduces a negotiated extension to HTTP/2 that turns a single HTTP/2 connection into a bi-directional communication channel. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. 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.

Acknowledgments This document draws wisdom and inspiration from Cory Benfield's Intenet Draft from 2015, "Peer-to-peer Extension to HTTP/2", draft-benfield-http2-p2p-02 ().