Re: [quicwg/base-drafts] Forwarding upstream errors, and the implications (#3300)

Kazuho Oku <> Tue, 14 January 2020 05:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D57512001A for <>; Mon, 13 Jan 2020 21:04:21 -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 4drBFqq2wEVe for <>; Mon, 13 Jan 2020 21:04:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B444120019 for <>; Mon, 13 Jan 2020 21:04:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 62F152C0A82 for <>; Mon, 13 Jan 2020 21:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578978258; bh=jZeos37/y56Jrmpab5xqEUreDWhuiTRzo962FHTS/aI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uwdHH9ohevVdIRWqmWnFRR9mHVxRp8dD4zBYaY7xqeDBcwYX28nXXH4BST8AyZQSE yvEdj14Xz/gZmK8XjOY1wtrQPhYw3YOWe1asyNUbYds+WE/21Aphc9qWCaGW0+SHdC VmNFQgiaGkWL6jlZu3hBoBVJgb0FkZDA4/6hvJNA=
Date: Mon, 13 Jan 2020 21:04:18 -0800
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 errors, and the implications (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1d4bd251d5c_6b8c3ff7e24cd9602440cd"; 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: Tue, 14 Jan 2020 05:04:22 -0000

I think that this issue discusses two orthogonal problems:
* This issue was originally about how an intermediary can close a HTTP message that it has been forwarding, when that intermediary recognizes that the message being forwarded is malformed (e.g., when upstream closes the request stream mid-frame, when the amount of body provided does not match the value of content-length response header), at the same time forwarding all the content that it has received from upstream. The only approach that works is delaying the transmission of stream resets until receiving ACKs for all the data it has sent on that stream. H2 does not have the first problem because a stream reset can never overtake the delivery of other frames that have already been sent.
* The scope of an error that happens on the request stream (or the push stream). At the moment, some errors (i.e. invalid frames) are handled at connection-level, while others (i.e. malformed response) are stream-level. This is a departure from the design that we have in H2, that localizes stream-level issues to stream-level errors. Note that H2 and H3 both allow endpoints to escalate stream-level errors to connection-level.

It might be a good idea to split this issue in two; both #3303 and #3336 are attempts to address the second problem, but not the first problem.

Regarding the second problem, there are three paths:
* a) status quo
* b) go back to what H2 does - #3336 
* c) require those errors to be stream-level, forbidding promotion to connection-level - #3303 

As stated in [my previous comment](, my preference goes to #3303, as it maximizes the chance of requests being coalesced. Unless we forbid the promotion of stream-level errors to connection level (or without stating that such promotion might have negative effects), CDNs cannot allow coalescing of HTTP requests that go to different origins, as one misbehaving origin might obstruct the exchanges between the client and other origins that share the same connection. While this is not an issue for all the server deployments, it would be a backlash against our previous efforts (e.g., ORIGIN frame, secondary certificates) to maximize the chance of requests going to different origins getting coalesced, as there would be less interest in implementing these extensions from CDNs.

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