- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 12 Oct 2023 08:14:57 +0200
- To: Martin Thomson <mt@lowentropy.net>
- Cc: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Oct 12, 2023 at 04:35:57PM +1100, Martin Thomson wrote: > But in justifying that change, you aren't just arguing that a 100 should be a > 10 (or whatever), you are also arguing that we need to go through the entire > process of updating an RFC. That means not just agreeing that 10 is better > than 100, but also agreeing that all the work necessary to draft and publish > a revised RFC is also worth it because that 10 is that much better than the > 100. The process which can speed such things up is the errata but there's no error here, the intent is clearly stated even if it's absurd. At best it could be stated that clients are encouraged to stick to lower values when no limit is presented to them, but that could have the inverse effect as desired, by showing server implementers that the defaults have become safe over time. Regardless, there's no point in trying to change the default value anymore since due to this issue, very likely that the rare servers that would previously not emit such a limit will now start to emit one anyway. Also, as Kazuho said, even low values are not a protection. If an update was deserved, it would definitely be to change the algorithm itself and adopt something like your proposal which transfers the control of stream creation acceptance to the server while remaining backward compatible. That's clearly something I intend to implement to get rid of this old annoyance, as it will also finally help us implement cleaner graceful connection closures by refusing to offer new streams to the client without having to send early GOAWAY frames. Willy
Received on Thursday, 12 October 2023 06:15:19 UTC