- From: Mike Bishop <mbishop@evequefou.be>
- Date: Thu, 31 Oct 2019 15:09:34 +0000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <BN6PR2201MB1700D10A34C72213C78E09A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.>
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. 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?
Received on Thursday, 31 October 2019 15:09:42 UTC