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

Mike Bishop <notifications@github.com> Thu, 19 December 2019 16:22 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 E98361201EA for <quic-issues@ietfa.amsl.com>; Thu, 19 Dec 2019 08:22:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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, URIBL_BLOCKED=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 wlAdpRq4RZKl for <quic-issues@ietfa.amsl.com>; Thu, 19 Dec 2019 08:22:20 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D533120923 for <quic-issues@ietf.org>; Thu, 19 Dec 2019 08:22:18 -0800 (PST)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id A24AA960802 for <quic-issues@ietf.org>; Thu, 19 Dec 2019 08:22:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576772537; bh=7ENbXyP+xnyxjZ3rPbJno4b6dkvqqR5JzIroMCmcibo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hUdSxCOcvqaY27FP8lZYBtjMv9HFBrgndTYlUVH13C9b14n3GFO3xrRIO/d7e100D 7WeZ5asLlh6uG5qZLR4xVS17Ng0gkFarEX59/O6dzRAqdT2d17LgGWLfL9IjeKEDuL +LFdGasmkb3ibO54f4G43W45nfpsUf93xOUqYc18=
Date: Thu, 19 Dec 2019 08:22:17 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4XS4BCAFKERG3GV654BDLDTEVBNHHCABYU5A@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/567559242@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3300@github.com>
References: <quicwg/base-drafts/issues/3300@github.com>
Subject: Re: [quicwg/base-drafts] Forwarding upstream errors, and the implications (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dfba3b993b79_3c4a3fdfe6ccd96c1745d0"; 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/t4hLpxlNq7TYlIfEDDCMcRujA5k>
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: Thu, 19 Dec 2019 16:22:22 -0000

> In either case, the close signal never overtakes the partial payload.

This is not true, or at least not universal.  It's entirely legitimate for a TCP stack to dump anything that's in buffers (unread by the application) and immediately surface the TCP RST.  The reset can and does overtake partial payload in places.

> We already allow a HTTP tunnel to send a malformed response (see [the third paragraph of section 4.1.3](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-4.1.3-3)). That tunnel might be coalescing HTTP messages going to different endpoints. That means that an endpoint should not handle a stream that contains invalid DATA frames as a connection-level issue.

That's not my understanding of that paragraph.  It says that if an intermediary receives a malformed response, it MUST NOT forward it and MUST treat receipt of the malformed response as a stream error.  This is unclear in two ways we need to correct:

- First, it doesn't say whether the specified error should be sent upstream or downstream.  I believe this intends to say it resets the upstream stream that sent it a malformed response.
- Second, assuming the first answer, it doesn't specify what to send downstream _instead_ of forwarding the malformed response.

I would propose that we need YAEC to signal an aborted response upstream.

The suggestion that we send as much as we can, then cleanly terminate the stream disturbs me.  I'm inclined to take a hard line here and keep the text that intermediaries shouldn't be forwarding known broken responses.  That way lies consistency bugs.  You forward data as long as it's valid; if it becomes invalid, then you forward a RESET_STREAM that indicates the upstream is no longer talking sense.

-- 
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/3300#issuecomment-567559242