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

Lucas Pardue <> Wed, 18 December 2019 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E758E120ADD for <>; Wed, 18 Dec 2019 10:40:20 -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 iOIbK1Qz5e-X for <>; Wed, 18 Dec 2019 10:40: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 5515E120ACF for <>; Wed, 18 Dec 2019 10:40:19 -0800 (PST)
Date: Wed, 18 Dec 2019 10:40:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576694418; bh=TVVnUtb0inRDauThTWPaJ/pn5kokl1f7ZOLuLfTzJCI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=c5gD/CEZbb8wXFt8NDNtaViB2skjaF2zXzucvS/N9ieNDI+xXn6SgjtcE6WMyDCwh qYXHoCNe6YTIjX6bhzS+WxYHOx6GX2kRUr5nERQh12Eygz1xY414B6lrYcZaYhMbRy T8PktXcmPM2PUWLH2gJKV3i30w9zKnPALO7RGKuw=
From: Lucas Pardue <>
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_5dfa72929e9c4_3b583ff9d64cd960330216"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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 18:40:21 -0000

I wasn't following this discussion so closely, so IIUC the problem is that the stream cannot end abruptly or else there are no guarantess from QUIC layer that the DATA will arrive at the HTTP client. Closing cleanly would ensure DATA is delivered but triggers h3-24 section 7.1.

> If we consider that a tunnel should be allowed to send DATA frames (or HTTP/1 chunks) that it receives from upstream as is,

To invoke the problem, an intermediary would have needed to committed a DATA frame of length `N`, to stream offset `O`, then attempt to fin the stream at offset `F`, which is less than `O+N`. I can see several scenarios that this might occur in an intermediary and it would be quite unfortunate to cause a connection close.

Since request streams are the only core streams that can be cleanly closed without blowing up the connection I think the middle ground might be to state something like: an endpoint that receives truncated leading HEADERS or PUSH_PROMISE should treat it as a connection error. Truncation of DATA and non-leading HEADERS is ok. Extension frames or streams need to consider truncation and specify the behaviour.

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