IETF Logo Mail Archive

Re: [quicwg/base-drafts] HTTP-31: Reserved Error codes (#4219)

Magnus Westerlund <notifications@github.com> Fri, 16 October 2020 07:59 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 099723A0DA4 for <quic-issues@ietfa.amsl.com>; Fri, 16 Oct 2020 00:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.208
X-Spam-Level:
X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 nFRVhSOMNuHM for <quic-issues@ietfa.amsl.com>; Fri, 16 Oct 2020 00:59:23 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A743A0D9D for <quic-issues@ietf.org>; Fri, 16 Oct 2020 00:59:23 -0700 (PDT)
Received: from github.com (hubbernetes-node-83aef73.ac4-iad.github.net [10.52.113.55]) by smtp.github.com (Postfix) with ESMTPA id C5637560D4F for <quic-issues@ietf.org>; Fri, 16 Oct 2020 00:59:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1602835162; bh=GyQncS6Co2oQffI8eiq5HjFLTJ9lSSZIbe9qestRBYo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NJ5iFjUF+NubnTLcAPZ8r5MFJLCcLe+xy3qx5vOk1ujZREnhphph94sFy3vJEjDKI ZnVwIxm+Wj4y/rVWI6ogr1Rhjsp4lhf8p6Uqla7sWnHNwmOGRq+g3i2LVwjE9YGy5C BnBW5/dXfQHd6/nAp3B+Z9gloS2H7KGm8hzpvCU0=
Date: Fri, 16 Oct 2020 00:59:22 -0700
From: Magnus Westerlund <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYYYRHXEV6H4IANNGN5SUZ5VEVBNHHCWEAHEA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4219/709890894@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4219@github.com>
References: <quicwg/base-drafts/issues/4219@github.com>
Subject: Re: [quicwg/base-drafts] HTTP-31: Reserved Error codes (#4219)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f8952dac1912_15c019b4852f5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gloinul
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/Kwcy52QVsYM5FhpjZBR3IbNQKlE>
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: Fri, 16 Oct 2020 07:59:25 -0000

Isn't it problematic for an HTTP/3 endpoint that receives a for it unknown stream type to abort it and respond H3_NO_ERROR. To me that looks potentially problematic as it might indicate something worked okay if that extension have the behavior of receiving a block of data and then close down the stream? Or should any of this extension anyway be negotiated using SETTINGS so this should never be an issue as the peer should know through that SETTINGS exchange what the peer is capable of? 

-- 
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/4219#issuecomment-709890894

v2.23.0 | Report a Bug | By Email