tree 7b9c6b53f82b6760c306f83b9f240802928779fc
parent 617592c9ebb6fb879e7f2f8f0456e8e3a0c280ff
author Glenn Strauss <gstrauss@gluelogic.com> 1654395110 -0400
committer Willy Tarreau <w@1wt.eu> 1654759701 +0200
encoding latin1

OPTIM: mux-h2: increase h2_settings_initial_window_size default to 64k

This changes the default from RFC 7540's default 65535 (64k-1) to avoid
avoid some degenerative WINDOW_UPDATE behaviors in the wild observed with
clients using 65536 as their buffer size, and have to complete each block
with a 1-byte frame, which with some servers tend to degenerate in 1-byte
WU causing more 1-byte frames to be sent until the transfer almost only
uses 1-byte frames.

More details here: https://github.com/nghttp2/nghttp2/issues/1722

As mentioned in previous commit (MEDIUM: mux-h2: try to coalesce outgoing
WINDOW_UPDATE frames) the issue could not be reproduced with haproxy but
individual WU frames are sent so theoretically nothing prevents this from
happening. As such it should be backported as a workaround for already
deployed clients after watching for any possible side effect with rare
clients. As an added benefit, uploads from curl now use less DATA frames
(all are 16384 now). Note that the previous patch alone is sufficient to
stop the issue with curl in case this one would need to be reverted.

[wt: edited commit messaged, updated doc]