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

[Ian Swett <[e-mail]>]

Alan and Mike answered my question on a different channel, from
https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-http.md#frame-layout

Each frame's payload MUST contain exactly the fields identified in its
description. A frame payload that contains additional bytes after the
identified fields or a frame payload that terminates before the end of the
identified fields MUST be treated as a connection error ({{errors}}) of
type H3_FRAME_ERROR.

So we just need to write up an extension draft.

On Tue, Oct 20, 2020 at 6:05 PM Ian Swett <[e-mail]> wrote:

> I'm coming to this conversation late in the game, but this was discussed
> fairly extensively on https://github.com/quicwg/base-drafts/issues/1885
>
> And I do believe it's an annoyance, since adding an extra layer of framing
> can greatly increase code complexity, harm performance, or both.
>
> However, now that I re-read the HTTP draft, I wonder if it's legal to send
> a DATA frame with a huge size and then let the QUIC stream close?  I
> couldn't find any text specifically describing what to do in the case where
> the DATA frame length does not match the number of bytes read prior to the
> QUIC stream being closed, but possibly I missed something.  If this is
> allowed, it seems functionally equivalent to the proposal to treat 0 length
> DATA frames as terminated when the stream is closed.
>
> Ian
>
> On Mon, Oct 19, 2020 at 7:26 AM Lucas Pardue <[e-mail]>
> wrote:
>
>> The library doesn't inspect request methods. Doing so for CONNECT would
>> create a disparity, which is an excellent way to create bugs.
>>
>>
>>>
>>>