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

Hi Martin,



On Thu, Feb 5, 2026, at 01:39, Martin Thomson wrote:
> RFC 9114 says:
> 
> > The request stream remains open at the end of the request to carry the data to be transferred. A CONNECT request that does not conform to these restrictions is malformed.
> 
> -- https://datatracker.ietf.org/doc/html/rfc9114#section-4.4-5
> 
> Reading on a little more, it's clear that the request we're talking about isn't a normal "headers, body, trailers" request, but you might be forgiven for starting to think otherwise.
Right. I think we came to the same conclusion in RFC 9297 and defined a "data stream" term to use in the context of the capsule protocol. [1]
> 
> Would it be worth an editorial erratum?
Maybe
> 
> I'd suggest the addition:
> 
> > A CONNECT request consists of a header block only, it cannot contain a body; similarly a CONNECT response consists of a header block only.  CONNECT requests and responses can include trailers, however the use of trailers is inadvisable. Trailers can interfere with the closing of the associated TCP connection as they have to be sent prior to signaling connection close.
I don't follow this all sorry. There's no header block in H3, perhaps you mean "encoded field section"? More seriously, I don't understand how trailers are supported since RFC 9114 section 4.4 states

> 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.
> The text in HTTP/2 is a little better in this regard, but the note about trailers does apply there as well.  (https://datatracker.ietf.org/doc/html/rfc9113#section-8.5)
> 
> 
This section also states

> Frame types other than DATA <https://datatracker.ietf.org/doc/html/rfc9113#DATA> or stream management frames (RST_STREAM <https://datatracker.ietf.org/doc/html/rfc9113#RST_STREAM>, WINDOW_UPDATE <https://datatracker.ietf.org/doc/html/rfc9113#WINDOW_UPDATE>, and PRIORITY <https://datatracker.ietf.org/doc/html/rfc9113#PRIORITY>) MUST NOT be sent on a connected stream and MUST be treated as a stream error <https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler> (Section 5.4.2 <https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler>) if received.

Maybe I'm overlooking what your proposal is. Is there an edge case affecting those rules?

Cheers
Lucas
[1] https://www.rfc-editor.org/rfc/rfc9297.html#section-3.1