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:
parent
28dfd006ca
commit
9f3a0834d8
|
@ -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:
|
||||
|
|
Loading…
Reference in New Issue