IETF Logo Mail Archive

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

Lucas Pardue <notifications@github.com> Sun, 21 July 2019 18:21 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B27120135 for <quic-issues@ietfa.amsl.com>; Sun, 21 Jul 2019 11:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT4HiBWJBjMr for <quic-issues@ietfa.amsl.com>; Sun, 21 Jul 2019 11:21:19 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF841120133 for <quic-issues@ietf.org>; Sun, 21 Jul 2019 11:21:19 -0700 (PDT)
Date: Sun, 21 Jul 2019 11:21:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563733279; bh=Ges5zNqF79Sey4Ed36YrDcpWkgeX3IawU21SxPmN1io=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=b8ZXQe6WP6xY7NWsrgPG9JV8jN8+G0Ys/fW2ET6GSYJ66T0wQXja9fs7lzTp5iyfj beLudyLpB3nnBhJJL8J3CJl6CoQns5L/e0QagL/L7Xg/cwnkXsvpbp3LYbpWa27Tjz WjVYVHjlEdICqW4PqOJp+Pp/KPymVnUkBbZmXs7Q=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5STJVJVLUBHA4G7VN3IHPZ5EVBNHHBYDQKAQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2911/513576272@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2911@github.com>
References: <quicwg/base-drafts/issues/2911@github.com>
Subject: Re: [quicwg/base-drafts] Separate HTTP/3 stream errors from connection errors. (#2911)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d34ad1ef0544_780d3f83d0ecd964797470"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/P3vjDF3o6lBYTrHWvv9f070YhsU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2019 18:21:21 -0000

@kazuho 

> 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.

I agree. This is a real thing that happens today with H2 and should be maintained.

My question would be, does  it makes sense for promotion to maintain the the error code fidelity? I.e. if you are closing connection on a miss-behaving peer, is there benefit from articulating the specific stream error code, or does it work as well to drop this to HTTP_GENERAL_PROTOCOL_ERROR?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2911#issuecomment-513576272

v2.14.0 | Report a Bug | By Email