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

[Ryan Hamilton <[e-mail]>]

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
>