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
