[quicwg/base-drafts] Why is SETTINGS parameter duplication a connection error? (#2663)

[Lucas Pardue <[e-mail]>]

In draft 01 it was ok to send duplicate parameters in the same frame, in draft 02 several changes were introduced to settings and the changelog links to #181. However, most of the discussion there was about putting SETTINGS in QUIC TP, so it isn't clear why duplication is so problematic.

The old 01 text made sense:

```
   Each parameter in a SETTINGS frame replaces any existing value for
   that parameter.  Parameters are processed in the order in which they
   appear, and a receiver of a SETTINGS frame does not need to maintain
   any state other than the current value of its parameters.  Therefore,
   the value of a SETTINGS parameter is the last value that is seen by a
   receiver.
```

These days the draft says:

```
   Parameters MUST NOT occur more than once in the SETTINGS frame.  A
   receiver MAY treat the presence of the same parameter more than once
   as a connection error of type HTTP_MALFORMED_FRAME.
```

This adds work on the receiver to maintain state while parsing the SETTINGS frame in order to detect duplication, which is kind of annoying when we consider that the contents of unknown SETTINGS identifiers should be ignored.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2663