Re: HTTP/2 GREASE, Results, and Implications

Willy Tarreau <> Wed, 06 November 2019 20:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4352C1200A4 for <>; Wed, 6 Nov 2019 12:26:41 -0800 (PST)
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 S1qX_9ijJGig for <>; Wed, 6 Nov 2019 12:26:39 -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 DB49E12004A for <>; Wed, 6 Nov 2019 12:26:39 -0800 (PST)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iSRqp-0002Ad-Hc for; Wed, 06 Nov 2019 20:24:23 +0000
Resent-Date: Wed, 06 Nov 2019 20:24:23 +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 1iSRqn-00029r-Oj for; Wed, 06 Nov 2019 20:24:21 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1iSRqm-0007ML-1T for; Wed, 06 Nov 2019 20:24:21 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id xA6KOB2P015089; Wed, 6 Nov 2019 21:24:11 +0100
Date: Wed, 6 Nov 2019 21:24:11 +0100
From: Willy Tarreau <>
To: Bence =?iso-8859-1?Q?B=E9ky?= <>
Cc: Stefan Eissing <>, 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: 1iSRqm-0007ML-1T 97688fa1703f4aa3ccfd91d230ff6e43
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <>
X-Mailing-List: <> archive/latest/37130
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Bence,

On Wed, Nov 06, 2019 at 03:03:18PM -0500, Bence Béky wrote:
> Hi,
> I added two simple command line flags to Chrome to trigger sending greased
> HTTP/2 elements, and they are available since version 80.0.3960.0 (not on
> Linux quite yet).

OK, thanks for letting us know.

> --http2-grease-settings adds one settings parameter with a reserved
> identifier and random value to every SETTINGS frame sent (one per HTTP/2
> connection).
> --http2-grease-frame-type sends one frame of reserved type and random short
> payload after every SETTINGS and HEADERS frame, including HEADERS frames
> with END_STREAM flag set.  This is what caused problems apparently with
> Cloudflare and Akamai.

And haproxy, given that this violates the rule of no frame type other than
the few allowed one in half-closed remote state. The problem with allowing
new frame types during forbidden states is that we could make it way
harder to implement these new frame types later without risking to see
them behave differently depending on implementations. I suspect that if
we want to go down that route we'll need to either reserve certain frame
types as carrying no payload for streams and others as possibly having
some :-/ In addition, frame flags are defined per-frame, eventhough we
all know they are the same. But new frames exhibiting an END_HEADERS
flag or an END_STREAM flag cannot be completely ignored. Frames
designating an idle stream ID which are not HEADERS frame will also
possibly create a stream or not and cause issues. I think that at the
moment the only way we have to continue to ignore frames is :

  - ignore the unknown ones on stream 0
  - ignore the unknown ones on non-idle, non-half-closed(remote) streams
  - respect existing rules for existing states (i.e. reject what doesn't
    match certain types for idle, half-closed, reserved.
  - and likely define how to deal with known flags in the remaining

Just my two cents.