Re: HTTP/2 GREASE, Results, and Implications

Bence Béky <> Thu, 31 October 2019 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58FA1120800 for <>; Thu, 31 Oct 2019 10:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 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.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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lVBhB_T5c3v3 for <>; Thu, 31 Oct 2019 10:12:14 -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 9586F120886 for <>; Thu, 31 Oct 2019 10:12:14 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iQDwc-0005pO-NL for; Thu, 31 Oct 2019 17:09:10 +0000
Resent-Date: Thu, 31 Oct 2019 17:09:10 +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 1iQDwa-0005of-HR for; Thu, 31 Oct 2019 17:09:08 +0000
Received: from ([2607:f8b0:4864:20::e2b]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1iQDwY-0002z5-Nu for; Thu, 31 Oct 2019 17:09:08 +0000
Received: by with SMTP id 190so36256vss.8 for <>; Thu, 31 Oct 2019 10:09:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mp5LgTHCPvv5Ek6GODB15ktY1IHo+G/0KDCD8xwBHo8=; b=aqYcH1TDczNTL6qgzrQTSIG3gCVgy/G/8JOd6cJMzp7eUceNgqJli4tP0V+SrtG5PJ YqXE2yNZ1YSqtQ1NqCFyMwLduhAWyES6pPOVdd68MCcGrOvNX3ZTEqRVj4a4MV5l72ji u9nQnAPHkxbcAM8gmdtPdJQ4tdQS60gI6PvWE=
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=Mp5LgTHCPvv5Ek6GODB15ktY1IHo+G/0KDCD8xwBHo8=; b=VDjBrhn9rRsjjn9cOinmvZeS2oa16z7uPVOoN/JnBofBsVKjVSRJDTYycyvi95vv2V ffiIpyx7qBlzRWXCtxHq6ic1Ss6QeReLSqnm6qnXnCDSKBmGES9eJCcCm0IHcaXenaTi CLvm2jWXQ8igkiTg0zy7hUWLd94cTIWFtehR4WkDXQxmBfx7YY3rCKei6jJKi536rOUs KaQ3PPEEGXr7U3zVcY73CMXvxzgC2rODRX1GZeY0TbM6oIfQBOHlyZNMWaHM6azLBrFf tIvoUjxQ/ejV+0Wbj0je3Nux+DcGEYctV5xGO415Jr9Jj0zSpwPMBgRo+sgdRA6KhDzh yjeg==
X-Gm-Message-State: APjAAAVO/s/q1/ru04yYaGau9PG5pH7D+p0emVFmVi/kKoYB6oCBz8ng U0qiF8JQFfBvvK03ScLG7H4UDZX3A55eT2ApYBdF8TiJ
X-Google-Smtp-Source: APXvYqyU78rFlD6VAROhXdotsrLv7r7D0L9Bq2/Rnda6/MdivtdAPPwiXs2hKwBpotvQ5dx6gUqXIOtt1C7BTI0gAAA=
X-Received: by 2002:a67:f24d:: with SMTP id y13mr3401438vsm.123.1572541745259; Thu, 31 Oct 2019 10:09:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: =?UTF-8?Q?Bence_B=C3=A9ky?= <>
Date: Thu, 31 Oct 2019 13:08:53 -0400
Message-ID: <>
To: Willy Tarreau <>
Cc: Mike Bishop <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000001f410c059637e8c4"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e2b;;
X-W3C-Hub-Spam-Status: No, score=-12.2
X-W3C-Scan-Sig: 1iQDwY-0002z5-Nu e67900322118a27dfb60bd843ee6bfca
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <>
X-Mailing-List: <> archive/latest/37088
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.  It might be worth fixing that and re-running the
experiment.  I'll circle back with results if we end up doing that.

On Thu, Oct 31, 2019 at 11:55 AM Willy Tarreau <> wrote:

> Hi Mike!
> On Thu, Oct 31, 2019 at 03:09:34PM +0000, 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.
> >
> > 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?
> Ah! That's interesting, so that's the problem Yves and me have been
> working on yesterday where we found frame types 0xF7 sent by a Beta
> version of Chrome and rejected by haproxy! At least now we have an
> explanation! And I have a bug to fix now.
> But quite frankly that's exactly the expected outcome of a spec written
> in directive way instead of normative. I mean, instead of indicating
> state transitions it says what an agent must do. It's impossible for
> such a long text to remain consistent along the whole document and you
> end up with some conflicting rules. Here in the traces we've collected
> yesterday, we've found a frame type 0xF7 sent in half-closed(remote)
> state. And the spec says :
>    half-closed (remote):
>       If an endpoint receives additional frames, other than
>       WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in
>       this state, it MUST respond with a stream error (Section 5.4.2) of
>       type STREAM_CLOSED.
> So by this rule, the 0xF7 I saw was not permitted.
> Further down it says:
>    In the absence of more specific guidance elsewhere in this document,
>    implementations SHOULD treat the receipt of a frame that is not
>    expressly permitted in the description of a state as a connection
>    error (Section 5.4.1) of type PROTOCOL_ERROR.  Note that PRIORITY can
>    be sent and received in any stream state.  Frames of unknown types
>    are ignored.
> And it's just in the middle of a paragraph in 5.5 that I can see :
>    Implementations MUST discard frames that have unknown or unsupported
>    types.
> With that said, for the cases I'm responsible of, the fixes are easy,
> and I'm even fine with tagging them as major bugs so that the fixes
> flow down into distros. Clearly, we try to fight protocol ossification
> but by writing specs that look almost like code with very strict rules
> we encourage it by accident, and we must be extremely careful about
> this in the future.
> I also think that for future designs, indicating prominently in a
> spec that some type ranges are reserved for experimentation and
> some for extensions will already ring a bell to some developers.
> There's still a problem is with already deployed code, but H2 compatible
> components in field are still young and experiencing frequent updates,
> so users will easily apply fixes. Thus I think that it's probably not
> to late to continue to enforce using unknown frame types to send such
> signals from time to time is the best way to make sure they're updated.
> And, just like there have been flag days for IPv6 or DNS, we could have
> some H2 days once or twice a year during which browsers will send random
> protocol elements. Just making this public will encourage users to care
> about the correctness of their components and pressure their vendors to
> provide a compliant implementation.
> Just my two cents,
> Willy