Is the overhead really that bad though? A common case for CONNECT will be to tunnel TLS, so if you assume 16Kbyte records the frame overhead of 3 bytes comes out at ~0.02%.
If you have TCP quarks that are smaller than DATA frames it's a different story. But the solution there is to have a large DATA frame and write into it several times. I'd hope that HTTP/3 implementations can offer streaming frame consumption. Buffering is going to cause all sorts of issues. Extension frames seem like a solid alternative. I know of at least one other proposal for a tighter coupling of DATA-like frame to STREAM. Cheers Lucas Cheers On Fri, 16 Oct 2020, 00:51 Mirja Kuehlewind, <[email protected]> wrote: > Damn, missing „not“ below… meant to say that you need the HTTP framing for > multiplexing in h2 but you don’t need it for that purpose in h3.. > > > > *From: *Masque <[email protected]> on behalf of Mirja Kuehlewind > <[email protected]> > *Date: *Friday, 16. October 2020 at 01:44 > *To: *Lucas Pardue <[email protected]>, Alex Chernyakhovsky < > [email protected]> > *Cc: *"[email protected]" <[email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [Masque] HTTP DATA frames for HTTP CONNECT? > > > > HI Lucas, > > > > RFC7231 defines CONNECT originally like this: > > > > “The CONNECT method requests that the recipient establish a tunnel to > > the destination origin server identified by the request-target and, > > if successful, thereafter restrict its behavior to blind forwarding > > of packets, in both directions, until the tunnel is closed.” > > > > So I would interpret that the connection is not really a HTTP connection > anymore after it has concluded the CONNECT. Again in HTTP/2 this did work > because of multiplexing but in HTTP/3 is would work again and effectively > maybe be the more flexible solution. > > > > Mirja > > > > > > *From: *Lucas Pardue <[email protected]> > *Date: *Thursday, 15. October 2020 at 19:35 > *To: *Alex Chernyakhovsky <[email protected]> > *Cc: *Mirja Kuehlewind <[email protected]>, "[email protected]" > <[email protected]> > *Subject: *Re: [Masque] HTTP DATA frames for HTTP CONNECT? > > > > Hey Mirja, > > > > I'm against allowing unframed bytes on request streams. It limits > extensibility (as pointed out by Alex) and introduces complexity to > conventional HTTP/3 server implementations. HTTP desync attacks are > something that framing protects against, let's not introduce risk for the > sake of optimization. > > > > The good news is that DATA frames can span QUIC packets. So if you're ok > to take the hit once, you can send a very-long DATA frame and just keep > appending data to it. > > > > Cheers > > Lucas >
