]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: mux-h1/mux-fcgi: Reject messages with unknown transfer encoding
authorChristopher Faulet <cfaulet@haproxy.com>
Tue, 28 Sep 2021 07:50:07 +0000 (09:50 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Tue, 28 Sep 2021 14:39:47 +0000 (16:39 +0200)
commitda3adebd06a85cacbdca577f03e433243c351fe9
tree24519cf2afd8f74fe587d95e514d7ffc3e2e33e6
parent545fbba2733a1f611ce940ecd5fbea1130b6d503
BUG/MEDIUM: mux-h1/mux-fcgi: Reject messages with unknown transfer encoding

HAproxy only handles "chunked" encoding internally. Because it is a gateway,
we stated it was not a problem if unknown encodings were applied on a
message because it is the recipient responsibility to accept the message or
not. And indeed, it is not a problem if both the client and the server
connections are using H1. However, Transfer-Encoding headers are dropped
from H2 messages. It is not a problem for chunk-encoded payload because
dechunking is performed during H1 parsing. But, for any other encodings, the
xferred H2 message is invalid.

It is also a problem for internal payload manipulations (lua,
filters...). Because the TE request headers are now sanitiezd, unsupported
encoding should not be used by servers. Thus it is only a problem for the
request messages. For this reason, such messages are now rejected. And if a
server decides to use an unknown encoding, the response will also be
rejected.

Note that it is pretty uncommon to use other encoding than "chunked" on the
request payload. So it is not necessary to backport it.

This patch should fix the issue #1301. No backport is needed.
src/mux_fcgi.c
src/mux_h1.c