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

Mike Bishop <> Fri, 23 August 2019 14:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0CF21200E5 for <>; Fri, 23 Aug 2019 07:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FvHW1-lJHiE4 for <>; Fri, 23 Aug 2019 07:15:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC99B120047 for <>; Fri, 23 Aug 2019 07:15:02 -0700 (PDT)
Date: Fri, 23 Aug 2019 07:15:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1566569702; bh=//dZHWXUiT6LlErup29NoKN7llWDhE5u58dAx/dAb9g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jRx5UyJi4/libqk0n85FA3QhHJdzzGtDaye2a3P2++U2w8/Sw+HmoICocBxuYAhha xZ/W5KFUAVpXAsfdLecoRffyLirRLL1zsL/VYGorPgVwiiuBwVybuVurWhkZOjj/oF yHajnqHzcNnpRdT3Tnzg9c+99a5gXqlOgPMzzuCc=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2986/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] clarify that an endpoint cannot block on SETTINGS (#2986)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d5ff4e5f3027_28ed3f9acc2cd96c304583"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Aug 2019 14:15:05 -0000

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
+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: