Re: [quicwg/base-drafts] Ambiguous wording about error codes in HTTP/3 (#3276)

Dmitri Tikhonov <> Wed, 04 December 2019 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85547120886 for <>; Wed, 4 Dec 2019 08:38:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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, URIBL_BLOCKED=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 rdBalHSOY0Av for <>; Wed, 4 Dec 2019 08:38:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 140E012080B for <>; Wed, 4 Dec 2019 08:38:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EED93661114 for <>; Wed, 4 Dec 2019 08:38:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1575477527; bh=riqaOIa6WRplJW5rmbpNXyet5cHKJ42NMJQYv1gMj8E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pu9k//cMTC0wYJr8ZqK8S9rQOQZH7i550PW1/kQprMRHntfK2pXwnWJ9Qrfj/otPT BWsnpHC5jwkwZ17JyBaEp9mkCV5J/7rlUXiRpBV5E4MSMbkZdSaDtZwZEFTR383LRk d4F3FAO3u/iDs96jCJ9fgNU4r9RGXkOMFXNLm6eE=
Date: Wed, 04 Dec 2019 08:38:47 -0800
From: Dmitri Tikhonov <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3276/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Ambiguous wording about error codes in HTTP/3 (#3276)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5de7e117e0517_2c083fa17d4cd96c1306c1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: dtikhonov
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: Wed, 04 Dec 2019 16:38:51 -0000

The paragraph in question (see [HTTP draft, section 8]( talks about different things:

   Because new error codes can be defined without negotiation (see
   Section 9), receipt of an unknown error code or use of an error code
   in an unexpected context MUST NOT be treated as an error.  However,
   closing a stream can constitute an error regardless of the error code
   (see Section 4.1).

Let's break it up to make it easier to talk about:

1. Treating an unexpected error code as an error is not allowed, in particular:
a. Receiving unknown error is not an error in itself (a "further" error); and
b. Receiving an unexpected error code (known or unknown) is not an error.
1. A stream close may be an error independent of error code.

Item 1(a) follows from Section 9.  This does not need to be stated here.

Item 1(b) seems to suggest that error codes are not to be used to make decisions, for they could be anything, notwithstanding all the "MUST treat as error type" admonitions elsewhere in the code.  (This is what the text implies, which may not be what was intended.)

Item 2 says that some error occur due to changes in stream state and are not communicated via an error code from peer.

I would drop Items 1(a) and 1(b); Item 2 can be rephrased.

P.S. Given the loose treatment given to error codes by their recipient, it is logical to allow their sender to keep on treating specified errors as errors ("MUST treat as error..."), but allow setting the error codes to anything.  Stating that "MUST treat as error of type X and SHOULD set error code to X" sounds awkward; perhaps this guidance could be added to Section 8 as a new item.

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