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

ianswett <> Mon, 16 December 2019 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A894112081F for <>; Mon, 16 Dec 2019 08:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 cn-uZEBLQ3Mw for <>; Mon, 16 Dec 2019 08:42:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 198741200B2 for <>; Mon, 16 Dec 2019 08:42:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2351EA01A1 for <>; Mon, 16 Dec 2019 08:42:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576514531; bh=TEXRVGtGC82FHzC6jJFMA16vPaqUQimXGsUEZKnwbcM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=V3SZ4o6Ob7AHRh9knQ4WDNnk1HmAdcbmJl55WWktJT4XeT66saqKoVn3H3yh0fBoS cw6V24Q2shIOo2nnbFAOeqOSLosakvthFFFg4oeeAXIg1ZIr+3a+ftLCrX+2fhIVIg OOEICbXvOqyUKdtWzOApANWvVG+5V1wYMdDf3jwU=
Date: Mon, 16 Dec 2019 08:42:11 -0800
From: ianswett <>
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_5df7b3e313984_43373ff4d5ecd95c181280"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: Mon, 16 Dec 2019 16:42:14 -0000

If the TCP connection is closed with a reset, there's no guarantee how many bytes the intermediary has read from the kernel buffer before the reset is received, so I don't think the behavior is likely to be that different.

If there's an error at the HTTP layer, then I think there would commonly be a change in what the client sees, but that seems like a buggy backend, so I'm not sure it's worth attempting to deal with more gracefully?

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