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

Kazuho Oku <> Mon, 26 August 2019 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7F84120CF0 for <>; Mon, 26 Aug 2019 14:38:18 -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 4h44cBaPOKnb for <>; Mon, 26 Aug 2019 14:38:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0C24120838 for <>; Mon, 26 Aug 2019 14:38:16 -0700 (PDT)
Date: Mon, 26 Aug 2019 14:38:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1566855495; bh=FexvFS/ua3gtWMYs0ukGsONs2fgMGEJJg7Kv7BcEgWY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=udrQqWKzk1fXU+797IjGa3iiSkU80X3myUtbnkRk9YB3NG4kD67orymaS+MfvVmM7 9YyWVl+J2LNi2p8akfjssuXAAynfeDWAsVnscaxHiagnt+SX3lqvdK+b/NWlEOcSqV kZWfs7miWR49H1QdjCp1KNOZrHCeGScHgmTYxI0w=
From: Kazuho Oku <>
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_5d645147e48bd_9453ff2a88cd9642435c3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Mon, 26 Aug 2019 21:38:19 -0000

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