- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Mon, 18 Feb 2019 11:38:17 +0000
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Mike Bishop <mbishop@evequefou.be>, Graham King <graham@gkgk.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 Monday, 18 February 2019 11:38:50 UTC