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

[Ian Swett <[e-mail]>]

Thinking more, I don't think we're losing much with this restriction, so
I'm fine with it as is.

On Tue, Feb 4, 2020 at 4:44 AM Mike Bishop <[e-mail]> wrote:

> Yes, this text was added to record our decision when this question came up
> before.  An unknown frame is not SETTINGS.  If you define something new
> (EXTENDED_SETTINGS_REBORN), you can very well mandate that it be the next
> frame *after* SETTINGS, but it is not a SETTINGS frame and doesn’t
> satisfy the expectation to see a SETTINGS frame there.
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of * Lucas Pardue
> *Sent:* Sunday, February 2, 2020 12:34 PM
> *To:* Ian Swett <ianswett=[e-mail]>
> *Cc:* IETF QUIC WG <[e-mail]>; Ryan Hamilton <[e-mail]>;
> Renjie Tang <renjietang=[e-mail]>
> *Subject:* Re: [HTTP/3]Sending reserved frame before SETTINGS
>
>
>
> I think the design of this is ok as is.
>
>
>
> On Sat, 1 Feb 2020, 22:49 Ian Swett, <ianswett=[e-mail]
> <[e-mail]..org>> 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
>
>