Re: HTTP/2 GREASE, Results, and Implications
Willy Tarreau <w@1wt.eu> Fri, 15 November 2019 16:02 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 7D5C9120801 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 08:02:11 -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 korrfdIJzCy4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 08:02:05 -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 A4C03120892 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Nov 2019 08:01:56 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iVe0L-0000tM-T0 for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Nov 2019 15:59:25 +0000
Resent-Date: Fri, 15 Nov 2019 15:59:25 +0000
Resent-Message-Id: <E1iVe0L-0000tM-T0@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <w@1wt.eu>) id 1iVe0K-0000sT-1x for ietf-http-wg@listhub.w3.org; Fri, 15 Nov 2019 15:59:24 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by titan.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1iVe0I-0006dQ-DJ for ietf-http-wg@w3.org; Fri, 15 Nov 2019 15:59:23 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id xAFFxDtd025399; Fri, 15 Nov 2019 16:59:13 +0100
Date: Fri, 15 Nov 2019 16:59:13 +0100
From: Willy Tarreau <w@1wt.eu>
To: Tom Bergan <tombergan@chromium.org>
Cc: Bence Béky <bnc@chromium.org>, Stefan Eissing <stefan.eissing@greenbytes.de>, Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20191115155913.GD25181@1wt.eu>
References: <BN6PR2201MB1700D10A34C72213C78E09A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.com> <20191031155259.GC30674@1wt.eu> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+3+x5GyCgh2JROXwd+mo3Rsew1EDzJ6diyvHoLv3JwbJLg6Xg@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: titan.w3.org 1iVe0I-0006dQ-DJ 9e840a880f4db96938e255173e89a744
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <https://www.w3.org/mid/20191115155913.GD25181@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37136
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>
Hi Tom, first, thanks for reloading this. On Fri, Nov 15, 2019 at 07:10:31AM -0800, 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. (...) > 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 we do this, we should really change the wording to never use "other than" and instead explicitly mention the list of frame types that are not permitted in each state. > 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. I'm fine with this point. However I do have a real concern regarding deployed code now based on the fact that the way this ambiguity is present can have caused solid roots to be set inside some software. For example when trying to address the issue in haproxy, I noticed that we've used bit fields of permitted frame types to more easily match what's allowed or not. When working around them I figured that changing tests constructed this way to think in terms of exclusion instead wasn't always as riskfree as I initially imagined, and if we relax certain rules we need to be sure that (almost) all implementations will accept to revisit their code and take such risks in maintenance versions to allow smooth updates of deployed components, or we really risk the same type of fragmentation that we've known with HTTP/1.1. I have been wondering if we could classify frame types into 2 or 3 categories : - those permitted on stream 0 - those permitted on an open stream - those permitted after END_STREAM or on an idle stream I even suspect that the last one should be cut into two. The question was whether we could have imagined simplifying the handling of extra frame types by saying that only certain ranges of frame types will be permitted in certain situations which would allow to better handle extensions in the future, but after checking in my code I'm not convinced anymore that this could really help. Thus I think that your point about any frame type adding a new arc on the state graph should only be used through negotiation is probably the only option. But I still do have some concerns about our ability to extend the protocol even without this. What if a new frame expects an ACK for example ? Probably this one will also require an extension. And for those plugged on the stream without the ability to really participate (typically a firewall or a wireshark dissector), maybe declaring that the ACK flag is always the same bit 0 and that any frame type holding an ACK should be ignored regardless of the context could make sense. Just a few thoughts. Willy
- HTTP/2 GREASE, Results, and Implications Mike Bishop
- Re: HTTP/2 GREASE, Results, and Implications Lucas Pardue
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- RE: HTTP/2 GREASE, Results, and Implications Mike Bishop
- Re: HTTP/2 GREASE, Results, and Implications Ian Swett
- Re: HTTP/2 GREASE, Results, and Implications Bence Béky
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- RE: HTTP/2 GREASE, Results, and Implications Mike Bishop
- Re: HTTP/2 GREASE, Results, and Implications Lucas Pardue
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications David Benjamin
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications David Benjamin
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications Bence Béky
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications Stefan Eissing
- Re: HTTP/2 GREASE, Results, and Implications Bence Béky
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications Tom Bergan
- Re: HTTP/2 GREASE, Results, and Implications Bence Béky
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications Tom Bergan
- Re: HTTP/2 GREASE, Results, and Implications Willy Tarreau
- Re: HTTP/2 GREASE, Results, and Implications Dmitri Tikhonov
- Re: HTTP/2 GREASE, Results, and Implications Stefan Eissing