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 <w@1wt.eu>
+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 <w@1wt.eu>
+
+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 <w@1wt.eu>
+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 <w@1wt.eu>
+
+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;