Re: [Masque] HTTP DATA frames for HTTP CONNECT?

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]>
Date: Friday, 16. October 2020 at 02:28
To: Mirja Kuehlewind <[e-mail]>
Cc: Mirja Kuehlewind <mirja.kuehlewind=[e-mail]>, Alex Chernyakhovsky <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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, <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Mirja Kuehlewind <mirja.kuehlewind=[e-mail]<mailto:[e-mail]>>
Date: Friday, 16. October 2020 at 01:44
To: Lucas Pardue <[e-mail]<mailto:[e-mail]>>, Alex Chernyakhovsky <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 15. October 2020 at 19:35
To: Alex Chernyakhovsky <[e-mail]<mailto:[e-mail]>>
Cc: Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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