Re: HTTP/2 GREASE, Results, and Implications

Willy Tarreau <> Thu, 31 October 2019 20:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83ED31200E9 for <>; Thu, 31 Oct 2019 13:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HJrihRQiuwml for <>; Thu, 31 Oct 2019 13:37:37 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 8F20312004D for <>; Thu, 31 Oct 2019 13:37:37 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iQH9w-0001m8-8B for; Thu, 31 Oct 2019 20:35:08 +0000
Resent-Date: Thu, 31 Oct 2019 20:35:08 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1iQH9u-0001lK-Ny for; Thu, 31 Oct 2019 20:35:06 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1iQH9s-0000Ml-Vs for; 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 <>
To: Bence =?iso-8859-1?Q?B=E9ky?= <>
Cc: Mike Bishop <>, HTTP Working Group <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=;;
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: 1iQH9s-0000Ml-Vs e4853067ff75f4240afad2e5b62501ef
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <>
X-Mailing-List: <> archive/latest/37097
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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
  - 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,