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 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://www.rfc-editor.org/rfc/rfc9110.html#status.2xx> 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://datatracker.ietf.org/doc/html/rfc793>]) to the server identified in the :authority pseudo-header field. Once this connection is successfully established, the proxy sends a HEADERS <https://datatracker.ietf.org/doc/html/rfc9114#frame-headers> frame containing a 2xx series status code to the client, as defined in Section 15.3 <https://www.rfc-editor.org/rfc/rfc9110#section-15.3> of [HTTP <https://datatracker.ietf.org/doc/html/rfc9110>].

And 

> Once the CONNECT method has completed, only DATA <https://datatracker.ietf.org/doc/html/rfc9114#frame-data> 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://datatracker.ietf.org/doc/html/rfc9114#errors> of type H3_FRAME_UNEXPECTED <https://datatracker.ietf.org/doc/html/rfc9114#H3_FRAME_UNEXPECTED>.

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://datatracker.ietf.org/doc/html/rfc9114#frame-data> 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://datatracker.ietf.org/doc/html/rfc9114#errors> of type H3_FRAME_UNEXPECTED <https://datatracker.ietf.org/doc/html/rfc9114#H3_FRAME_UNEXPECTED>.


[1] https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.6