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

[Lucas Pardue <[e-mail]>]

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