[quicwg/base-drafts] Error code for indicating that a HTTP response is aborted (#2416)

Kazuho Oku <notifications@github.com> Tue, 05 February 2019 02:48 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 39C48130F99 for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 18:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_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 IVNCKbodJGGO for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 18:48:18 -0800 (PST)
Received: from out-9.smtp.github.com (out-9.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 73AD3130F96 for <quic-issues@ietf.org>; Mon, 4 Feb 2019 18:48:18 -0800 (PST)
Date: Mon, 04 Feb 2019 18:48:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549334897; bh=nhVBQ4eoFBaMPxiWNZf+kZZjBv6ra/HGze67LjzaoOM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=jEzPcG1RKHo8jL9JuU1mGr3/QCB8jwFdoXevoKocdXSTzcuxNGc6rUzHkIxPVPEih lybI2xRn4pwzrCjgO8h1mgwOqD5cwsJ8DnGDPYSEOFa0osq0PpxTBCGWa/d1UuAR2b qP6TzHWBDIBBS/cEKE/hJt/+VjtDqDPCQeHI1DKs=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abf8280c0dd286d86b79995954dc07190927fab25492cf000000011870bb7192a169ce183c5ccd@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2416@github.com>
Subject: [quicwg/base-drafts] Error code for indicating that a HTTP response is aborted (#2416)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c58f9713bc5a_6913ff2248d45b859986"; 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/mnG1LZBtgTpuA07zy1gqWC6TPFQ>
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: Tue, 05 Feb 2019 02:48:20 -0000

When a reverse proxy forwards a HTTP response to the client, sometimes it sees the upstream server terminate the response early. For example, a HTTP/1.1 connection being closed prior to transmitting number of bytes specified by the `content-length` field. Or a chunked response being closed abruptly.

The only way of delegating such a condition to the client in HTTP/2 was to send a RST_STREAM frame with `PROTOCOL_ERROR`. However, use of the error code is awkward in this case, considering the fact that the error did not happen within the communication between the endpoints using the particular HTTP/2 connection.

I think it makes sense to have an error code that better designates the case.

One way to address the issue in H3 would be to change `HTTP_REQUEST_CANCELLED` to `HTTP_MESSAGE_CANCELLED`, and let the server use the error code (as an argument of the RESET_STREAM frame) to indicate that the response has been "cancelled".

Originally proposed in 

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