W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

RE: HTTP/2 GREASE, Results, and Implications

From: Mike Bishop <mbishop@evequefou.be>
Date: Thu, 31 Oct 2019 17:49:47 +0000
To: Mike Bishop <mbishop@evequefou.be>, Lucas Pardue <lucaspardue.24.7@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <BN6PR2201MB1700DA200AA4C756558170A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.com>
Upon further investigation, it appears that Akamai hosts most of the sites where the connection gets closed, and Cloudflare hosts the sites which close the stream but leave the connection open (I’m guessing, from what the dev tools show).  Given that we’re both represented here, it seems likely that we should be able to drive some internal bugfixes and improve the state of the ecosystem.

From: Mike Bishop <mbishop@evequefou.be>
Sent: Thursday, October 31, 2019 11:57 AM
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: RE: HTTP/2 GREASE, Results, and Implications

Bence’s experiment didn’t cover anything server-sent, that I’m aware of.  Of course, if Cloudflare would like to do a corresponding experiment…?  😉

From: Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>>
Sent: Thursday, October 31, 2019 11:46 AM
To: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>
Cc: HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: HTTP/2 GREASE, Results, and Implications


On Thu, Oct 31, 2019 at 3:14 PM Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>> wrote:
Way back when, I presented a draft (https://tools.ietf.org/html/draft-bishop-httpbis-grease-00) 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 https://crbug.com/1019410.  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.


Thanks for the experimentation and sharing the results Mike and Bence.

Is the sense that this is symmetrically broken? Do we have data about how server-sent GREASE frames might break clients? (and if not would that move the needle at all).

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?

This indeed has some practical implications to active work in the group. I can see how there might be some merit in capturing this situation, along with some guidance, in a draft that can be reference by people making HTTP/2 extensions.

Based on my experience of HTTP/3 interop to date, we are doing pretty well with GREASE perhaps it is time to capture this in the matrix. I'd also like to highlight that today the Cloudflare edge exercises all HTTP/3 grease mechanisms* for all connections.

* unidirectional stream type GREASE is sent when sufficient stream credit is provided by the client e.g. more than 3

Received on Thursday, 31 October 2019 17:49:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC