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

Martin Thomson <notifications@github.com> Thu, 02 January 2020 03:13 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 E389C120046 for <quic-issues@ietfa.amsl.com>; Wed, 1 Jan 2020 19:13:25 -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_IMAGE_ONLY_32=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhBJKfzxMNaq for <quic-issues@ietfa.amsl.com>; Wed, 1 Jan 2020 19:13:24 -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 328DC12003E for <quic-issues@ietf.org>; Wed, 1 Jan 2020 19:13:24 -0800 (PST)
Date: Wed, 01 Jan 2020 19:13:23 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1577934803; bh=j4jBatA2WMfuD/PvemrtKUuHZ+8pTXpHktwwJKIYD3E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TAvWAgwDWBmmnr+KTmgN+ls26fDtV40RMsHWkwZLI/8dZabao9Jb2Vfp2nCOHBS9x rqBkHCp2TpKT4cA1ajVrw2zhebCqb0RzwSC/WQaTFiqQ1JUDe920gsyQH1upXdRsRm PkWmkyrVM58wQ0zqaH6WjTPrZnxM/4MRQ1o79i9s=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4SFNYAPNQMYO466FN4DKJFHEVBNHHCABYU5A@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/570109275@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_5e0d5fd38c961_68833fad5a4cd9601159b1"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/YTwTY06aiXZxCbGHViuufQ9oKZo>
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, 02 Jan 2020 03:13:26 -0000

> HTTP/2 is underspecified in sense that it allows any stream error to be promoted to a connection error

I think that we might disagree on this point.  Even if the spec didn't expressly include this permission, you can always reduce this to a question of local policy.  That is, my policy could be to cease communicating with a peer that fails to follow the spec.

The effect of such a policy has been beneficial in that it provides some incentive for new implementations to follow the spec.  The same policy has also been bad in those cases where this was overzealously implemented: if we can't used new frame types without explicit negotiation, that's not a great state to be in.

> even though as we agree, a stream error that might have originated from an origin cannot be promoted to a connection error

I don't think "cannot" is agreed.  We might agree on the outcome of propagating the error, but I personally don't think that we should externalize these effects even in this way.  We might highlight the possibility of problems, but if an intermediary is forwarding streams without looking at their contents, it is still ultimately responsible for the effect of their contents.  If clients decide to hold the intermediary responsible for a failing at an origin server that is invisible to them, that's still the intermediary's problem.

I'm going to suggest that we acknowledge that this is tricky and then move on.  I don't want to create another application of the Robustness Principle before we've even shipped the protocol.


-- 
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-570109275