HTTP/2 GREASE experiment results

Bence Béky <> Fri, 11 September 2020 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFC433A0A7E for <>; Fri, 11 Sep 2020 09:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i2RV_Zi9JqI1 for <>; Fri, 11 Sep 2020 09:04:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7DB33A090C for <>; Fri, 11 Sep 2020 09:04:42 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kGlUC-0001BH-Tq for; Fri, 11 Sep 2020 16:01:17 +0000
Resent-Date: Fri, 11 Sep 2020 16:01:16 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kGlUB-0001Ae-7U for; Fri, 11 Sep 2020 16:01:15 +0000
Received: from ([2607:f8b0:4864:20::32c]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1kGlU9-0001cn-5W for; Fri, 11 Sep 2020 16:01:15 +0000
Received: by with SMTP id g96so8721159otb.12 for <>; Fri, 11 Sep 2020 09:01:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:from:date:message-id:subject:to; bh=spdirs6rDZ1m8CripkY9v+oSzygFPdi/8uJc7SxYKME=; b=RS6MbCb3ZlIReW3hLb6e2L7BvH3QNMtj/3eaMtedVw0bL+g298jsV8YNYxODvHtk2T hWiJKCQfK+KSrXKFotWGSa74fkulIubgQxS+loAKfdJwKjhO5i8vbQOT++txME7L/gKO /oGdKXNjAu62QuES5Fw1NkRyzJHocXTr4xFQU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=spdirs6rDZ1m8CripkY9v+oSzygFPdi/8uJc7SxYKME=; b=VgLntUSoZueuxemL0oNNnL3QmRbyfv+cZN+iv7i3y953FE0caUITI5CJ3/HkK5kOK9 mc2xnfEZh0gej9YjBfqD1PfL3o3u3xhmOBswJfpZGfLIim7bc9ue4HE1baJx3/QVTTDf fq0xTqDalMLLbdSBip9HAo5+g/AkKk403WTfQ6SKbJceb7gvCR+IjT49l7/8oAtMqKaM QddkFMF0yFVjm+CikfA5LZ5XShvdmEITNo3R0d5LIShfPrS1pTrWo9dPDEc38qmh8YPJ Tm1NzCbsGLfOtATA9UCgVgufWr7d4v+n4SpZveNIHHmCfNkLwXAMDLrFJI7A6ZoIpnUC 74ew==
X-Gm-Message-State: AOAM532YaGLdihTvE1I03nwqMTdOLfIeW2pEk/QC0Y0cjaBK8uWzL9n+ OqSAIcr+yWCFkKpzkLP6FAS3I15X4ciNtx/G/jLRxxNqlCxICA==
X-Google-Smtp-Source: ABdhPJyYrZrHTSl8EC61/4F4yIXhmhg23NZBVm9u3Fb3AIV67xdTQ0gsPUWKVKa0MUz9hI6S9TRoBTG8w7wODInIvUY=
X-Received: by 2002:a9d:688:: with SMTP id 8mr1534354otx.122.1599840061491; Fri, 11 Sep 2020 09:01:01 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?Q?Bence_B=C3=A9ky?= <>
Date: Fri, 11 Sep 2020 12:00:49 -0400
Message-ID: <>
To: HTTP <>
Content-Type: multipart/alternative; boundary="00000000000090855105af0bcaba"
Received-SPF: pass client-ip=2607:f8b0:4864:20::32c;;
X-W3C-Hub-Spam-Status: No, score=-12.2
X-W3C-Scan-Sig: 1kGlU9-0001cn-5W dd5d5337c88e8189e52073e0706105f3
Subject: HTTP/2 GREASE experiment results
Archived-At: <>
X-Mailing-List: <> archive/latest/38040
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


Chrome users are experiencing GREASE intolerance on,
see for details.  If any developers from Slack
read this, please respond on the ticket (or to me privately).

(I already sent the rest of this e-mail three days ago as a response to a
different thread, but mistakenly from my other address, so it didn't go
through.  Also it possibly deserves its own thread.)

Here is a summary of recent HTTP/2 GREASE experiments in Chrome.  The
findings can inform deployment of new HTTP/2 extensions.  Note that I have
not performed any server-side experiments, so I have no information about
clients' intolerances in the wild.  I am aware of a bug of unknown setting
identifier intolerance in very old OkHttp client versions, not sure how
widely they are still used.

I'm only naming implementations for reference, so that people can
check for old versions and gauge the state of the ecosystem.  By no
means do I mean to shame anybody.  In fact I introduced a number of
bugs in Chrome's GREASE implementation, both correctness issues and
crashers, that substantially slowed down my experiments.

Last fall it was discovered that ATS does not tolerate unknown setting
identifiers.  This bug has already been fixed by the time Chrome users
ran into it.  The fix got backported to 8.0.6 and by now it is widely
deployed.  50% of Chrome Dev and Canary has been sending reserved
setting identifiers again since May.

This spring it was discovered that WinHTTP and certain
Microsoft-operated cloud-based web services cannot handle an HTTP/2
request without a body if it is serialized as a HEADERS frame without
the END_STREAM flag followed by an empty DATA frame with the
END_STREAM flag.  (This was done by Chrome in order to insert a
reserved frame in between.)  This is not GREASE-intolerance, but a
failure of HTTP/2 compliance nonetheless.  The fix has been deployed
for cloud services, but WinHTTP has not been fixed, and "it’s possible
that this will impact other IIS sites using the 'ARR' load

Two weeks ago I restarted the reserved frame type experiment, but
without splitting bodyless requests this time.  Reserved frames are
sent after the SETTINGS and SETTINGS ACK frames on stream 0, and
before every DATA frame (in practice this means POST requests).  It
has been reported that LiteSpeed responds to the ones on stream 0 with
a PING ACK, which causes Chrome to close the connection since there
has been no unacked PINGs.  The LiteSpeed team is already fixing it.

And there is the issue with, see above.

This experiment is too recent to conclude that there are no
medium-sized intolerant deployments still out there, but I think it is
safe to assume that there are no large intolerant deployments.  (And
as far as small ones, we might never be able to find them, at least
not with Dev and Canary channels only.)

Overall I would say the ecosystem is in a pretty good shape when looking
from the client side.