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

From: Lucas Pardue <[email-masked]>
Date: Wed, 01 May 2019 06:39:00 -0700

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 01 May 2019 06:43:37 -0700

Agreed.  No reason for this.

> This adds work on the receiver to maintain state while parsing the SETTINGS frame in order to detect duplication

It's a "_MAY_ treat it as an error," so no extra checks are required, the parser can ignore it.

-- 
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#issuecomment-488285589

---

From: ianswett <[email-masked]>
Date: Wed, 01 May 2019 06:48:34 -0700

The text is MUST NOT send and MAY treat as an error, so as @dtikhonov said, you don't have to keep extra state on the parsing side.

I'm happy with the current text, because I don't see a valid use case for sending the same SETTING twice.

-- 
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#issuecomment-488286777

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 01 May 2019 06:58:20 -0700

Closed #2663.

-- 
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#event-2311912839

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 01 May 2019 06:58:20 -0700

> I'm happy with the current text, because I don't see a valid use case for sending the same SETTING twice.

aha right, so because it is only permitted to send one SETTINGS frame, HTTP/3 doesn't need the means to ever handle more than one instance of a parameter.

> The text is MUST NOT send and MAY treat as an error, so as @dtikhonov said, you don't have to keep extra state on the parsing side.

I can live with the MAY. Closing issue.

-- 
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#issuecomment-488289181

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 01 May 2019 06:58:47 -0700

> I'm happy with the current text, because I don't see a valid use case for sending the same SETTING twice.

This is an extra unnecessary MUST NOT.

-- 
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#issuecomment-488289320

---

From: Mike Bishop <[email-masked]>
Date: Wed, 01 May 2019 21:22:02 +0000 (UTC)

In HTTP/2, when SETTINGS can arrive at any time and update anything, the value of a particular setting evolves over time.  You have to be able to handle a setting wandering over the course of a connection, and so having it happen over the course of frame processing isn't actually any different.

In HTTP/3, settings have an initial value before SETTINGS is received, then they get a value once and it's permanent.  You can either mandate that senders construct a "proper" frame, or specify how receivers squash an improper frame; the end result has to be the same, that a setting gets a value once and can't change thereafter.

-- 
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#issuecomment-488434554

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 02 May 2019 03:02:36 -0700

That's a great summary @MikeBishop. The slight grey area for me is the current text:

> A receiver MAY treat the presence of the same parameter more than once as a connection error

This leaves handling up to the receiver with no defined behaviour (which is a fine paradigm). I.e. right now, if you send me duplicate parameters, I pick the last one observed and don't send connection error.

I have no preference for any change to receiver requirement.

-- 
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#issuecomment-488617998

---

From: Mike Bishop <[email-masked]>
Date: Thu, 02 May 2019 09:34:39 -0700

It's a euphemism for "senders: don't do that; receivers: you're not *required* to police but we'd really like it if you did."

-- 
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#issuecomment-488742475

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 May 2019 16:49:05 -0700

Right.  The philosophy behind it being that if we get a small but significant proportion of deployed implementations enforcing it, it will be very hard to deploy a non-compliant implementation.  It turns out that it doesn't take much.

-- 
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#issuecomment-488871625