Re: [quicwg/base-drafts] Close in response to invalid CONNECTION_CLOSE (#3230)

MikkelFJ <> Tue, 12 November 2019 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDCE412011C for <>; Tue, 12 Nov 2019 05:09:35 -0800 (PST)
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 iXdaKN1QS8av for <>; Tue, 12 Nov 2019 05:09:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED69C1200DB for <>; Tue, 12 Nov 2019 05:09:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3F5B86E0A6D for <>; Tue, 12 Nov 2019 05:09:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573564173; bh=C/m0imhWKio5hlQBXbFT+2foPRwO+8s+qQzdQ8iF9LA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uFDQdIjRiPqjLWSFiXvNhrXwJC6IdwD0N03BaMPv9FVFX6z7M+z4J/cClK9hh3wnH M/urWbCEQrmw0IiPDeXP8zDoIwRTQo/ClEmsqf+BCjGU34pP7J9YqyZn5rRZfNyWkA yH/XGr8HuokF8eErKhR0zVsMZNo/qf0s7+l+Z/cs=
Date: Tue, 12 Nov 2019 05:09:33 -0800
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3230/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Close in response to invalid CONNECTION_CLOSE (#3230)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dcaaf0d2fa67_78b3f99e22cd95c2225369"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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: Tue, 12 Nov 2019 13:09:36 -0000

mikkelfj commented on this pull request.

> @@ -2709,8 +2710,10 @@ frame risks a peer missing the first such packet.  The only mechanism available
 to an endpoint that continues to receive data for a terminated connection is to
 use the stateless reset process ({{stateless-reset}}).
-An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the
-existence of the error to its peer.
+An endpoint that receives an invalid CONNECTION_CLOSE frame MUST treat the
+message as being equivalent to a CONNECTION_CLOSE with the INTERNAL_ERROR error
+code.  The endpoint MAY send a single CONNECTION_CLOSE in response, but it MUST
+then enter the draining period; see {{draining}}.

Would INTERNAL_ERROR not suggest a locally induced inconsistent state as opposed to an observed remote inconsistent state? If so, I think it is important to make a distinction since it affects who is to blame and consequently where to debug.

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