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

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -1330,11 +1330,13 @@ If an endpoint receives a SETTINGS frame on a different stream, the endpoint
 MUST respond with a connection error of type HTTP_WRONG_STREAM.
 
 SETTINGS parameters are not negotiated; they describe characteristics of the
-sending peer, which can be used by the receiving peer. However, a negotiation
-can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a
-set of supported values. The definition of the setting would describe how each
-peer combines the two sets to conclude which choice will be used.  SETTINGS does
-not provide a mechanism to identify when the choice takes effect.
+sending peer, which can be used by the receiving peer. An endpoint MUST NOT wait
+for the peer's SETTINGS frame to arrive before sending it's own SETTINGS frame.

This seems to duplicate the text at 1401-1403 (your version) / 1399-1401 (current PR).  Is there a reason it needs to be in two places, or was there a problem with the wording?

> @@ -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

This appendix is informative; we shouldn't have 2119 requirements here.  (Besides, this is already covered by "Each endpoint MAY use these initial values to send messages before the peer's SETTINGS frame has arrived." on line 1396 / 1394.)  This is a difference from HTTP/2, so it's not unreasonable to mention here, though.

-- 
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#pullrequestreview-279023516