Re: HTTP/2 GREASE, Results, and Implications

Willy Tarreau <w@1wt.eu> Thu, 31 October 2019 17:18 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 741241200D7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Oct 2019 10:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 1Uo0esB2XJ7n for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Oct 2019 10:18:12 -0700 (PDT)
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 E532412008B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 31 Oct 2019 10:18:11 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iQE3N-0005NL-CD for ietf-http-wg-dist@listhub.w3.org; Thu, 31 Oct 2019 17:16:09 +0000
Resent-Date: Thu, 31 Oct 2019 17:16:09 +0000
Resent-Message-Id: <E1iQE3N-0005NL-CD@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 1iQE3M-0005MZ-1h for ietf-http-wg@listhub.w3.org; Thu, 31 Oct 2019 17:16:08 +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 1iQE3K-0005u2-7a for ietf-http-wg@w3.org; Thu, 31 Oct 2019 17:16:07 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x9VHFxUf030888; Thu, 31 Oct 2019 18:15:59 +0100
Date: Thu, 31 Oct 2019 18:15:59 +0100
From: Willy Tarreau <w@1wt.eu>
To: Bence Béky <bnc@chromium.org>
Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20191031171559.GB30874@1wt.eu>
References: <BN6PR2201MB1700D10A34C72213C78E09A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.com> <20191031155259.GC30674@1wt.eu> <CACMu3trL5UMukoPd8Nr4W-bMsyH+WKUnwg16yxu3tN5D=uZt8w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACMu3trL5UMukoPd8Nr4W-bMsyH+WKUnwg16yxu3tN5D=uZt8w@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 1iQE3K-0005u2-7a 823562a8eef3cd263a8f0365a7b1bce2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <https://www.w3.org/mid/20191031171559.GB30874@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37089
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 Thu, Oct 31, 2019 at 01:08:53PM -0400, Bence Béky wrote:
> 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.

OK. I have a pending patch ready for testing on the haproxy front which
addresses this mismatch. The only thing is that chrome beta doesn't seem
to be available on linux so I constantly have to bother other people for
testing, which takes time :-/

Regarding the impacts on our uesrs of anoyher test, I'm not much worried
of the risk to break a few sites running unfixed versions of haproxy if
a new Chrome version enables the test again; we've faced some hard to
diagnose bugs not too long ago and users are trained to disable H2 if
something really bad happens. Of course it's not desirable but it's not
as if everything definitely broke. Also our community tends to be quite
reactive when it comes to applying important fixes. Thus I full support
restarting the test ASAP :-)

Cheers,
Willy