Re: [quicwg/base-drafts] Forwarding upstream error mid-body to downstream (#3300)

Kazuho Oku <> Wed, 18 December 2019 01:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93D97120073 for <>; Tue, 17 Dec 2019 17:59:17 -0800 (PST)
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 4oCAs9dkibgr for <>; Tue, 17 Dec 2019 17:59:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7601E120043 for <>; Tue, 17 Dec 2019 17:59:15 -0800 (PST)
Date: Tue, 17 Dec 2019 17:59:14 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576634354; bh=kLAWwfU0wDCFCmbV52+JKDUt5j7lHSE1VmNuGlmhIeM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Hoh2z4t2MiY9COHmqilU5cIYuy/JGWGTzLhhiQLoVDLIAHf62mdtQeVU+T3TAVOqf QZ6IIRid0w5MH8RIBwUj8aDLvuA+LBFocOYjEkVWutGSTr5G7VnlvN3JQEXT6K6c02 2MbuC9Cznq519EILOsOTOJ+MCiChmY9f0earthwU=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3300/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Forwarding upstream error mid-body to downstream (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df987f28326b_4fc33fa6168cd95c155777"; 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: Wed, 18 Dec 2019 01:59:18 -0000

> Adding in-order stream reset sounds extremely complicated at either the HTTP/3 or QUIC layers. The particular use case here does not seem compelling enough to warrant this complexity.

As stated above, if it ought to be a complicated mechanism at the HTTP/3 layer depends on the how the HTTP/3 tunnel frames the response. As we've discussed previously in #1885, an HTTP/3 intermediaries can and will have different framing strategies. When the strategy employed by an intermediary is to create a new DATA frame every time it emits something, sending a HTTP frame to indicate an error after sending all the HTTP response it has is trivial.

All that said, I think that we might not need a new frame after all.

We already allow a HTTP tunnel to send a malformed response (see [the third paragraph of section 4.1.3]( That tunnel might be coalescing HTTP messages going to different endpoints. That means that an endpoint should not handle a stream that contains invalid DATA frames as a connection-level issue.

I've changed #3303 to be a clarification of this requirement, which has been implicit until now.


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