Re: [quicwg/base-drafts] clarify that an endpoint cannot block on SETTINGS (#2986)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> @@ -2159,6 +2161,12 @@ the settings identifier space in HTTP/3 is substantially larger (62 bits versus
 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See
 {{iana-settings}}.
 
+An endpoint SHOULD NOT wait for the peer's settings to arrive before responding

Yeah I now think that there is an issue in PR #2972.

It says that the sender SHOULD send SETTINGS, the receiver MAY use the initial value before receiving SETTINGS. We have a chance of deadlock by allowing the sender to not send SETTINGS, and the receiver to block on the receipt of SETTINGS.

d71650f resolves the deadlock by changing that to "MUST send SETTINGS". It also changes the recommendation on the receiver side to *not* block on SETTINGS as well as clarifying why. The normative text is moved into the main chapter, the appendix refers to 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/pull/2986#discussion_r317810121