Re: HTTP/2 GREASE, Results, and Implications

Willy Tarreau <w@1wt.eu> Thu, 31 October 2019 20:37 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 83ED31200E9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Oct 2019 13:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 HJrihRQiuwml for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Oct 2019 13:37:37 -0700 (PDT)
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 8F20312004D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 31 Oct 2019 13:37:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iQH9w-0001m8-8B for ietf-http-wg-dist@listhub.w3.org; Thu, 31 Oct 2019 20:35:08 +0000
Resent-Date: Thu, 31 Oct 2019 20:35:08 +0000
Resent-Message-Id: <E1iQH9w-0001m8-8B@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <w@1wt.eu>) id 1iQH9u-0001lK-Ny for ietf-http-wg@listhub.w3.org; Thu, 31 Oct 2019 20:35:06 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by titan.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1iQH9s-0000Ml-Vs for ietf-http-wg@w3.org; Thu, 31 Oct 2019 20:35:06 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x9VKYxbq031032; Thu, 31 Oct 2019 21:34:59 +0100
Date: Thu, 31 Oct 2019 21:34:58 +0100
From: Willy Tarreau <w@1wt.eu>
To: Bence =?iso-8859-1?Q?B=E9ky?= <bnc@chromium.org>
Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20191031203458.GA31017@1wt.eu>
References: <BN6PR2201MB1700D10A34C72213C78E09A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.com> <20191031155259.GC30674@1wt.eu> <CACMu3trL5UMukoPd8Nr4W-bMsyH+WKUnwg16yxu3tN5D=uZt8w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACMu3trL5UMukoPd8Nr4W-bMsyH+WKUnwg16yxu3tN5D=uZt8w@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1iQH9s-0000Ml-Vs e4853067ff75f4240afad2e5b62501ef
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <https://www.w3.org/mid/20191031203458.GA31017@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37097
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>

On Thu, Oct 31, 2019 at 01:08:53PM -0400, Bence Béky wrote:
> Thanks, Willy, for pointing out the different sections of RFC7540
> concerning unknown frame types.  It seems to me that for the past few days
> Chrome (on certain channels) has been sending frames on half-closed
> (remote) streams.

Bence, I saw that you updated the issue regarding this point. If
you're going to be stricter on the states to respect the (confusing)
wording of the spec, then you need to be very careful about other states
for completeness:

  - closed: An endpoint MUST NOT send frames other than PRIORITY on a closed
    stream.
  - reserved (remote): An endpoint MUST NOT send any type of frame other
    than RST_STREAM, WINDOW_UPDATE, or PRIORITY in this state.
  - idle: Receiving any frame other than HEADERS or PRIORITY on a stream in
    this state MUST be treated as a connection error.

I think it's reasonable to assume that only these transitions (in addition
to the already mentioned half-closed) face such restrictions. This means
that any new non-negociated frame type will still be allowed for the
connection (stream 0) and open streams. This sounds quite reasonable and
should not risk to trigger the consistency issues in the spec's wording.

And at first glance if that's the case I don't need to patch my code,
so we can expect that other implementations faced similar issues and
that the limitations above remain acceptable (but an errata will have
to be filed to keep track of this).

Hoping this helps,
Willy