MINOR: mux-h2: count late reduction of INITIAL_WINDOW_SIZE as a glitch

It's quite uncommon for a client to decide to change the connection's
initial window size after the settings exchange phase, unless it tries
to increase it. One of the impacts depending is that it updates all
streams, so it can be expensive, depending on the stacks, and may even
be used to construct an attack. For this reason, we now count a glitch
when this happens.

A test with h2spec shows that it triggers 9 across a full test.

diff --git a/src/mux_h2.c b/src/mux_h2.c
index 19aecf3..4925d8d 100644 (file)
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -2353,11 +2353,14 @@ static int h2c_handle_settings(struct h2c *h2c)
                                h2c_report_glitch(h2c);
                                goto fail;
                        }
-                       /* WT: maybe we should count a glitch here in case of a
-                        * change after H2_CS_SETTINGS1 because while it's not
+                       /* Let's count a glitch here in case of a reduction
+                        * after H2_CS_SETTINGS1 because while it's not
                         * fundamentally invalid from a protocol's perspective,
                         * it's often suspicious.
                         */
+                       if (h2c->st0 != H2_CS_SETTINGS1 && arg < h2c->miw)
+                               h2c_report_glitch(h2c);
+
                        h2c->miw = arg;
                        break;
                case H2_SETTINGS_MAX_FRAME_SIZE: