Subject: [quicwg/base-drafts] Second SETTINGS frame on any stream other than the control stream error (#2706)

From: Daan De Meyer <[email-masked]>
Date: Thu, 16 May 2019 05:21:17 -0700

> SETTINGS frames always apply to a connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see Section 4.2.1) by each peer, and MUST NOT be sent subsequently or on any other stream. If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type HTTP_WRONG_STREAM. If an endpoint receives a second SETTINGS frame, the endpoint MUST respond with a connection error of type HTTP_UNEXPECTED_FRAME.

It's unclear which error should be reported if an endpoint receives a second SETTINGS frame on any stream that's not a control stream. Perhaps this should be explicitly defined in the draft?

-- 
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/2706

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 May 2019 06:27:10 -0700

Hey @DaanDeMeyer. 

I initially thought this was an editorial problem so created #2710 as an attempt to clarify things.

However, I think the question is more philosophical. To analyse it a bit, what you're asking is how to handle an error after the occurrence of a critical connection error. First, a SETTINGS frame on a wrong stream type, then another SETTINGS frame on a wrong stream.

After the first critical error, all bets are off. I'd expect a lot implementations to just give up at that stage as the peer is likely to be misbehaving. 

-- 
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/2706#issuecomment-493066991

---

From: Daan De Meyer <[email-masked]>
Date: Thu, 16 May 2019 13:43:46 +0000 (UTC)

I agree its an edge case but I do think it'd be useful to exactly specify which of the two errors should be reported, especially when thinking of automated testing of HTTP/3 implementations.

-- 
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/2706#issuecomment-493073074

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 May 2019 06:50:56 -0700

I'm sympathetic to that but I fear this could be a slippery slope towards adding lots of text for issues that occur after a critical close event. PRIORITY frames fall into a similar bucket, along with many of the server push frames and their validation rules.

-- 
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/2706#issuecomment-493075770

---

From: Mike Bishop <[email-masked]>
Date: Thu, 16 May 2019 11:41:42 -0700

Closed #2706 via #2710.

-- 
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/2706#event-2347360663

---

From: Mike Bishop <[email-masked]>
Date: Thu, 16 May 2019 11:44:41 -0700

I think the real unclarity in the spec is that both can happen simultaneously.  After receiving a proper SETTINGS frame on the control channel, receiving a SETTINGS frame on some other stream would be *both* a second SETTINGS frame *and* a SETTINGS frame on the wrong stream.  #2710 clarifies this reasonable.  Thanks, both of you!

-- 
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/2706#issuecomment-493186614