Re: HTTP/2 GREASE, Results, and Implications

Bence Béky <> Fri, 15 November 2019 15:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E81A120129 for <>; Fri, 15 Nov 2019 07:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 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, 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 sjPi1k8pwfoL for <>; Fri, 15 Nov 2019 07:20:10 -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 7792B120073 for <>; Fri, 15 Nov 2019 07:20:10 -0800 (PST)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iVdMU-000471-3w for; Fri, 15 Nov 2019 15:18:14 +0000
Resent-Date: Fri, 15 Nov 2019 15:18:14 +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 1iVdMS-00046J-58 for; Fri, 15 Nov 2019 15:18:12 +0000
Received: from ([2607:f8b0:4864:20::e29]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1iVdMQ-0005UD-G9 for; Fri, 15 Nov 2019 15:18:12 +0000
Received: by with SMTP id m9so6550597vsq.7 for <>; Fri, 15 Nov 2019 07:18:09 -0800 (PST)
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=6txBg4U2D7bsfiIsZzIux+vMlORnIvI6qEzzOsrwsRE=; b=e0PWci2aFzL0QKjYFGsYr7jlXjKVhfGlqH4lC0xEFe6Yfgwr+N+udJez8ihgGpZfjb t87xBsuO5WBRTFx3ZKltfWS90APB6wEOJhWE7AQR33Ull//mZUWyV5OXJbmEHdgJysFa 4dz0CrlUTCDnRdeR2hOb16jo5pBtteIR/ZiNQ=
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=6txBg4U2D7bsfiIsZzIux+vMlORnIvI6qEzzOsrwsRE=; b=iIHD2b2zqOpJMDPWIUaKEBImRuI1tzlAZLvG2WJW7pijq91O4JKH8JUm15tHJE2/Uj 7v2ZpcdTcopGTopLyLLBHSQwY67yvRu2Z8tCO/LMj1HF7xKiANHXtvBYjoMfUbo4633p 6LaHf09ICMZdAswhJ1XACxXseJEzHHmZAuAuPzHdTvtfog55SdhaXcH9RF1gYDCTclNz XFYybCR+v/LTun1EuQYSAI/LA1Ba1u7n4WMNeImXSmcU8K+xQ3cAfIhtb0OuivFohFPM rw+0ZbdnYPGpkECMdCU8VAN5yESR6xVAnWazKvs2b+t7/tgadWGTFFUjW3tbX9YVOIFO vBcw==
X-Gm-Message-State: APjAAAVONm9QRttOVqE/j4XkjCBqcMDXsfwQ9pjIEMEHBZlr5FanR3+T vHbF7XPY5vhgmUY2y+n8EeNOpd/Y7AERMXagWBJ09yVn
X-Google-Smtp-Source: APXvYqwFcddZZl8xorPjUzQLo4/Osm/cuy7j441TW9x+zPM+SnVBSI981tOpvwDSU8rf+JmGepO4bTKaNnlhtBTs0O8=
X-Received: by 2002:a67:db10:: with SMTP id z16mr5629651vsj.5.1573831088708; Fri, 15 Nov 2019 07:18:08 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: =?UTF-8?Q?Bence_B=C3=A9ky?= <>
Date: Fri, 15 Nov 2019 10:17:57 -0500
Message-ID: <>
To: Tom Bergan <>
Cc: Willy Tarreau <>, Stefan Eissing <>, Mike Bishop <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000fb1e250597641a7b"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e29;;
X-W3C-Hub-Spam-Status: No, score=-12.3
X-W3C-Scan-Sig: 1iVdMQ-0005UD-G9 f4804fdbd4107407388e3b9d7e078e62
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <>
X-Mailing-List: <> archive/latest/37135
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Tom,

Thank you for raising this issue.  I agree with the requirements that you
outline with respect to the NEW_PRIORITY frame.

Just a comment that in case it is not possible to resolve the issue in a
way that's favorable to the priority use case (for example, if the
timeframe for updating all deployments in not acceptable for the desired
timeframe of launching priorities), then another option would be to send
priority-related frames on stream 0, and encode the stream ID they refer to
within the frame payload.  Sure that's a waste of four bytes per frame, but
at least it should work (as long as implementations are correctly
discarding unknown frames on stream 0).


On Fri, Nov 15, 2019 at 10:10 AM Tom Bergan <> wrote:

> I would like to revisit the ambiguity that Willy pointed out in this
> thread. On the one hand, we have this statement, which appears in Sections
> 4.1 and 5.5:
> 1. Implementations MUST discard frames that have unknown or unsupported
> types.
> On the other hand, we have statements like the following, which appear in
> Section 5.1:
> 2a. idle: Receiving any frame other than HEADERS or PRIORITY on a stream
> in this state MUST be treated as a connection error.
> 2b. 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
> If this ambiguity is resolved in favor of Section 5.1, then it becomes
> difficult or impossible to define a new priority scheme in an HTTP/2
> extension. In particular:
> - It might be desirable to send a NEW_PRIORITY frame before HEADERS, as a
> replacement for priority information that is built into HEADERS. This
> conflicts with (2a).
> - It might be desirable to send a NEW_PRIORITY frame after END_STREAM, so
> the client can reprioritize a lengthy response. This conflicts with (2b).
> For this reason, I propose that this ambiguity should be resolved in favor
> of Section 5.5. We should release an errata which clarifies that the rules
> in Section 5.1 do not apply to frames of unknown type. If an extension
> defines a new frame type, it must explicitly enumerate the states in which
> that frame can be sent and received. Willy also raised a concern about new
> frame types that include END_STREAM. I think this is covered by Section
> 5.5, which says "Extensions that could change the semantics of existing
> protocol components MUST be negotiated before being used." If a new frame
> type can end the stream, this adds an edge to the state diagram in Section
> 5.1, therefore, support for the new frame type must be negotiated before it
> can be used.
> Thoughts?
> On Wed, Nov 6, 2019 at 12:27 PM Willy Tarreau <> wrote:
>> 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
>>     cases.
>> Just my two cents.
>> Cheers,
>> Willy