HTTP Version Translation of the Capsule Protocol

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 8 May 2025.¶

Copyright Notice

Copyright (c) 2024 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

The Capsule Protocol [RFC9297] defines a framing layer that can be used for protocols running over HTTP. The Capsule Protocol consists of a linear stream of capsules, each with a specified type and size. Endpoints can establish a Capsule Protocol connection using HTTP Extended CONNECT or the HTTP/1.1 Upgrade process.¶

Intermediaries such as HTTP Gateways can play an active role in the Capsule Protocol. To inform intermediaries that this protocol is in use, endpoints can include a "Capsule-Protocol: ?1" header in their request or response. Intermediaries are obligated to pass unrecognized capsule types unmodified, but some capsule types do permit intermediaries to modify them.¶

The Capsule Protocol is defined for HTTP/1.1, HTTP/2, and HTTP/3, and intermediaries can translate Capsule Protocol streams between different versions of HTTP. For example, an HTTP Gateway receiving a request using the "connect-tcp-capsule" Upgrade Token [I-D.ietf-httpbis-connect-tcp] over HTTP/3 might forward it to a backend server using HTTP/1.1 for further processing. However, this translation currently requires the intermediary to recognize the specified Upgrade Token. Unrecognized Upgrade Tokens cannot be translated between HTTP versions.¶

As a result of this limitation, HTTP intermediaries cannot forward unrecognized Capsule Protocol Upgrade Tokens (CPUTs) unless the backend supports the HTTP version used by the client. In practice, such HTTP version mismatches are common, so intermediaries have preferred not to support unrecognized tokens at all. As a result, each new CPUT requires the cooperation of any HTTP intermediaries. This increases the maintenance burden on intermediaries and impedes the deployment of novel CPUTs.¶

This draft specifies general rules for translating Capsule Protocol requests across HTTP versions, allowing intermediaries to perform such translations for unrecognized CPUTs.¶

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

3. Requirements

This section describes requirements on HTTP intermediaries that change the HTTP version of a Capsule Protocol request.¶

4. Implications

Translation of unrecognized CPUTs across HTTP versions carries some implications for future specifications related to the Capsule Protocol:¶

• All CPUTs must treat "GET" in HTTP/1.1 as semantically equivalent to Extended CONNECT.¶

• The "Capsule-Protocol" response header has no effect and should be treated as a hint for later analysis. Intermediaries can process the response as the Capsule Protocol based entirely on the request header and the response status code.¶

• Intermediaries' behavior regarding each capsule type is independent of the CPUT. CPUTs cannot change intermediaries' treatment of existing capsule types.¶

• A Capsule Type or CPUT cannot change the meaning of an HTTP extension. It can only rely on the behaviors that are defined as mandatory for any implementation of that extension. Extensions intended for use with the Capsule Protocol will likely need to define how HTTP version translation works.¶

• Capsule Protocol endpoints are defined independently of the HTTP version, like ordinary HTTP resources. If an origin server's Capsule Protocol support varies between HTTP versions, clients may observe inconsistent behavior when accessing the origin through a compliant intermediary.¶

All existing CPUTs and Capsule Types already conform to these rules.¶

5. Security Considerations

When implemented incorrectly, HTTP/1.1 Upgrade carries a risk of request smuggling. (See [I-D.ietf-httpbis-optimistic-upgrade].)¶

Intermediary implementors should take care to avoid excessive resource consumption by malicious clients. For example, a client might be able to send many short requests over a single HTTP/2 or HTTP/3 connection, each of which requires opening a new, long-lived TCP connection to the backend.¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses