Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS

[Lucas Pardue <[e-mail]>]

On Fri, Sep 27, 2019 at 1:52 AM Nick Harper <nharper=
[e-mail]> wrote:

> This also provides opportunities for future features. Since the
> exchange of SETTINGS occurs before application data, a new feature
> doesn’t need to be specified in a way to provide an upgrade path from
> “vanilla” H3 to something including this feature, and instead be
> guaranteed that the new feature can be used for the entire connection.
>
> Without application parameters, each application that needs to
> advertise or negotiate application settings needs its own mechanism to
> do so. This would result in multiple transport parameters or
> extensions leading to duplication of work and layering violations.
> Applications could instead exchange these settings in application
> data, meaning that each application needs to define the semantics of
> application data received before and after the settings have been
> exchanged, as H3 currently does.
>
>
HTTP/3 defines rules for processing its application parameter messages:
SETTINGS frames MUST NOT contain duplicate settings, a receiver MAY treat
this as a connection error with an application error code.

If SETTINGS were to move to QUIC handshake, would you expect that a
receiver of such a bogus message would generate a CONNECTION_CLOSE of type
0x1d? I'm guessing the checks would take place after ALPN selection had
taken place (at the server).