Re: [quicwg/base-drafts] Forwarding status of errors on streams (#3303)

Kazuho Oku <> Thu, 02 January 2020 02:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48A89120072 for <>; Wed, 1 Jan 2020 18:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2PYAccyw5O-z for <>; Wed, 1 Jan 2020 18:57:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F236F120046 for <>; Wed, 1 Jan 2020 18:57:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 076902C0FED for <>; Wed, 1 Jan 2020 18:57:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1577933863; bh=gJtwH0XmJOZ4zjVAaXial1ccobep3PfnuvZbIE0/xAU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eEsjJdJB0DwfpYp46z5A/tIH4DbDDYMPTiH0rNm+uSw6VxZtlEfZUyLxKykS2I+Ac 5E6mEKmx+gyym1gfo5I71qIS/Wlz1DA9nE5LnyzZDpxqzruJZT1wBHj4wFePEmzhyA +4vR4rg1o/QlZUhrY+GO0OpR0+nrzF5gIPXW0CMg=
Date: Wed, 01 Jan 2020 18:57:42 -0800
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3303/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Forwarding status of errors on streams (#3303)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e0d5c26ec40f_6d333f803cacd96425066d"; 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: Thu, 02 Jan 2020 02:57:46 -0000

@ianswett @martinthomson Am I correct in assuming that you are arguing for prohibiting tunnels to forward malformed HTTP messages (e.g., those contain prohibited header fields)?

While I can see the beauty of such design, I am uncertain if that's a good approach. Use of an HTTP header field, which is end-to-end information, might make an HTTP message malformed. I wonder if an intermediary would be capable of detecting all such misuses. One extreme case that I can think of is an HTTP extension defining a new HTTP header field, that must not be sent as a trailer. Do we want an HTTP/3 intermediary to understand all the header fields that it forwards?

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