- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 15 Nov 2019 17:02:15 +0100
- To: Bence Béky <bnc@chromium.org>
- Cc: Tom Bergan <tombergan@chromium.org>, Stefan Eissing <stefan.eissing@greenbytes.de>, Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Bence, On Fri, Nov 15, 2019 at 10:17:57AM -0500, Bence Béky wrote: > Hi Tom, > > Thank you for raising this issue. I agree with the requirements that you > outline with respect to the NEW_PRIORITY frame. > > Just a comment that in case it is not possible to resolve the issue in a > way that's favorable to the priority use case (for example, if the > timeframe for updating all deployments in not acceptable for the desired > timeframe of launching priorities), then another option would be to send > priority-related frames on stream 0, and encode the stream ID they refer to > within the frame payload. Sure that's a waste of four bytes per frame, but > at least it should work (as long as implementations are correctly > discarding unknown frames on stream 0). Actually I think I like this and probably we should have done this as well for WINDOW_UPDATE (it's always easy to say afterwards). Because such frames which may reference closed streams are really more related to the connection's health than to the stream itself in fact and that would make more sense in the way they are processed. Cheers, Willy
Received on Friday, 15 November 2019 16:02:25 UTC