From 9f3a0834d8e4c1416c0e266e987d9c0378558659 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Thu, 8 Feb 2024 14:37:56 +0100 Subject: [PATCH] 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. --- src/mux_h2.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/mux_h2.c b/src/mux_h2.c index 19aecf352c..4925d8d155 100644 --- 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: