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 19aecf352c040d228349b1e760ceaf2c56eb49ec..4925d8d155ae8e69efa0cad7f68dd5e78eef252e 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: