RE: HTTP/2 re-sync connection level flow control?

I agree that there's no value in trying to "correct" values on the fly -- if there's a bug, it should be fixed, not patched over.  But an extension that allows immediate detection of the bug (and blows up the connection) rather than letting it bog down and eventually stall the connection?  That seems like it could have value if it were broadly implemented.

-----Original Message-----
From: Cory Benfield <cory@lukasa.co.uk> 
Sent: Monday, February 18, 2019 3:38 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Mike Bishop <mbishop@evequefou.be>; Graham King <graham@gkgk.org>; ietf-http-wg@w3.org
Subject: Re: HTTP/2 re-sync connection level flow control?

On Mon, 18 Feb 2019 at 09:21, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>
> As to the original question: I doubt that adding a "resync" will help interoperability. If connection state goes out of whack, it is due to bugs in the implementation of the protocol (e.g. discarding frames without counting them in flow control). Adding a 'resync' handshake will add complexity to the connection state - not simplify it, I believe.

Agreed, I'm opposed to a resync. Fundamentally this is an implementation bug: flow controlled frames are *always* flow controlled, and must have their flow control state modification made before they are checked for validity. This is the same as HEADERS
frames: you must always attempt to decode the body of the HEADERS frame unless the frame is so ill-formed that it is not parseable and leads to immediate connection error of type PROTOCOL_ERROR.

Received on Tuesday, 26 February 2019 00:30:49 UTC