Re: HTTP/2 GREASE, Results, and Implications

Willy Tarreau <w@1wt.eu> Fri, 15 November 2019 20:41 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E4C12011F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 12:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level:
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufJPpdTu73hx for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 12:41:13 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [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 ietfa.amsl.com (Postfix) with ESMTPS id 8201912006F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Nov 2019 12:41:13 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iViMN-0008G0-KU for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Nov 2019 20:38:27 +0000
Resent-Date: Fri, 15 Nov 2019 20:38:27 +0000
Resent-Message-Id: <E1iViMN-0008G0-KU@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <w@1wt.eu>) id 1iViML-0008FE-LD for ietf-http-wg@listhub.w3.org; Fri, 15 Nov 2019 20:38:25 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1iViMJ-0005CN-TB for ietf-http-wg@w3.org; Fri, 15 Nov 2019 20:38:25 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id xAFKcFRV026667; Fri, 15 Nov 2019 21:38:15 +0100
Date: Fri, 15 Nov 2019 21:38:15 +0100
From: Willy Tarreau <w@1wt.eu>
To: Tom Bergan <tombergan@chromium.org>
Cc: Bence =?iso-8859-1?Q?B=E9ky?= <bnc@chromium.org>, Stefan Eissing <stefan.eissing@greenbytes.de>, Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20191115203815.GA26651@1wt.eu>
References: <CACMu3trL5UMukoPd8Nr4W-bMsyH+WKUnwg16yxu3tN5D=uZt8w@mail.gmail.com> <20191031203458.GA31017@1wt.eu> <CACMu3toue60Y_6Qxpzsqw-fOByc3Qjv=AG8Ed_DGvkR1EYn+4w@mail.gmail.com> <20191101131903.GA1988@1wt.eu> <6F4160E3-D460-4DD9-9931-348479F6437F@greenbytes.de> <CACMu3trFUKpywX1GoChNn59B1tOmOUuaPESVFPy2u7Ah3gy0Jw@mail.gmail.com> <20191106202411.GA15081@1wt.eu> <CA+3+x5GyCgh2JROXwd+mo3Rsew1EDzJ6diyvHoLv3JwbJLg6Xg@mail.gmail.com> <20191115155913.GD25181@1wt.eu> <CA+3+x5GNnHn-MyYO0cDhc6ma1A4CfJMTZ5KBV+ifD5VYkj6brA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+3+x5GNnHn-MyYO0cDhc6ma1A4CfJMTZ5KBV+ifD5VYkj6brA@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
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: mimas.w3.org 1iViMJ-0005CN-TB 9985bc952bb206ca7262cfd12b377559
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <https://www.w3.org/mid/20191115203815.GA26651@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37139
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Fri, Nov 15, 2019 at 11:35:13AM -0800, Tom Bergan wrote:
> It's important to work through these implementation issues. If
> implementations are difficult to change, then we'll probably need to take
> Bence's suggestion, or something similar.

Regardless of these issues, Bence's proposal sounds appealing to me for
a better layering.

> That said, I don't fully understand the problem here. Can you elaborate?
> Assuming the implementation throws away unknown frames immediately, as
> suggested by Section 5.5, only the known frames are left. At that point, it
> shouldn't matter whether the bit mask describes permitted frames or
> forbidden frames -- both approaches are equivalent.

Oh it's very simple to understand: due to the rules restricting the frame
types depending on the stream state, the frames are matched against the
stream state early during the processing. In fact proceeding as you
suggest would make the code simpler, it's just that it's changing the
logic, and while I do see how to adapt mine for this (with limited risks
of regressions when it comes to backport this to deployed maintenance
branches), it's easily imaginable that and equivalent level of complexity
(not high, just moderate) can affect other deployed implementations,
causing some reluctance to changing existing code in field.

I *am* personally willing to make the change if there is consensus on
this. I even hacked a minimal patch for this after Mike's report. I'm
just not assuming that everyone will do so in an eyeblink.

Another option could be to refrain from sending new frame types until
a setting has been advertised by the other end. I just find this a bit
sad. That's exactly what the minor version in the protocol was for. We
could have had HTTP/2.1 advertised over ALPN to instantly match both
ends, but now we have to do without this possibility.

Willy