Re: HTTP/2 GREASE, Results, and Implications

Lucas Pardue <> Thu, 31 October 2019 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C25D0120864 for <>; Thu, 31 Oct 2019 08:48:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dhl1GJfdtzOb for <>; Thu, 31 Oct 2019 08:48: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 019C31208B5 for <>; Thu, 31 Oct 2019 08:48:36 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iQCeX-0000HM-CF for; Thu, 31 Oct 2019 15:46:25 +0000
Resent-Date: Thu, 31 Oct 2019 15:46:25 +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 1iQCeV-0000GW-8G for; Thu, 31 Oct 2019 15:46:23 +0000
Received: from ([2607:f8b0:4864:20::930]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1iQCeT-00009L-Nu for; Thu, 31 Oct 2019 15:46:23 +0000
Received: by with SMTP id o3so1975190ual.12 for <>; Thu, 31 Oct 2019 08:46:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A8AyOV+IiFdAvpayIiGK0n2ySO3AD3R09C1FpUWj74Q=; b=Z/RwgrMoyjhd6MKS0iog1BdXWDIsn11pozq4xgc1R3ffIk9Wix6fQAWZ+fK9Ifxeg6 6lJqt793/U6pqUmQFisTjlZN6p5IY/QorlsW55DbtW/Q/l7EJsiMazksvAFjWrxbNTix v4RKG2Xu8nrcwSA2teQBc4HviDc+9JmsZ6LZ5wMXHXZv2FlPbpI+nLrir6Zx69EMDcal Thev8UXvlLGP05g8b8S6LjGhtiOBpO7fDN8k/y8pAAVgO3UPfG/EJ+Cp9UVH+BwXj+af 773YTRR9F0pT5T4O6JzwpERTkYXvp4hUDaBuVwkPqp2gO4U1jLao+p2rzcRhdHuir4Ct I8HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A8AyOV+IiFdAvpayIiGK0n2ySO3AD3R09C1FpUWj74Q=; b=Cmv1Z82dI4QWvKl0Nfh0mENUdgn7bErasMwJIk0Fp8VvnSydr7rzIuoEY4INKsl7YK EjOZS9uwKv/a8YXPUy5AkyUFHgs9/XtoRi2bkXg8EYe6dbgkh3RmtJh6Ceo6yc0uZg+I wFVgahEODm/4JhfWgIiq0rqMMjGeaGxmhOgEDnV4ltt+MmO4rD37t+HtXPNb9xbBpACa AsicACTkPu7d11fKXm6Kv45xsOo2JP6id7kOprxWqShtyLz8n4pYw8VPrD+/3tfJvfq3 pjOjjwmXsPxqa+9yAXE9gFJYqtmIiY2HB8eu/ImWM9J8Gka4OGnhdRt+AyhYe46fjlcP XLRA==
X-Gm-Message-State: APjAAAVUsdzkqfDIIPyN9pgaZdxaP7+AleURWoy3qTbWzxvk+5ma79sA +J9fQiGSIcndjZwUP3ZuyHW87JLG0IGTkBZWeSzq9Sjc
X-Google-Smtp-Source: APXvYqxJ//tcufn3+BWie9cnmG/J72CJqSf2IjGc9vTyeHEggFlaE4UAQQR6tFl2udXfOgmwBGLDwHQ9u5bFjAxWco4=
X-Received: by 2002:ab0:1553:: with SMTP id p19mr3147684uae.80.1572536780177; Thu, 31 Oct 2019 08:46:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 31 Oct 2019 15:46:08 +0000
Message-ID: <>
To: Mike Bishop <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000002dc59c059636c06c"
Received-SPF: pass client-ip=2607:f8b0:4864:20::930;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Scan-Sig: 1iQCeT-00009L-Nu 7064eb2da27ec92d326fdcb46b7a7db9
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <>
X-Mailing-List: <> archive/latest/37084
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Oct 31, 2019 at 3:14 PM Mike Bishop <> wrote:

> Way back when, I presented a draft (
> proposing
> that we adopt as an HTTP/2 extension the same behaviors that HTTP/3 is
> specifying, permitting the greasing of settings and frame types.  The
> outcome of that discussion was that, prior to considering adoption, we’d
> want to understand the real-world impact of deploying such a behavior.
> Bence generously volunteered to add such an experiment to Chrome, which he
> has done.
> The results are discussed at  TL;DR:  Settings
> are fine, but too many servers blow up on unknown frame types for this to
> be viable in major client deployments.  They don’t even tell you what they
> don’t like – they just PROTOCOL_ERROR on you.

Thanks for the experimentation and sharing the results Mike and Bence.

Is the sense that this is symmetrically broken? Do we have data about how
server-sent GREASE frames might break clients? (and if not would that move
the needle at all).

> Frankly, this makes me quite sad.  It means that our primary extension
> mechanism for HTTP/2 has already rusted shut, and it’s now inadvisable to
> define new optional-to-understand frame types and send them without prior
> negotiation.
> Now that we have this data, are we interested in pursuing the draft with
> settings only, or perhaps reserving frame types but recommending caution in
> their use?

This indeed has some practical implications to active work in the group. I
can see how there might be some merit in capturing this situation, along
with some guidance, in a draft that can be reference by people making
HTTP/2 extensions.

Based on my experience of HTTP/3 interop to date, we are doing pretty well
with GREASE perhaps it is time to capture this in the matrix. I'd also like
to highlight that today the Cloudflare edge exercises all HTTP/3 grease
mechanisms* for all connections.

* unidirectional stream type GREASE is sent when sufficient stream credit
is provided by the client e.g. more than 3