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.
This commit is contained in:
Willy Tarreau 2024-02-08 14:37:56 +01:00
parent 28dfd006ca
commit 9f3a0834d8
1 changed files with 5 additions and 2 deletions

View File

@ -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: