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

Kazuho Oku <notifications@github.com> Fri, 13 December 2019 03:54 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 362AE12018B for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 19:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xrjGIiVhRlt3 for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 19:54:51 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09EE1200F6 for <quic-issues@ietf.org>; Thu, 12 Dec 2019 19:54:51 -0800 (PST)
Received: from github-lowworker-6b40fdd.va3-iad.github.net (github-lowworker-6b40fdd.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id D75CF96056F for <quic-issues@ietf.org>; Thu, 12 Dec 2019 19:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576209290; bh=xV+OlCzgTViTZmr2HCxGMQe6J07NJK+7+HC8lwRd7wU=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=PpKVVu22C2uNMOyxZpksChOWMJKDLjNhZ016TBfFAqW7zOlvmAhM+j5OK2S2DFfws s3j7o0Fcey3MaaSJnsgYlApgVv1PSL8sJSuhgB9AyosXK/CQHy7+gRqsv6P9RGTXMA rS1BYZTbSQXbRjmCnKtb60rHaU78Roin+SIu9OE0=
Date: Thu, 12 Dec 2019 19:54:50 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5GGN5BBCUFPWNJ7JV4AA7AVEVBNHHCABYU5A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3300@github.com>
Subject: [quicwg/base-drafts] Forwarding upstream error to downstream (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df30b8ac851e_305c3fa3c8ecd9605684f"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/BuR2e4sYplrrT7RaXcnLO-VDHvY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2019 03:54:53 -0000

In HTTP/2, it has been easy for a proxy to forward upstream errors to client.

When the upstream abruptly closes a H1 connection (i.e., closed before serving the correct number of bytes as suggested by the content-length header, or before trailers when chunked encoding is used), the HTTP/2 terminator could forward all the content that it received from upstream, then send an RST_STREAM frame. Because HTTP/2 uses TCP, which guarantees the transmission order, the client receives the bytes that the origin has sent, before receiving a reset.

In contrast, HTTP/3 does not have such guarantee. When a HTTP/3 proxy resets a request stream mid-response, the QUIC stack is allowed to cease transmitting data. Depending on when the HTTP/3 proxy receives input from upstream, and depending on how the responses are prioritized, there is fair chance that the HTTP/3 proxy would be resetting the request stream with HTTP_REQUEST_CANCELED, without sending any response at all.

Are we fine with this behavior change?

We could argue that the root cause is the upstream failing to send the correct response. But the change of the failure mode might be an issue, because it would worsen the user-experience when the upstream misbehaves. For example, when an upstream server abruptly terminates the transfer of a JPEG image, a user connected through an HTTP/2 proxy would receive a partial image, whereas a user connected through an HTTP/3 proxy would see nothing (due to the reasons stated above).

Related to: #2426

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