Re: HTTP/3 CONNECT requests, body, and trailers

As a Proxy-Status enthusiast, I think (3) would be poor outcome.  RFC 9209 specifically lays out use cases for Proxy-Status trailers.  These seem potentially useful for any long-lived request through a proxy, including CONNECT.  For example, Proxy-Status could be used to convey details that distinguish the reason for an ungraceful shutdown, which is useful for debugging but is otherwise lost (Was it a TCP timeout? A RST?  Did the connection duration reach a configured limit?  Is this proxy server shutting down?).

If we ban trailers, we currently have no way to convey this information.

None of this prevents the endpoints from negotiating "unbounded DATA" if they don't have a use for trailers.

--Ben
________________________________
From: Yaroslav Rosomakho <yrosomakho@zscaler.com>
Sent: Friday, February 6, 2026 12:53 PM
To: Ben Schwartz <bemasc@meta.com>
Cc: Lucas Pardue <lucas@lucaspardue.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTP/3 CONNECT requests, body, and trailers

As an unbound DATA for CONNECT enthusiast, I strongly support option (3) -yaroslav On Fri, Feb 6, 2026 at 2: 29 PM Ben Schwartz <bemasc@ meta. com> wrote: If we're going to revisit this text, let's give some thought to the interaction

As an unbound DATA for CONNECT enthusiast, I strongly support option (3)

-yaroslav

On Fri, Feb 6, 2026 at 2:29 PM Ben Schwartz <bemasc@meta.com<mailto:bemasc@meta.com>> wrote:
If we're going to revisit this text, let's give some thought to the interaction with Extended CONNECT.  For example, can the set of allowed frames vary based on the :protocol?

draft-ietf-httpbis-connect-tcp currently says
"In HTTP/2 or HTTP/3, proxies MAY   additionally send a "Proxy-Status" trailer in the event of an abrupt   stream closure."

We probably need to (1) remove this restriction altogether for Extended CONNECT, (2) declare that a :protocol specification can relax this restriction, or (3) flip this MAY to a MUST NOT in draft-ietf-httpbis-connect-tcp.

--Ben
________________________________
From: Lucas Pardue <lucas@lucaspardue.com<mailto:lucas@lucaspardue.com>>
Sent: Thursday, February 5, 2026 7:24 PM
To: HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: HTTP/3 CONNECT requests, body, and trailers

On Thu, Feb 5, 2026, at 23: 54, Martin Thomson wrote: On Fri, Feb 6, 2026, at 06: 58, Lucas Pardue wrote: > Alex beat me to what I was going to say here. The proposed text could > be wordsmithed more I guess. Still not convinced this is


On Thu, Feb 5, 2026, at 23:54, Martin Thomson wrote:
On Fri, Feb 6, 2026, at 06:58, Lucas Pardue wrote:
> Alex beat me to what I was going to say here. The proposed text could
> be wordsmithed more I guess. Still not convinced this is a huge spec
> problem though (the protocol-level requirements are correct IMO, just
> maybe not super obvious on first inspection but what is?)

You are both right, of course.  This did seem editorial, but the 2xx/200 question below might tip that further toward being technical.

Is it 2xx that has no response body, or is it only 200?  I don't know if we ever really decided that.

RFC 9110 says:

> Any 2xx (Successful)<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9110.html*status.2xx__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj5S_rYR8$> response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the response header section; data received after that header section is from the server identified by the request target. Any response other than a successful response indicates that the tunnel has not yet been formed.

And

> A CONNECT request message does not have content. The interpretation of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use.


> A CONNECT request consists of a header block only and cannot contain a body or trailers; similarly, a 200 response to a CONNECT requests consists of a header block only.  Other responses to a CONNECT request are normal HTTP responses and can contain a body (that can explain why a request failed, for example).


Its still not clear to me what document a change is being proposed. Restating things from document to document is where misunderstandings can creep in.

RFC 9114 says

> A proxy that supports CONNECT establishes a TCP connection ([RFC0793<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc793__;!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8ljx3hK6MA$>]) to the server identified in the :authority pseudo-header field. Once this connection is successfully established, the proxy sends a HEADERS<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9114*frame-headers__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj1Sy_j0D$> frame containing a 2xx series status code to the client, as defined in Section 15.3<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9110*section-15.3__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj0TRg1EY$> of [HTTP<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9110__;!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj8VFkGJn$>].

And

> Once the CONNECT method has completed, only DATA<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9114*frame-data__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj0L0pqXk$> frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension. Receipt of any other known frame type MUST be treated as a connection error<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9114*errors__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj0ftm5sF$> of type H3_FRAME_UNEXPECTED<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9114*H3_FRAME_UNEXPECTED__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj8HVdy0c$>.

So a minimal change would be

A) Invent a better term for returning a 2xx and state it clearly in the para that talks about 2xx

B) Change that second para to something like

CONNECT method requests that are <insert new term for successful connect> do not support trailer header section. Only DATA<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9114*frame-data__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj0L0pqXk$> frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension. Receipt of any other known frame type MUST be treated as a connection error<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9114*errors__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj0ftm5sF$> of type H3_FRAME_UNEXPECTED<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9114*H3_FRAME_UNEXPECTED__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj8HVdy0c$>.


[1] https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.6<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9110.html*section-9.3.6__;Iw!!Bt8RZUm9aw!93J7ZKDdhG3zB_wibixsN2xja0LcFSf5FIKXUkRRK6ATZ5BptTSL1JtZr7exEMG4LC8lj1pO2PqD$>



This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.