Re: HTTP/2 GREASE, Results, and Implications

Willy Tarreau <> Fri, 15 November 2019 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2E4C12011F for <>; Fri, 15 Nov 2019 12:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ufJPpdTu73hx for <>; Fri, 15 Nov 2019 12:41:13 -0800 (PST)
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 8201912006F for <>; Fri, 15 Nov 2019 12:41:13 -0800 (PST)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iViMN-0008G0-KU for; Fri, 15 Nov 2019 20:38:27 +0000
Resent-Date: Fri, 15 Nov 2019 20:38:27 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1iViML-0008FE-LD for; Fri, 15 Nov 2019 20:38:25 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1iViMJ-0005CN-TB for; Fri, 15 Nov 2019 20:38:25 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id xAFKcFRV026667; Fri, 15 Nov 2019 21:38:15 +0100
Date: Fri, 15 Nov 2019 21:38:15 +0100
From: Willy Tarreau <>
To: Tom Bergan <>
Cc: Bence =?iso-8859-1?Q?B=E9ky?= <>, Stefan Eissing <>, Mike Bishop <>, HTTP Working Group <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: 1iViMJ-0005CN-TB 9985bc952bb206ca7262cfd12b377559
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <>
X-Mailing-List: <> archive/latest/37139
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Nov 15, 2019 at 11:35:13AM -0800, Tom Bergan wrote:
> It's important to work through these implementation issues. If
> implementations are difficult to change, then we'll probably need to take
> Bence's suggestion, or something similar.

Regardless of these issues, Bence's proposal sounds appealing to me for
a better layering.

> That said, I don't fully understand the problem here. Can you elaborate?
> Assuming the implementation throws away unknown frames immediately, as
> suggested by Section 5.5, only the known frames are left. At that point, it
> shouldn't matter whether the bit mask describes permitted frames or
> forbidden frames -- both approaches are equivalent.

Oh it's very simple to understand: due to the rules restricting the frame
types depending on the stream state, the frames are matched against the
stream state early during the processing. In fact proceeding as you
suggest would make the code simpler, it's just that it's changing the
logic, and while I do see how to adapt mine for this (with limited risks
of regressions when it comes to backport this to deployed maintenance
branches), it's easily imaginable that and equivalent level of complexity
(not high, just moderate) can affect other deployed implementations,
causing some reluctance to changing existing code in field.

I *am* personally willing to make the change if there is consensus on
this. I even hacked a minimal patch for this after Mike's report. I'm
just not assuming that everyone will do so in an eyeblink.

Another option could be to refrain from sending new frame types until
a setting has been advertised by the other end. I just find this a bit
sad. That's exactly what the minor version in the protocol was for. We
could have had HTTP/2.1 advertised over ALPN to instantly match both
ends, but now we have to do without this possibility.