Re: [HTTP/3]Sending reserved frame before SETTINGS

[Lucas Pardue <[e-mail]>]

I think the design of this is ok as is.

On Sat, 1 Feb 2020, 22:49 Ian Swett, <ianswett=[e-mail]>
wrote:

> Thanks for bringing this up Renjie.  I agree the subsequent text seems to
> clarify the answer.
>
> However, is that the behavior we want, given it does limit extensibility
> in some small ways?
>
> On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton <[e-mail]> wrote:
>
>> Wow, interesting question!
>>
>> 6.2.1 requires the SETTINGS frame to be first on the control frame:
>>
>>    If the first frame of the control stream is any other frame
>>    type, this MUST be treated as a connection error of type
>>    H3_MISSING_SETTINGS.
>>
>>
>> Whereas 7.2.9 says reserved frames have no semantic meaning:
>>
>>    Frame types of the format "0x1f * N + 0x21" for integer values of N
>>    are reserved to exercise the requirement that unknown types be
>>    ignored (Section 9 <https://tools.ietf.org/html/draft-ietf-quic-http-25#section-9>).  These frames have no semantics, and can be sent
>>    on any open stream when application-layer padding is desired.
>>
>>
>> This sounds like a conflict since something that has no semantics seems
>> like it should not cause errors! However, looking Section 9 I think we find
>> the resolution:
>>
>>    Implementations MUST ignore unknown or unsupported values in all
>>    extensible protocol elements.  Implementations MUST discard frames
>>    and unidirectional streams that have unknown or unsupported types.
>>    This means that any of these extension points can be safely used by
>>    extensions without prior arrangement or negotiation.  However, where
>>    a known frame type is required to be in a specific location, such as
>>    the SETTINGS frame as the first frame of the control stream (see
>>    Section 6.2.1 <https://tools.ietf.org/html/draft-ietf-quic-http-25#section-6...2.1>), an unknown frame type does not satisfy that
>>    requirement and SHOULD be treated as an error.
>>
>>
>> So it seems that it's illegal to send a GREASED frame before the SETTINGS frame. Does that sound right to you?
>>
>>
>> Cheers,
>>
>>
>> Ryan
>>
>>
>> On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang <renjietang=
>> [e-mail]> wrote:
>>
>>> Hi all,
>>>
>>> When I was implementing greasing for HTTP/3 frames, I came across a
>>> potential confusion.
>>>
>>> Presumably, if a non-reserved unknown frame is received before SETTINGS
>>> on a control stream, the connection should be closed.
>>>
>>> But if a reserved frame is received before SETTINGS frame on a control
>>> stream, does it count as an error and close the connection? Or should
>>> it simply be ignored because it has no semantic meaning?
>>>
>>> Thanks!
>>> Renjie
>>>
>>