Re: [quicwg/base-drafts] Grease HTTP error codes (#3360)

Lucas Pardue <> Tue, 21 January 2020 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98DE71200F7 for <>; Tue, 21 Jan 2020 05:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Status: No, score=-7.998 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_32=0.001, 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 jSgXIwd2tuBH for <>; Tue, 21 Jan 2020 05:10:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD2F81208A6 for <>; Tue, 21 Jan 2020 05:10:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A471D8C0DC8 for <>; Tue, 21 Jan 2020 05:09:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579612199; bh=tKgxm6yPSAwDy4EMW0JVLdjwKt8aMB01j8FQk4jdUck=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pbL6akMblDyjuL+YwIj8qFpar/4cGU2atkjcPRPvL7O0l2dJNWZoCR0s+S8wPUBP7 VrFMahTaFzlONC/xE7iRr9lxOu9eo61Yo201tBvLW+xWa/f8LNXvtSP983/O9CA7d3 anCoZWGYZziC4TNMqMHOlZj9jCGFaSIwS38yUx3s=
Date: Tue, 21 Jan 2020 05:09:59 -0800
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3360/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Grease HTTP error codes (#3360)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e26f82795257_4d6e3fa0ca0cd96033654e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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, 21 Jan 2020 13:10:07 -0000

LPardue commented on this pull request.

> @@ -925,7 +925,9 @@ transferred. Endpoints MUST NOT consider these streams to have any meaning upon
 The payload and length of the stream are selected in any manner the
-implementation chooses.
+implementation chooses.  Implementations MAY terminate these streams cleanly,
+or MAY abruptly terminate them with an error code of the implementation's
+choice, including reserved error codes ({{http-error-codes}}).

We already say

> Because new error codes can be defined without negotiation (see Section 9), use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to H3_NO_ERROR. However, closing a stream can have other effects regardless of the error code

Closing a stream with the error code H3_CLOSED_CRITICAL_STREAM seems like an unexpected context to me. Martin makes the suggestion above to also treat reserved error values as H3_NO_ERROR.

By defining and exercising grease of error codes, we can help surface naiive implementations that react in the unfortunate way of your example. 

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