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

Kazuho Oku <> Sun, 21 July 2019 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59A6E120089 for <>; Sun, 21 Jul 2019 10:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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] 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 kfK6lhLVu3HS for <>; Sun, 21 Jul 2019 10:10:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D94CF120020 for <>; Sun, 21 Jul 2019 10:10:41 -0700 (PDT)
Date: Sun, 21 Jul 2019 10:10:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1563729041; bh=Geb9JoCLfswNVv8tOmFk0Rcj1Y0YuKui8QxmZ+vI3OE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GOaIPOh9lzSt4NjPZNVDMVyRbruFjMsIyThc3V+FA7OnHy4SkCJkvxVj1y51X8FX+ eUDrnqknmig0X0tfq4b2h+pMOl906tXuDYSAFmtE6Fl2oiu90ssYUgop91BLPfXiML 8+2JOxufAwbSw+FgRjMsYNQdFCg210eQ/dE6avTE=
From: Kazuho Oku <>
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_5d349c90f09dd_17773f8cfd0cd964487035"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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 17:10:44 -0000

> HTTP_NO_ERROR is only defined in the draft for usage in CONNECTION_CLOSE, I'm not sure when it would be used as a stream error (we have more specific error codes to indicate intent when closing a stream).

That's a good point. RFC 7540 uses NO_ERROR for instructing the client to stop sending the request when a response is provided early. In HTTP/3, we have created HTTP_EARLY_RESPONSE. But it might be a good idea to use HTTP_NO_ERROR in HTTP/3 too.

> HTTP_GENERAL_PROTOCOL_ERROR is only used as a stream error in the section discussing malformed requests/responses. I'd suggest using a more descriptive error for this case (HTTP_MALFORMED_MESSAGE for example) and treating HTTP_GENERAL_PROTOCOL_ERROR as solely a connection error.

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.

> One of the thorny points to this discussion is that promotion of stream errors to connection errors is a feature of RFC 7540 Section 5.4.1

I'd prefer keeping the same design.

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.

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