]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MINOR: h2: always trim leading and trailing LWS in header values
authorWilly Tarreau <w@1wt.eu>
Mon, 24 Feb 2025 08:17:22 +0000 (09:17 +0100)
committerWilly Tarreau <w@1wt.eu>
Mon, 24 Feb 2025 08:39:57 +0000 (09:39 +0100)
commitbbf824933f71eca90b5f07a51fa93f4fa7ac2256
tree96c52960262519e7822f6d5758d1d24be86027a9
parent9011b3621b283efb6872ae9a3ae7fa02f94ad190
BUG/MINOR: h2: always trim leading and trailing LWS in header values

Annika Wickert reported some occasional disconnections between haproxy
and varnish when communicating over HTTP/2, with varnish complaining
about protocol errors while captures looked apparently normal. Nils
Goroll managed to reproduce this on varnish by injecting the capture of
the outgoing haproxy traffic and noticed that haproxy was forwarding a
header value containing a trailing space, which is now explicitly
forbidden since RFC9113.

It turns out that the only way for such a header to pass through haproxy
is to arrive in h2 and not be edited, in which case it will arrive in
HTX with its undesired spaces. Since the code dealing with HTX headers
always trims spaces around them, these are not observable in dumps, but
only when started in debug mode (-d). Conversions to/from h1 also drop
the spaces.

With this patch we trim LWS both on input and on output. This way we
always present clean headers in the whole stack, and even if some are
manually crafted by the configuration or Lua, they will be trimmed on
the output.

This must be backported to all stable versions.

Thanks to Annika for the helpful capture and Nils for the help with
the analysis on the varnish side!
src/h2.c
src/mux_h2.c