From e5a860634b2077b6b9bb00050f83ff20a015ff9a Mon Sep 17 00:00:00 2001 From: Christian Lachner Date: Wed, 16 May 2018 14:44:53 +0200 Subject: [PATCH] haproxy: Update all patches for HAProxy v1.8.8 - Add new patches (see https://www.haproxy.org/bugs/bugs-1.8.8.html) - Raise patch-level to 04 Signed-off-by: Christian Lachner --- net/haproxy/Makefile | 2 +- ...e-large-proxy-IDs-can-be-represented.patch | 38 ++++++++++ ...t-always-abort-transfers-on-CF_SHUTR.patch | 70 +++++++++++++++++++ 3 files changed, 109 insertions(+), 1 deletion(-) create mode 100644 net/haproxy/patches/0015-BUG-MINOR-lua-ensure-large-proxy-IDs-can-be-represented.patch create mode 100644 net/haproxy/patches/0016-BUG-MEDIUM-http-dont-always-abort-transfers-on-CF_SHUTR.patch diff --git a/net/haproxy/Makefile b/net/haproxy/Makefile index 61ab5a545..8c3a714e9 100644 --- a/net/haproxy/Makefile +++ b/net/haproxy/Makefile @@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=haproxy PKG_VERSION:=1.8.8 -PKG_RELEASE:=03 +PKG_RELEASE:=04 PKG_SOURCE:=haproxy-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://www.haproxy.org/download/1.8/src/ diff --git a/net/haproxy/patches/0015-BUG-MINOR-lua-ensure-large-proxy-IDs-can-be-represented.patch b/net/haproxy/patches/0015-BUG-MINOR-lua-ensure-large-proxy-IDs-can-be-represented.patch new file mode 100644 index 000000000..dce13e4fa --- /dev/null +++ b/net/haproxy/patches/0015-BUG-MINOR-lua-ensure-large-proxy-IDs-can-be-represented.patch @@ -0,0 +1,38 @@ +commit edb4427ab7c070a16cb9a23460f68b3fc3c041bb +Author: Willy Tarreau +Date: Sun May 6 14:50:09 2018 +0200 + + BUG/MINOR: lua: ensure large proxy IDs can be represented + + In function hlua_fcn_new_proxy() too small a buffer was passed to + snprintf(), resulting in large proxy or listener IDs to make + snprintf() fail. It is unlikely to meet this case but let's fix it + anyway. + + This fix must be backported to all stable branches where it applies. + + (cherry picked from commit 29d698040d6bb56b29c036aeba05f0d52d8ce94b) + Signed-off-by: Willy Tarreau + +diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c +index a8d53d45..1df08f85 100644 +--- a/src/hlua_fcn.c ++++ b/src/hlua_fcn.c +@@ -796,7 +796,7 @@ int hlua_fcn_new_proxy(lua_State *L, struct proxy *px) + struct server *srv; + struct listener *lst; + int lid; +- char buffer[10]; ++ char buffer[17]; + + lua_newtable(L); + +@@ -836,7 +836,7 @@ int hlua_fcn_new_proxy(lua_State *L, struct proxy *px) + if (lst->name) + lua_pushstring(L, lst->name); + else { +- snprintf(buffer, 10, "sock-%d", lid); ++ snprintf(buffer, sizeof(buffer), "sock-%d", lid); + lid++; + lua_pushstring(L, buffer); + } diff --git a/net/haproxy/patches/0016-BUG-MEDIUM-http-dont-always-abort-transfers-on-CF_SHUTR.patch b/net/haproxy/patches/0016-BUG-MEDIUM-http-dont-always-abort-transfers-on-CF_SHUTR.patch new file mode 100644 index 000000000..0605b205d --- /dev/null +++ b/net/haproxy/patches/0016-BUG-MEDIUM-http-dont-always-abort-transfers-on-CF_SHUTR.patch @@ -0,0 +1,70 @@ +commit 1c10e5b1b95142bb3ac385be1e60d8b180b2e99e +Author: Willy Tarreau +Date: Wed May 16 11:35:05 2018 +0200 + + BUG/MEDIUM: http: don't always abort transfers on CF_SHUTR + + Pawel Karoluk reported on Discourse[1] that HTTP/2 breaks url_param. + + Christopher managed to track it down to the HTTP_MSGF_WAIT_CONN flag + which is set there to ensure the connection is validated before sending + the headers, as we may need to rewind the stream and hash again upon + redispatch. What happens is that in the forwarding code we refrain + from forwarding when this flag is set and the connection is not yet + established, and for this we go through the missing_data_or_waiting + path. This exit path was initially designed only to wait for data + from the client, so it rightfully checks whether or not the client + has already closed since in that case it must not wait for more data. + But it also has the side effect of aborting such a transfer if the + client has closed after the request, which is exactly what happens + in H2. + + A study on the code reveals that this whole combined check should + be revisited : while it used to be true that waiting had the same + error conditions as missing data, it's not true anymore. Some other + corner cases were identified, such as the risk to report a server + close instead of a client timeout when waiting for the client to + read the last chunk of data if the shutr is already present, or + the risk to fail a redispatch when a client uploads some data and + closes before the connection establishes. The compression seems to + be at risk of rare issues there if a write to a full buffer is not + yet possible but a shutr is already queued. + + At the moment these risks are extremely unlikely but they do exist, + and their impact is very minor since it mostly concerns an issue not + being optimally handled, and the fixes risk to cause more serious + issues. Thus this patch only focuses on how the HTTP_MSGF_WAIT_CONN + is handled and leaves the rest untouched. + + This patch needs to be backported to 1.8, and could be backported to + earlier versions to properly take care of HTTP/1 requests passing via + url_param which are closed immediately after the headers, though this + is unlikely as this behaviour is only exhibited by scripts. + + [1] https://discourse.haproxy.org/t/haproxy-1-8-x-url-param-issue-in-http2/2482/13 + + (cherry picked from commit ba20dfc50161ba705a746d54ebc1a0a45c46beab) + Signed-off-by: Willy Tarreau + +diff --git a/src/proto_http.c b/src/proto_http.c +index 4c18a27c..b384cef1 100644 +--- a/src/proto_http.c ++++ b/src/proto_http.c +@@ -4865,7 +4865,8 @@ int http_request_forward_body(struct stream *s, struct channel *req, int an_bit) + if (!(s->res.flags & CF_READ_ATTACHED)) { + channel_auto_connect(req); + req->flags |= CF_WAKE_CONNECT; +- goto missing_data_or_waiting; ++ channel_dont_close(req); /* don't fail on early shutr */ ++ goto waiting; + } + msg->flags &= ~HTTP_MSGF_WAIT_CONN; + } +@@ -4949,6 +4950,7 @@ int http_request_forward_body(struct stream *s, struct channel *req, int an_bit) + goto return_bad_req_stats_ok; + } + ++ waiting: + /* waiting for the last bits to leave the buffer */ + if (req->flags & CF_SHUTW) + goto aborted_xfer;