Re: [quicwg/base-drafts] Unidirectional RESET_STREAM/STOP_SENDING semantics map poorly to proxies (#2415)

Mike Bishop <notifications@github.com> Wed, 06 February 2019 19:36 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7A8130F29 for <quic-issues@ietfa.amsl.com>; Wed, 6 Feb 2019 11:36:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB7alMgMkvYU for <quic-issues@ietfa.amsl.com>; Wed, 6 Feb 2019 11:36:46 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4BF12426A for <quic-issues@ietf.org>; Wed, 6 Feb 2019 11:36:46 -0800 (PST)
Date: Wed, 06 Feb 2019 11:36:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549481805; bh=cDpMSMAv1Y+uN4u8nU7J1AytnVKlEuKFYYzsIxSBrdM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1mu+X6nRjYSGmaR/pLI0fkFpngG61YNDV7AX60velpZ9rijTjUBzjYiAD1W2v6ZsG KqCqV0or6jjE8vAl4kkDctHIm25AHbaojeO7DuO+0PVtK3CswjWt32oYK9Xj03tzVi RfbxjxRWxd1qjwB31kdn0uZ+AFLySF1FFrSz3f7Q=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdab1638eceea337d469f5e37cb132178467b6bc192cf000000011872f94d92a169ce183bce82@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2415/461157727@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2415@github.com>
References: <quicwg/base-drafts/issues/2415@github.com>
Subject: Re: [quicwg/base-drafts] Unidirectional RESET_STREAM/STOP_SENDING semantics map poorly to proxies (#2415)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c5b374d4dbc3_1de3f89e18d45b46142e5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/E1oskLBKecYXdFOwX2PpFOVE9IY>
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: Wed, 06 Feb 2019 19:36:48 -0000

As to the H3 question, the spec currently says:
> When a stream is closed, this indicates the end of an HTTP message. Because some messages are large or unbounded, endpoints SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress. If a client stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response with the error code HTTP_INCOMPLETE_REQUEST.

The stream might have closed because of a FIN or a RESET; if the entire request arrived intact, the server can proceed to respond; the RESET just means that no attempt will be made to repair any losses.  A STOP_SENDING, however, means that you don't want the response even if the request went through.

Thus:
> Clients can cancel requests by aborting the stream (QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with an error code of HTTP_REQUEST_CANCELLED (Section 8.1). When the client cancels a response, it indicates that this response is no longer of interest. Implementations SHOULD cancel requests by aborting both directions of a stream.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2415#issuecomment-461157727