It’s not that much the bit overhead but it a) seems just unnecessary, so why not remove it, and b) it’s more the added complexity when the a proxy server that only provides forwarding but no other HTTP servers has to support further HTTP semantics (or even potential future extensions).
Mirja From: Lucas Pardue <[email protected]> Date: Friday, 16. October 2020 at 02:28 To: Mirja Kuehlewind <[email protected]> Cc: Mirja Kuehlewind <[email protected]>, Alex Chernyakhovsky <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Masque] HTTP DATA frames for HTTP CONNECT? 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]<mailto:[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]<mailto:[email protected]>> on behalf of Mirja Kuehlewind <[email protected]<mailto:[email protected]>> Date: Friday, 16. October 2020 at 01:44 To: Lucas Pardue <[email protected]<mailto:[email protected]>>, Alex Chernyakhovsky <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Thursday, 15. October 2020 at 19:35 To: Alex Chernyakhovsky <[email protected]<mailto:[email protected]>> Cc: Mirja Kuehlewind <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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
