



Protocol for Transposed Transactions over HTTP                M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                       26 September 2025
Expires: 30 March 2026


                         Potato - Reverse HTTP
                      draft-thomson-ptth-potato-00

Abstract

   This document defines 🥔, a suite of reversed versions of HTTP for
   origin servers.

About This Document

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

   The latest revision of this draft can be found at
   https://martinthomson.github.io/potato/draft-thomson-ptth-
   potato.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-thomson-ptth-potato/.

   Discussion of this document takes place on the Protocol for
   Transposed Transactions over HTTP Working Group mailing list
   (mailto:ptth@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ptth/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/ptth/.

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

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 30 March 2026.

Copyright Notice

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

   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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction
     1.1.  Comparative Notes
   2.  Conventions and Definitions
   3.  Overview and Scope
   4.  Reversed HTTP
     4.1.  Reversed HTTP/1.1
     4.2.  Reversed HTTP/2
     4.3.  Reversed HTTP/3
   5.  Authenticating and Authorizing Origin Servers
     5.1.  TLS Client Certificates
     5.2.  HTTP Request
     5.3.  Authorization for Limited Path Scope
   6.  Authenticating Gateways
   7.  TLS Early Data
   8.  Scalability, Availability, and Connection Management
   9.  Security Considerations
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgments
   Author's Address

1.  Introduction

   Operating an HTTP server that is accessable on the public internet
   creates an unmanageable risk of denial of service for many
   organizations, especially smaller operators.  Content delivery
   networks (CDNs) are able to provide a measure of protection, but
   their services typically operate as gateways, which require that the
   origin server be reachable.

   An alternative deployment model has emerged as a means of addressing
   this concern, where, rather than have the gateway initiate a
   connection to the origin, the origin connects to the gateway.

   +--------+     +---------+      +----------+    +--------+
   | Client |     | Gateway |      | Firewall |    | Origin |
   +---+----+     +----+----+      +----+-----+    +---+----+
       |               |                |              |
       |               |<================ connect 🥔 ===+
       |               |                |              |
    ~~~~~~~~~~~~~~~~~~~~ some time later ~~~~~~~~~~~~~~~~~~~
       |               |                |              |
       +-- request --->|                |              |  | messages
       |               +-- request ------------------->|  | exchanged
       |               |                |              |  | over
       |               |<------------------ response --+  | existing
       |<-- response --+                |              |  | connection
       |               |                |              |

   This arrangement greatly simplifies the configuration of firewalls,
   which are better able to authorize outward-bound connections.

   This document defines alternative, "reversed", versions of HTTP
   [HTTP] protocols.  These protocols are all nearly identical to their
   "forward" counterparts, with the exception that the client and server
   roles are inverted after completing the transport and TLS layer
   establishment.

   This document defines reversed equivalents to HTTP/1.1 [HTTP/1.1],
   HTTP/2 [HTTP/2], and [HTTP/3].

1.1.  Comparative Notes

   This is one of a set of different options in this space.  Other
   designs include reverse tunnels [I-D.kazuho-ptth-ptth] and reverse
   HTTP transport [I-D.bt-httpbis-reverse-http].

   These alternatives are all broadly capable of achieving the goal.

   Key points of divergence exist around the use of tunnels (for reverse
   tunnels) and how different roles are authenticated and authorized.

   There are some minor differences in use of terminology, which need to
   be cleared up.

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

   This document uses terminology from [HTTP].

   Because having roles reversed can be especially confusing, this
   document tries to be consistent in its use of language.

   The terms _client_ and _server_, when unqualified, refer to the HTTP
   client and HTTP server roles respectively.

   In this document, a _gateway_ will generally be the HTTP client and
   an _origin server_ will generally be the HTTP server.  These terms
   will be used where it makes sense.

   Where it is necessary to identify a client or server role outside of
   the context of reversed HTTP, the term will be qualified.  This
   typically will use the protocol where the role is used.  For example,
   "TLS client role" or "acting as QUIC client".

3.  Overview and Scope

   This document describes how to establish reversed HTTP connections.

   The overall approach is to allocate new Application-Layer Protocol
   Negotiation (ALPN) [ALPN] identifiers to each reversed HTTP version.

   The origin server acts in the client role for establishing the
   transport and security layers of a connection to the gateway, which
   provides a server for those layers.  That is, for HTTP/1.1 and
   HTTP/2, the origin server is the TCP and TLS client and the gateway
   is the TCP and TLS server.  For HTTP/3, the origin server is the QUIC
   client and the gateway is the QUIC server.

   If the gateway selects the reversed HTTP version in the protocol
   negotiation, the corresponding HTTP version is conducted with the
   usual roles reversed.  The gateway becomes the HTTP client and the
   origin server becomes the HTTP server.  No other changes are made to
   the protocol.

   The document explores some of the implications of this design,
   including authorization (Section 6 and Section 5), and interactions
   with some protocol features.  However, there are numerous factors
   that are relevant when choosing an appropriate server deployment
   architecture.  This document will address only those that are
   relevant to the design of the protocol and essential to its secure
   and correct operation.

   This document does not define a protocol that allows both endpoints
   to make requests over the same connection.  Separate connections can
   be used if requests need to be exchanged in both directions.

4.  Reversed HTTP

   This section defines the basic operation of reversed HTTP for each
   major HTTP version.

   All versions of reversed HTTP require special handling for questions
   of server authority.  Authorizing the origin server is discussed in
   Section 5.  Similarly the means by which a gateway authorizes an
   origin server are discussed in Section 5.

   Most HTTP features, including extensions to specific HTTP versions,
   are unaffected by the reversal of the protocol.

   Only those features that depend on lower protocols layers that also
   depend on assumptions about how the the TLS or transport-layer role
   relates to the HTTP client or server role.  Such features cannot be
   used without additional profiling.

   The features that cannot be used with reversed HTTP include: the
   Client-Cert HTTP field [RFC9440].

   A small adjustment to the operation of the HTTP/3 Datagram extension
   [HTTP-DGRAM] is described in Section 4.3.

4.1.  Reversed HTTP/1.1

   A reversed version of HTTP/1.1 [HTTP/1.1] is identified by the ALPN
   label "rh1".

   To negotiate the use of reversed HTTP/1.1 protocol, an origin server
   advertises the "rh1" token in its TLS handshake using ALPN [ALPN] and
   a gateway selects that token.

   Once a TLS connection is established, the origin server (as a TLS
   client) becomes the HTTP server and the gateway (as TLS server)
   becomes the HTTP client.  Messages sent by the gateway are HTTP
   requests and messages from the origin server are HTTP responses.

   HTTP/1.1 depends only on an undifferentiated stream of bytes.  No
   special considerations apply to this version.

4.2.  Reversed HTTP/2

   A reversed version of HTTP/2 [HTTP/2] is identified by the ALPN label
   "rh2".

   To negotiate the use of reversed HTTP/2 protocol, an origin server
   advertises the "rh2" token in its TLS handshake using ALPN [ALPN] and
   a gateway selects that token.

   Once a TLS connection is established, the origin server (as a TLS
   client) becomes the HTTP/2 server and the gateway (as TLS server)
   becomes the HTTP/2 client.  Each send a preface (Section 3.4 of
   [HTTP/2]) and establishes an HTTP connection.

   HTTP/2 depends only on an undifferentiated stream of bytes.  No
   changes are necessary to the base protocol.

   In operation, the gateway (as HTTP/2 client) initiates requests on
   odd-numbered streams.  Any push promises from the origin server (as
   HTTP server) are sent on even-numbered streams.

4.3.  Reversed HTTP/3

   A reversed version of HTTP/3 [HTTP/3] is identified by the ALPN label
   "rh3".

   To negotiate the use of reversed HTTP/3 protocol, an origin server
   advertises the "rh3" token in its QUIC handshake using ALPN [ALPN]
   and a gateway selects that token.

   Once a QUIC connection is established, the origin server (as a QUIC
   client) becomes the HTTP/3 server and the gateway (as QUIC server)
   becomes the HTTP/3 client.  Each send a preface (Section 3.4 of
   [HTTP/2]) and establishes an HTTP connection.

   Unlike HTTP/2, the streaming layer that HTTP/3 uses is provided by
   QUIC.  Therefore, the identifiers given to streams change.  This
   should not be visible to the HTTP/3 layer; the HTTP/3 design
   generally does not depend on stream identifiers being in any
   particular form.

   One exception to this is the Quarter Stream ID concept introduced in
   Section 2.1 of [HTTP-DGRAM].  Because requests in reversed HTTP/3 are
   made on bi-directional, server-initiated streams, those identifiers
   end with two bits (0b01); see Section 2.1 of [QUIC].  To construct a
   Quarter Stream ID from a stream identifier, any remainder is
   discarded.  To construct a stream identifier from a Quarter Stream ID
   in reversed HTTP/3, the value is multiplied by 4, then the stream
   type (0b01) is added.  This adjustment only requires an understanding
   of the type of QUIC stream that the HTTP client uses to make
   requests.

   Any extension that makes similar assumptions about the structure of
   stream identifiers can be adjusted in a similar manner.

5.  Authenticating and Authorizing Origin Servers

   Arrangements between gateways and origin servers are often privately
   arranged.  Therefore, how a gateway chooses to authorize an origin
   server does not necessarily benefit from having a single, standard
   mechanism.

   This section describes a few options for origin server
   authentication.  None of these approaches is mandated, as it is
   expected that private arrangements will be used in most deployments.

5.1.  TLS Client Certificates

   TLS client certificates can be used to authenticate TLS clients.
   That authentication could be used as the basis of authorization.

   The choice of how to authenticate a client certificate is complex.
   Multiple options are possible, each with different operational and
   deployment properties:

   *  The gateway could use the same public key infrastructure (PKI) as
      the certificate that the gateway itself offers (see Section 6).

   *  A completely separate PKI could be used.  This includes a PKI
      managed by the gateway.

   *  Self-signed certificates could be mapped to specific
      authorizations.

   This option might introduce some challenges in deployment.  Because
   the TLS connection that is established to the gateway uses the same
   endpoint that other clients, the TLS server software needs to make
   its protocol selection before deciding to request a client
   certificate.

5.2.  HTTP Request

   Once a reversed HTTP connection is established, the gateway could
   make a request to a pre-arranged resource.

   This request could be used to retrieve a bearer token that authorizes
   the origin server.  A more complex request might involve the origin
   server producing a signed object that covers a challenge produced by
   the gateway.  Responding to a challenge is a defense against the
   possibility of an attack that captures and replays a bearer token.

   TODO: Should this document define a protocol?

5.3.  Authorization for Limited Path Scope

   A gateway does not need to authorize an origin server to serve all
   requests for an origin.  Nor does a gateway need to limit its
   authorization to a single origin.

   The choice of which requests are forwarded to an origin server is a
   matter for gateway policy.  That policy might be guided by the choice
   of credential presented by the origin server.

   For instance, if a HTTP request is used to authorize the origin
   server, the response might include information that guides the
   gateway in determining which requests are forwarded over the
   connection.  This could be as simple as having the origin server list
   path prefixes that it can serve or it could be bound to the
   credentials that are offered.

   This might be used to enable different deployment architectures where
   the one logical origin server is distributed across multiple
   instances, with different paths being served by different hosts.

   This approach is also compatible with a gateway that makes regular
   HTTP connections to some origin server nodes.  A gateway might
   forward requests for the one origin to origin servers that use both
   regular and reversed HTTP based on whatever policy it chooses.

6.  Authenticating Gateways

   An origin server MUST authenticate a gateway unless an alternative
   means of authentication is privately arranged.

   In all reversed HTTP versions, when the the origin server establishes
   a TLS connection to the gateway, it confirms the identity of the
   gateway according to the rules of the respective, non-reversed, HTTP
   version.

   The rules in Section 4.3 of [HTTP] regarding how clients determine
   whether a server can answer a request are applied in reverse.  That
   is, an origin server that cannot successfully determine that a
   gateway is authoritative for resources MUST NOT answer requests from
   that gateway.

   Because the server and client roles are reversed, some methods for
   expanding the scope that a server can claim authority are
   invalidated.  Mechanisms like the ORIGIN frame [ORIGIN] remain valid
   as a means of limiting scope.

   These requirements do not exist to provide protection against
   impersonation, which is generally the reason to require that a server
   establish authority.  They exist to protect things like the
   confidentiality of responses.

   TODO: For discovery, should this use generic SVCB records, HTTPS
   records, or a new RR type?  It seems like HTTPS will work just fine
   for this.

7.  TLS Early Data

   A gateway can use TLS session resumption to make establishing
   connections more efficient.  This includes the possibility of
   enabling TLS early data.

   Unlike in regular HTTP where a client can use TLS early data to make
   a request, reversed HTTP gives the server an opportunity to speak
   first.  This has little value, as an HTTP server generally has to
   wait for requests.

   This provides similar properties to the first flight of server
   application data in a TLS 1.3 connection without early data.  There,
   the server is able to send first.

   Though that data has no replay risk, the data that a server might
   send in any HTTP version without a request is unlikely to produce
   side effects that might be a problem if replayed.

   An origin can use early data to reduce the latency of settings or
   pre-populate header compression state.  These both only apply to
   HTTP/2 and HTTP/3.  These uses can avoid any replay attack risk, as
   these do not cause side effects beyond the connection state.

   For a gateway, the first flight of application data can be used to
   make requests.  However, this data is sent prior to receiving client
   certificates if those are used to authorize the origin server; see
   Section 5.1.  This flight might be used for making a request to
   authorize the origin server; see Section 5.

8.  Scalability, Availability, and Connection Management

   A gateway that is configured to make connections to an origin server
   is able to make connections as needed.  Having the origin server be
   responsible for connection establishment can mean that the gateway
   cannot rely on being able to make new connection as demand increases.

   This can mean that origin servers have a greater control over their
   availability and service scaling.  Where an origin server that might
   need to scale up to handle increased demand might otherwise need to
   arrange for load balancing infrastructure, that becomes something
   that the gateway assumes more responsibilty for.

   As a passive participant, a gateway is not able to act if an origin
   server goes offline.  The origin server is responsible for
   establishing connections when it becomes available.

   This can present scaling challenges as a gateway cannot make
   additional connections on the assumption that origin servers will
   scale to meet increased demand.  Gateways can attempt to make
   additional requests over existing connections, but origin servers can
   use protocol features designed to limit resource commitment -- such
   as stream limits and flow control -- to manage load.

   This document does not define any mechanism that might allow the
   gateway to communicate changes in demand for capacity to origin
   server instances.  Defining mechanisms to help with adding or
   removing capacity on demand is a matter for future work.

   The use of reversed HTTP/1.1 presents particular difficulty for
   connection management, which is borne by the origin server.  The lack
   of any concurrency features in that protocol means that origin
   servers likely need to manage a pool of connections if the gateway
   needs to handle requests with any amount of concurrency or volume.

9.  Security Considerations

   Using reversed HTTP changes the denial of service profile for origin
   servers that rely on it.  Such servers are able to use different
   tools to manage their reachability.

   A gateway becomes a more central part of managing load, but the
   gateway no longer has direct control over connection establishment.
   This alters how gateways and origin servers need to be configured to
   handle scaling, availability, and connections; see Section 8 for
   details.

   Other than these changes, the security considerations of HTTP and the
   specific HTTP version in use apply in full.

10.  IANA Considerations

   TODO: Register ALPN labels.

11.  References

11.1.  Normative References

   [ALPN]     Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.

   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [HTTP-DGRAM]
              Schinazi, D. and L. Pardue, "HTTP Datagrams and the
              Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
              2022, <https://www.rfc-editor.org/rfc/rfc9297>.

   [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

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

   [HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

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

11.2.  Informative References

   [I-D.bt-httpbis-reverse-http]
              Schwartz, B. M., Reddy.K, T., Boucadair, M., and P. S.
              Tiesel, "Reverse HTTP Transport", Work in Progress,
              Internet-Draft, draft-bt-httpbis-reverse-http-01, 23
              October 2023, <https://datatracker.ietf.org/doc/html/
              draft-bt-httpbis-reverse-http-01>.

   [I-D.kazuho-ptth-ptth]
              Oku, K., "Protocol for Transposed Transactions over HTTP",
              Work in Progress, Internet-Draft, draft-kazuho-ptth-ptth-
              00, 25 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-kazuho-ptth-
              ptth-00>.

   [ORIGIN]   Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
              RFC 8336, DOI 10.17487/RFC8336, March 2018,
              <https://www.rfc-editor.org/rfc/rfc8336>.

   [RFC9440]  Campbell, B. and M. Bishop, "Client-Cert HTTP Header
              Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
              <https://www.rfc-editor.org/rfc/rfc9440>.

Acknowledgments

   This draft is based on discussions with many people.

   Kazuho Oku

   Additional contact information:

      奥 一穂


   and Andrew McGregor both made helpful contributions.

Author's Address

   Martin Thomson
   Mozilla
   Email: mt@lowentropy.net
