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

Maybe we could find a compromise?

For example, if there was a way to convey Proxy-Status information in a
Capsule we would not depend on trailers and draft-ietf-httpbis-connect-tcp
could support this functionality even for HTTP/1.
This would allow sending non-fatal status updates such as "I will shut down
in 5 minutes, please gracefully migrate the connection".

-yaroslav

On Fri, Feb 6, 2026 at 6:10 PM Ben Schwartz <bemasc@meta.com> wrote:

> 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> 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>
> *Sent:* Thursday, February 5, 2026 7:24 PM
> *To:* HTTP Working Group <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.
>

-- 


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.