PKG_NAME:=haproxy
PKG_VERSION:=1.4.24
-PKG_RELEASE:=02
+PKG_RELEASE:=09
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://haproxy.1wt.eu/download/1.4/src
--- /dev/null
+From d45840bd28f5cf604d320ab9ff308ba7ba8c0b28 Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Fri, 21 Jun 2013 08:20:19 +0200
+Subject: [PATCH 3/9] MEDIUM: session: disable lingering on the server when the
+ client aborts
+
+When abortonclose is used and an error is detected on the client side,
+better force an RST to the server. That way we propagate to the server
+the same vision we got from the client, and we ensure that we won't keep
+TIME_WAITs.
+
+(cherry picked from commit 8615c2af67dc2be07bdb246ed13130fe7d32e3d1)
+---
+ src/session.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/session.c b/src/session.c
+index 21ecb9f..9ed932c 100644
+--- a/src/session.c
++++ b/src/session.c
+@@ -1370,8 +1370,11 @@ resync_stream_interface:
+ buffer_shutw_now(s->req);
+
+ /* shutdown(write) pending */
+- if (unlikely((s->req->flags & (BF_SHUTW|BF_SHUTW_NOW|BF_OUT_EMPTY)) == (BF_SHUTW_NOW|BF_OUT_EMPTY)))
++ if (unlikely((s->req->flags & (BF_SHUTW|BF_SHUTW_NOW|BF_OUT_EMPTY)) == (BF_SHUTW_NOW|BF_OUT_EMPTY))) {
++ if (s->req->flags & BF_READ_ERROR)
++ s->req->cons->flags |= SI_FL_NOLINGER;
+ s->req->cons->shutw(s->req->cons);
++ }
+
+ /* shutdown(write) done on server side, we must stop the client too */
+ if (unlikely((s->req->flags & (BF_SHUTW|BF_SHUTR|BF_SHUTR_NOW)) == BF_SHUTW &&
+--
+1.8.1.5
+
--- /dev/null
+From 25d0a14ada411dc73b55b55d5b27599ccd2fa4a2 Mon Sep 17 00:00:00 2001
+From: Godbach <nylzhaowei@gmail.com>
+Date: Wed, 26 Jun 2013 16:49:51 +0800
+Subject: [PATCH 4/9] BUG/MINOR: deinit: free fdinfo while doing cleanup
+
+Both fdinfo and fdtab are allocated memory in init() while haproxy is starting,
+but only fdtab is freed in deinit(), fdinfo should also be freed.
+
+Signed-off-by: Godbach <nylzhaowei@gmail.com>
+(cherry picked from commit 4cc1b0d4ef283b5ace5249483ec7eb3b1fc5d193)
+---
+ src/haproxy.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/haproxy.c b/src/haproxy.c
+index 7a09e3f..c163743 100644
+--- a/src/haproxy.c
++++ b/src/haproxy.c
+@@ -941,6 +941,7 @@ void deinit(void)
+ free(global.pidfile); global.pidfile = NULL;
+ free(global.node); global.node = NULL;
+ free(global.desc); global.desc = NULL;
++ free(fdinfo); fdinfo = NULL;
+ free(fdtab); fdtab = NULL;
+ free(oldpids); oldpids = NULL;
+
+--
+1.8.1.5
+
--- /dev/null
+From ee591233efd57d625fea9057a975281fb8f4d358 Mon Sep 17 00:00:00 2001
+From: Godbach <nylzhaowei@gmail.com>
+Date: Mon, 22 Jul 2013 07:44:53 +0800
+Subject: [PATCH 5/9] BUG/MEDIUM: server: set the macro for server's max weight
+ SRV_UWGHT_MAX to SRV_UWGHT_RANGE
+
+The max weight of server is 256 now, but SRV_UWGHT_MAX is still 255. As a result,
+FWRR will not work well when server's weight is 256. The description is as below:
+
+There are some macros related to server's weight in include/types/server.h:
+ #define SRV_UWGHT_RANGE 256
+ #define SRV_UWGHT_MAX (SRV_UWGHT_RANGE - 1)
+ #define SRV_EWGHT_MAX (SRV_UWGHT_MAX * BE_WEIGHT_SCALE)
+
+Since weight of server can be reach to 256 and BE_WEIGHT_SCALE equals to 16,
+the max eweight of server should be 256*16 = 4096, it will exceed SRV_EWGHT_MAX
+which equals to SRV_UWGHT_MAX*BE_WEIGHT_SCALE = 255*16 = 4080. When a server
+with weight 256 is insterted into FWRR tree during initialization, the key value
+of this server should be SRV_EWGHT_MAX - s->eweight = 4080 - 4096 = -16 which
+is closed to UINT_MAX in unsigned type, so the server with highest weight will
+be not elected as the first server to process request.
+
+In addition, it is a better choice to compare with SRV_UWGHT_MAX than a magic
+number 256 while doing check for the weight. The max number of servers for
+round-robin algorithm is also updated.
+
+Signed-off-by: Godbach <nylzhaowei@gmail.com>
+(cherry picked from commit a34bdc0ea402ea5be1e9d7f80eaddec772b94393)
+---
+ doc/configuration.txt | 2 +-
+ include/types/backend.h | 4 ++--
+ include/types/server.h | 2 +-
+ src/cfgparse.c | 6 +++---
+ src/lb_fwrr.c | 2 +-
+ 5 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/doc/configuration.txt b/doc/configuration.txt
+index 6e0add7..a008cd7 100644
+--- a/doc/configuration.txt
++++ b/doc/configuration.txt
+@@ -1141,7 +1141,7 @@ balance url_param <param> [check_post [<max_wait>]]
+ processing time remains equally distributed. This algorithm
+ is dynamic, which means that server weights may be adjusted
+ on the fly for slow starts for instance. It is limited by
+- design to 4128 active servers per backend. Note that in some
++ design to 4095 active servers per backend. Note that in some
+ large farms, when a server becomes up after having been down
+ for a very short time, it may sometimes take a few hundreds
+ requests for it to be re-integrated into the farm and start
+diff --git a/include/types/backend.h b/include/types/backend.h
+index dc4786e..1067125 100644
+--- a/include/types/backend.h
++++ b/include/types/backend.h
+@@ -102,8 +102,8 @@
+ * weight modulation even with small weights (eg: 1). It should not be too high
+ * though because it limits the number of servers in FWRR mode in order to
+ * prevent any integer overflow. The max number of servers per backend is
+- * limited to about 2^32/255^2/scale ~= 66051/scale. A scale of 16 looks like
+- * a good value, as it allows more than 4000 servers per backend while leaving
++ * limited to about (2^32-1)/256^2/scale ~= 65535.9999/scale. A scale of 16
++ * looks like a good value, as it allows 4095 servers per backend while leaving
+ * modulation steps of about 6% for servers with the lowest weight (1).
+ */
+ #define BE_WEIGHT_SCALE 16
+diff --git a/include/types/server.h b/include/types/server.h
+index 14e4d1f..9fbd290 100644
+--- a/include/types/server.h
++++ b/include/types/server.h
+@@ -69,7 +69,7 @@
+
+ /* various constants */
+ #define SRV_UWGHT_RANGE 256
+-#define SRV_UWGHT_MAX (SRV_UWGHT_RANGE - 1)
++#define SRV_UWGHT_MAX (SRV_UWGHT_RANGE)
+ #define SRV_EWGHT_RANGE (SRV_UWGHT_RANGE * BE_WEIGHT_SCALE)
+ #define SRV_EWGHT_MAX (SRV_UWGHT_MAX * BE_WEIGHT_SCALE)
+
+diff --git a/src/cfgparse.c b/src/cfgparse.c
+index 345b415..7d349b3 100644
+--- a/src/cfgparse.c
++++ b/src/cfgparse.c
+@@ -3639,9 +3639,9 @@ stats_error_parsing:
+ else if (!strcmp(args[cur_arg], "weight")) {
+ int w;
+ w = atol(args[cur_arg + 1]);
+- if (w < 0 || w > 256) {
+- Alert("parsing [%s:%d] : weight of server %s is not within 0 and 256 (%d).\n",
+- file, linenum, newsrv->id, w);
++ if (w < 0 || w > SRV_UWGHT_MAX) {
++ Alert("parsing [%s:%d] : weight of server %s is not within 0 and %d (%d).\n",
++ file, linenum, newsrv->id, SRV_UWGHT_MAX, w);
+ err_code |= ERR_ALERT | ERR_FATAL;
+ goto out;
+ }
+diff --git a/src/lb_fwrr.c b/src/lb_fwrr.c
+index d92b6eb..7f5c8a9 100644
+--- a/src/lb_fwrr.c
++++ b/src/lb_fwrr.c
+@@ -343,7 +343,7 @@ static void fwrr_queue_srv(struct server *s)
+ * lower the scale, the rougher the weights modulation, and the
+ * higher the scale, the lower the number of servers without
+ * overflow. With this formula, the result is always positive,
+- * so we can use eb3é_insert().
++ * so we can use eb32_insert().
+ */
+ s->lb_node.key = SRV_UWGHT_RANGE * s->npos +
+ (unsigned)(SRV_EWGHT_MAX + s->rweight - s->eweight) / BE_WEIGHT_SCALE;
+--
+1.8.1.5
+
--- /dev/null
+From 3bd693057420af0cd04132fdfb7c59e56aa90421 Mon Sep 17 00:00:00 2001
+From: Godbach <nylzhaowei@gmail.com>
+Date: Wed, 7 Aug 2013 09:48:23 +0800
+Subject: [PATCH 6/9] BUG/MINOR: use the same check condition for server as
+ other algorithms
+
+Such load balance algorithms as roundrobin, leastconn and first will check the
+server after being selected with the following condition:
+ if (!s->maxconn || (!s->nbpend && s->served < srv_dynamic_maxconn(s)))
+
+But static-rr uses the different one in map_get_server_rr() as below:
+ if (!srv->maxconn || srv->cur_sess < srv_dynamic_maxconn(srv))
+After viewing this difference, it is a better choice for static-rr to use the
+same check condition as other algorithms.
+
+This change will only affect static-rr. Though all hash algorithms with type
+map-based will use the same server map as static-rr, they call another function
+map_get_server_hash() to get server.
+
+Signed-off-by: Godbach <nylzhaowei@gmail.com>
+(cherry picked from commit 8f9fd2f0a0893761afeb6800c7b62a51d782af0e)
+---
+ src/lb_map.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/lb_map.c b/src/lb_map.c
+index 49805ad..9858249 100644
+--- a/src/lb_map.c
++++ b/src/lb_map.c
+@@ -229,7 +229,7 @@ struct server *map_get_server_rr(struct proxy *px, struct server *srvtoavoid)
+ avoididx = 0; /* shut a gcc warning */
+ do {
+ srv = px->lbprm.map.srv[newidx++];
+- if (!srv->maxconn || srv->cur_sess < srv_dynamic_maxconn(srv)) {
++ if (!srv->maxconn || (!srv->nbpend && srv->served < srv_dynamic_maxconn(srv))) {
+ /* make sure it is not the server we are try to exclude... */
+ if (srv != srvtoavoid) {
+ px->lbprm.map.rr_idx = newidx;
+--
+1.8.1.5
+
--- /dev/null
+From 8c1b1be9e4f11a8474f64dcb85d507a57b6cfe9f Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Tue, 13 Aug 2013 17:19:08 +0200
+Subject: [PATCH 7/9] MINOR: config: warn when a server with no specific port
+ uses rdp-cookie
+
+Mathew Levett reported an issue which is a bit nasty and hard to track
+down. RDP cookies contain both the IP and the port, and haproxy matches
+them exactly. So if a server has no port specified (or a remapped port),
+it will never match a port specified in a cookie. Better warn the user
+when this is detected.
+(cherry picked from commit 82ffa39bfd34e5680cb65cc0b7ef625c0a274856)
+---
+ src/cfgparse.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/src/cfgparse.c b/src/cfgparse.c
+index 7d349b3..cecec03 100644
+--- a/src/cfgparse.c
++++ b/src/cfgparse.c
+@@ -5638,6 +5638,12 @@ out_uri_auth_compat:
+ err_code |= ERR_WARN;
+ }
+
++ if ((newsrv->state & SRV_MAPPORTS) && (curproxy->options2 & PR_O2_RDPC_PRST)) {
++ Warning("config : %s '%s' : RDP cookie persistence will not work for server '%s' because it lacks an explicit port number.\n",
++ proxy_type_str(curproxy), curproxy->id, newsrv->id);
++ err_code |= ERR_WARN;
++ }
++
+ #if defined(CONFIG_HAP_CTTPROXY) || defined(CONFIG_HAP_LINUX_TPROXY)
+ if (curproxy->mode != PR_MODE_HTTP && newsrv->bind_hdr_occ) {
+ newsrv->bind_hdr_occ = 0;
+--
+1.8.1.5
+
--- /dev/null
+From 92518a563b9c1f9117e1dec2cc2a8ae95b1643d6 Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Fri, 24 Feb 2012 19:20:12 +0100
+Subject: [PATCH 8/9] MEDIUM: increase chunk-size limit to 2GB-1
+
+Since commit 115acb97, chunk size was limited to 256MB. There is no reason for
+such a limit and the comment on the code suggests a missing zero. However,
+increasing the limit past 2 GB causes trouble due to some 32-bit subtracts
+in various computations becoming negative (eg: buffer_max_len). So let's limit
+the chunk size to 2 GB - 1 max.
+(cherry picked from commit 431946e9617572d2813bd5a8f5a51ce36f841ea3)
+---
+ src/proto_http.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/proto_http.c b/src/proto_http.c
+index 22a7737..7fd1fe6 100644
+--- a/src/proto_http.c
++++ b/src/proto_http.c
+@@ -2112,7 +2112,7 @@ int http_parse_chunk_size(struct buffer *buf, struct http_msg *msg)
+ break;
+ if (++ptr >= end)
+ ptr = buf->data;
+- if (chunk & 0xF000000) /* overflow will occur */
++ if (chunk & 0xF8000000) /* integer overflow will occur if result >= 2GB */
+ goto error;
+ chunk = (chunk << 4) + c;
+ }
+--
+1.8.1.5
+
--- /dev/null
+From fdeb2171b83ab4fd5db36f1c45d57e2100529076 Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Sat, 31 Aug 2013 08:16:26 +0200
+Subject: [PATCH 9/9] DOC: add a mention about the limited chunk size
+
+We now indicate that PD flags can be returned for chunk sizes >= 2GB.
+(cherry picked from commit f3a3e1389e40434da9e1fc295be6ff5a8037effb)
+---
+ doc/configuration.txt | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/doc/configuration.txt b/doc/configuration.txt
+index a008cd7..56438dd 100644
+--- a/doc/configuration.txt
++++ b/doc/configuration.txt
+@@ -8044,7 +8044,8 @@ easier finding and understanding.
+ PD The proxy blocked an incorrectly formatted chunked encoded message in
+ a request or a response, after the server has emitted its headers. In
+ most cases, this will indicate an invalid message from the server to
+- the client.
++ the client. Haproxy supports chunk sizes of up to 2GB - 1 (2147483647
++ bytes). Any larger size will be considered as an error.
+
+ PH The proxy blocked the server's response, because it was invalid,
+ incomplete, dangerous (cache control), or matched a security filter.
+--
+1.8.1.5
+
projects / openwrt / svn-archive / packages.git / commitdiff