Re: Question about Connection Reuse in RFC7540 / HTTP/2

"Martin Thomson" <mt@lowentropy.net> Thu, 12 December 2019 01:12 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868801200F7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 11 Dec 2019 17:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=S1vgGryq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pjsTj7Sd
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 YGBVmj3EK5C3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 11 Dec 2019 17:12:02 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9248B1200F4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 11 Dec 2019 17:12:02 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ifCz5-0007aB-T9 for ietf-http-wg-dist@listhub.w3.org; Thu, 12 Dec 2019 01:09:39 +0000
Resent-Date: Thu, 12 Dec 2019 01:09:39 +0000
Resent-Message-Id: <E1ifCz5-0007aB-T9@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mt@lowentropy.net>) id 1ifCz3-0007ZP-7N for ietf-http-wg@listhub.w3.org; Thu, 12 Dec 2019 01:09:37 +0000
Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1ifCz1-0002Gg-BN for ietf-http-wg@w3.org; Thu, 12 Dec 2019 01:09:37 +0000
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 58082223C2; Wed, 11 Dec 2019 20:09:33 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 11 Dec 2019 20:09:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=03 VO7vF7O7pysaz872tl4iZi/o89KRVZ3flmLB8NrEA=; b=S1vgGryqzCN+dmHDCy xsIWWMabDhotKQgt/ZoGd120HZOO+hgfrwwzHTcJ6kTl6vl7ce/GfW9GnAgdkNJb 1SojIIvzrlgcI6tbvRM0eofbMjPz9xq1WaBEQHsj5T5MkgQgnLvItjwn7FBEEoSf Z/6hSuMjh4nxEABWzScDxtNEcF2W/oPHa42G1OTZrFAZ7gnTRDvWfNwoTqBGsDMh yWIn3/HZbBWWLm7S068qGiUF4aURPSqociOO5rrJ8BLoZPESB/cZoCflWJkuUglR tE9JcZMjVu2G0I9d0d5lXyZsG84WgzbXRsg14V/q/QZT6e4ch4ly/0aLlkvNEH8y MVQQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=03VO7vF7O7pysaz872tl4iZi/o89KRVZ3flmLB8Nr EA=; b=pjsTj7SdmHvmWIrg2GgMEp5qQT7a5iS42I5J5wWcqAj+CLi6NVrCcECtM Z2FQkWpFA+Iu/th2KqtDZdguFBjKl59JoXQRgE4jbNAL8MeH7XEKJLPoRN5z0Sz3 XS5zrWNlxdG/gxwtX6W8mhw78cjSQFJFUpFQXUNVHXNXjciFxZoJ0x99VQ5erM9A a5Vd+eypfpqds2GCS3A2f3j5v9cMs3uqKERZIscIA4gidPgE9OArsogEJHPgbN0q 9GxoBVMrgbcvX9y+KIXS2Vfn00xPT1+pQTv7XNFvNMP9B4BT2W/mYXfM/l5i6w5g 0qXZX+64tHTP7Nc0bjuqYpWTH5nPQ==
X-ME-Sender: <xms:TJPxXdyKm1ni1YZlwzIjSwtLN43Dck326qJT9GhrcO7xKs-VqxiRZQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeliedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm theslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:TJPxXRUiEf3ojNI8fmsmely56ct9zAgd1frGKalZ8joAxlVMQHVZHw> <xmx:TJPxXcj3RfbPB-40CF-Fnjo3fjhXuCT4FaC2YQr-jSDrZlt6A5OJGA> <xmx:TJPxXQAW3-1gisB1hOd89ycGI2-gyh1YNXlsQy26vY9u4qcHmssCVg> <xmx:TZPxXeXa4JpnGjvHgEdYJB87_iWF1Z72TY17JbyD4REURM_hsM2F_Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A806EE00A2; Wed, 11 Dec 2019 20:09:32 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-679-g1f7ccac-fmstable-20191210v1
Mime-Version: 1.0
Message-Id: <318899aa-f2c3-4702-937d-54bc9dedfc81@www.fastmail.com>
In-Reply-To: <f0e298e1-95df-aa15-843b-1b6ec51cb654@huenig.name>
References: <f0e298e1-95df-aa15-843b-1b6ec51cb654@huenig.name>
Date: Thu, 12 Dec 2019 12:09:13 +1100
From: Martin Thomson <mt@lowentropy.net>
To: ietf-http-wg@w3.org
Cc: Anne van Kesteren <annevk@annevk.nl>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=66.111.4.27; envelope-from=mt@lowentropy.net; helo=out3-smtp.messagingengine.com
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1ifCz1-0002Gg-BN 75f7a8975c17be8c31fd9f39058295e6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Question about Connection Reuse in RFC7540 / HTTP/2
Archived-At: <https://www.w3.org/mid/318899aa-f2c3-4702-937d-54bc9dedfc81@www.fastmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37207
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

(IETF to BCC, moved to HTTP WG)

On Thu, Dec 12, 2019, at 04:08, Jonas Hünig wrote:
> My question is, if there is any specific reason this [retry on 421] is not mandatory 
> declared in the RFC for clients as this results in creating situations 
> in where some clients are not getting the resource at all but are 
> behaving in harmony with with HTTP/2

Making a new request is not generally something HTTP can require.  For instance, though 302 is usually handled by making a new request, some clients do stop and return the 302 status code.  This part of client behaviour is not something that the HTTP specs attempt to proscribe.  HTTP is just too diverse to have firm requirements of that nature.

The Fetch spec might have something else to say about the particular case you describe, however.  The goal is to reduce the amount of this style of variance between implementations of the web platform.  Maybe asking the same question as an issue on https://github.com/whatwg/fetch/issues would result in some changes.  I've cc'd the Fetch editor, who might have more insights on how you might best contribute there.