Re: [quicwg/base-drafts] Separate HTTP/3 stream errors from connection errors. (#2911)

Daan De Meyer <> Sun, 21 July 2019 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 306FD120161 for <>; Sun, 21 Jul 2019 11:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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, RCVD_IN_MSPIKE_H2=-0.001, 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 1qiJCj2Ceyu9 for <>; Sun, 21 Jul 2019 11:23:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B455120135 for <>; Sun, 21 Jul 2019 11:23:56 -0700 (PDT)
Date: Sun, 21 Jul 2019 11:23:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1563733435; bh=yENJx3/Jvz8zYN2HGbdH+xleKiX/cqjrs+M9paTKdzE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=D3keEVu1zpL02q4GqZzQDVvmXOWse1POcfDDSP8Yhi6dBfmLby9//bTaLt48minHM XRctxARB36k1hIBvRV2LzHLpXDD9tmtp0ytDVsh24Rpwfo46/p0KaWOEx0U7155p/U tY087XoF7FGW0elvfPhewT/+9YaoocILNKGzmP8Y=
From: Daan De Meyer <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2911/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Separate HTTP/3 stream errors from connection errors. (#2911)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d34adbb7e699_697b3fda89ccd9604839f0"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DaanDeMeyer
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: Sun, 21 Jul 2019 18:23:58 -0000

> HTTP_GENERAL_PROTOCOL_ERROR is a catch-all error code that can be for any reason. I'd prefer having that usable at stream-level too.

PROTOCOL_ERROR sounds to me like something that mandates closing the connection. I do agree with having a catch-all error code for streams as well but I'd just add HTTP_GENERAL_STREAM_ERROR instead of reusing HTTP_GENERAL_PROTOCOl_ERROR. It avoids confusion of whether PROTOCOL_ERROR closed a single stream or the entire connection. 

> I think we need the freedom of promoting stream-level errors to connection errors. For example, when a server detects a suspicious activity by a client at a stream-level, it would make sense to close the connection.

Why do we need promotion for this? Closing the connection because of suspicious activity at the stream level sounds like a clear use-case for a connection level error such as HTTP_SUSPICIOUS_ACTIVITY (I don't think we should actually add this).

More generically, if an error at the stream level (clearly intended not to close the entire connection since its a stream level error) causes the entire connection to be closed, that should be communicated with a connection level error instead of a stream level error. Many of the current stream level errors don't make any sense at all when used in the context of a connection level error. Instead, if a stream error could possibly mandate closing the entire connection, it should have a corresponding connection level error that more clearly indicates why a stream level error caused the the entire connection to be closed.

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