Subject: Section 6.9 (WINDOW_UPDATE), shouldn't it always be a connection error if window increment is 0?

From: Matthew Cox <[email-masked]>
Date: Tue, 5 Aug 2014 16:33:36 +0000

Draft 14 adds this paragraph to section 6.9:

   A receiver MUST treat the recipt of a WINDOW_UPDATE frame with an

   flow control window increment of 0 as a stream error (Section 5.4.2<http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.4.2>)

   of type PROTOCOL_ERROR; errors on the connection flow control window
   MUST be treated as a connection error (Section 5.4.1<http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.4.1>).

The only allowed values are 1 to 2^31 - 1.  This would lead me to believe that this should always be a connection error instead of being based on the stream id in the frame.

I don't see any reason to allow a server to send a bogus frame in this way even if they set a stream id.

Unless someone has a good reason to allow this I purpose making this always a connection error regardless of the intended target of the window update.

Thanks,

Matthew

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Aug 2014 09:40:40 -0700

On 5 August 2014 09:33, Matthew Cox <[email-masked]> wrote:
> I don’t see any reason to allow a server to send a bogus frame in this way
> even if they set a stream id.

Of course a client would *never* send one ;)

> Unless someone has a good reason to allow this I purpose making this always
> a connection error regardless of the intended target of the window update.

As always, it is your prerogative to turn stream errors into
connection errors.  I generally encourage people to do so. I don't
think that the spec needs to take such an aggressive line here though.