Network Working Group                                           J. Cohen
Internet-Draft                                                      Self
Intended status: Informational                           21 October 2024
Expires: 24 April 2025


                       Symmetric HTTP/2 Extension
                      draft-joshco-symmetric-h2-01

Abstract

   This draft defines an HTTP/2 [RFC9113] 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

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/joshco/sh2.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.







Cohen                     Expires 24 April 2025                 [Page 1]

Internet-Draft                    symh2                     October 2024


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Simplifying Assumption  . . . . . . . . . . . . . . . . .   3
   2.  HTTP/2 Extensions . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  HTTP/2 SETTINGS_SYMMETRIC . . . . . . . . . . . . . . . .   4
     2.2.  Client Authority  . . . . . . . . . . . . . . . . . . . .   4
       2.2.1.  HTTP/2 Authority  . . . . . . . . . . . . . . . . . .   4
       2.2.2.  Client Known URN  . . . . . . . . . . . . . . . . . .   4
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  HTTP/2 Settings Registry Update . . . . . . . . . . . . .   5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  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...

1.1.  Terminology

   This document uses the following terminology.










Cohen                     Expires 24 April 2025                 [Page 2]

Internet-Draft                    symh2                     October 2024


            +========+========================================+
            | 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 | The Agent on the client                |
            | Agent  |                                        |
            +--------+----------------------------------------+
            | Server | The Agent on the server                |
            | Agent  |                                        |
            +--------+----------------------------------------+

                                  Table 1

1.2.  Simplifying Assumption

   A previous draft "Peer-to-peer Extension to HTTP/2" ([P2P]) attempted
   to create bidirectional HTTP/2 extension, but specified that the
   client authority needed to be verified out of band.

   Section 3 of ([P2P]) 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.

2.  HTTP/2 Extensions

   This document overrides HTTP/2 [RFC9113] section 5.1, where it says:





Cohen                     Expires 24 April 2025                 [Page 3]

Internet-Draft                    symh2                     October 2024


      "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.

2.1.  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 [HTTP2] Section 5.4.1) of type PROTOCOL ERROR.

2.2.  Client Authority

2.2.1.  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

2.2.2.  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

3.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.




Cohen                     Expires 24 April 2025                 [Page 4]

Internet-Draft                    symh2                     October 2024


4.  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.

5.  IANA Considerations

5.1.  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.

6.  Normative References

   [HTTP2]    Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9113>.

   [P2P]      Benfield, C., "Peer-to-peer Extension to HTTP/2", Work in
              Progress, Internet-Draft, draft-benfield-http2-p2p-02, 9
              October 2015, <https://datatracker.ietf.org/doc/html/
              draft-benfield-http2-p2p-02>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9113>.

Appendix A.  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 ([P2P]).

Author's Address

   Josh Cohen
   Self



Cohen                     Expires 24 April 2025                 [Page 5]

Internet-Draft                    symh2                     October 2024


   Email: joshco@gmail.com


















































Cohen                     Expires 24 April 2025                 [Page 6]