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]
diff --git a/src/mux_h2.c b/src/mux_h2.c
index 4b615fc..cd3b579 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -518,7 +518,7 @@
/* a few settings from the global section */
static int h2_settings_header_table_size = 4096; /* initial value */
-static int h2_settings_initial_window_size = 65535; /* initial value */
+static int h2_settings_initial_window_size = 65536; /* initial value */
static unsigned int h2_settings_max_concurrent_streams = 100;
static int h2_settings_max_frame_size = 0; /* unset */