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

Martin Thomson <> Fri, 23 August 2019 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8732F12013F for <>; Thu, 22 Aug 2019 19:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 cYnkUmitoMyT for <>; Thu, 22 Aug 2019 19:22:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33E2312004C for <>; Thu, 22 Aug 2019 19:22:23 -0700 (PDT)
Date: Thu, 22 Aug 2019 19:22:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1566526942; bh=YcIE9OOiCRkYg0lbTXzaHYWZaUGpq3JxGUFlrhzETSc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f+Ee7cb2hciJHe+lwGQHlnM+SycGrsl09bPhBKK/o1AFHKiBgTDbxydCGBtSzGcrt Z0NT5lEh3du16GpAdzMkk/kUG9Ex5YNQScs5r00y10qgj9yq490Wa1UbCSJUFu2sgB UclFFpFNmKtOl3oS+Ucw1Wj2uK1XjdcScluU8N0Y=
From: Martin Thomson <>
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_5d5f4dde732bf_30fa3f82b52cd9641367b7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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 02:22:24 -0000

martinthomson commented on this pull request.

I'm a little concerned about the standoff this permits, but otherwise, I think that this is a good change.

> @@ -2159,6 +2159,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
+to other streams, as it cannot assume the peer's settings to arrive in a timely
+manner.  This is because the packet carrying the settings can be lost, or the

The problem here is that if both endpoints wait for settings from a peer, we have a situation where SETTINGS never gets sent.  If both peers decide to wait, then they wait forever.

Sorry, I wasn't clear that this was the concern in my other comment.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: