W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

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

From: Cory Benfield <cory@lukasa.co.uk>
Date: Mon, 18 Feb 2019 11:38:17 +0000
Message-ID: <CAH_hAJHcxhuoGqcZ69Qp2gsrPAqgc6Rbm9KMkBqa+RsT-K-Oig@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 18 February 2019 11:38:51 UTC