DOC: typo: nosepoll self reference in config guide
BUG/MINOR: fix forcing fastinter in "on-error"

health_adjust() should requeue the task after changing its expire timer.

I noticed it on devel servers without load. We have long inter (10 seconds)
and short fasinter (100ms). But according to webserver logs, after a failed
request next check request was called with same 10s interval.

This patch should probably be backported to 1.4 which has the same feature.
(cherry picked from commit 1d57e508104ccd085c1e70d147edcba9f6960c1b)
BUG/MINOR: acl: remove patterns from the tree before freeing them

A call to free_pattern_tree() upon exit() is made to free all ACL
patterns allocated in a tree (strings or IP addresses). Unfortunately
it happens that this function has been bogus from the beginning, it
walks over the whole tree, frees the nodes but forgets to remove them
from the tree prior to freeing them. So after visiting a leaf, the
next eb_next() call will require to revisit some of the upper nodes
that were just freed. This can remain unnoticed for a long time because
free() often just marks the area as free. But in cases of aggressive
memory freeing, the location will not be mapped anymore and the process
segfaults.

Note that the bug has no impact other than polluting kernel logs and
frightening sysadmins, since it happens just before exit().

Simply adding the debug code below makes it easier to reproduce the
same bug :

	while (node) {
		next = eb_next(node);
+		node->node_p = (void *)-1;
		free(node);
		node = next;
	}

Many thanks to the StackExchange team for their very detailed bug report
that permitted to quickly understand this non-obvious bug!

This fix should be backported to 1.4 which introduced the bug.
(cherry picked from commit 60eccc18419763680f1cd08abfe8711e9170f9b0)
BUG/MEDIUM: checks: fix slow start regression after fix attempt

Commit 2e99390 (BUG/MEDIUM: checks: fix slowstart behaviour when server
tracking is in use) moved the slowstart task initialization within the
health check code and leaves it unset when checks are disabled. The
problem is that it's possible to trigger slowstart from the CLI by
issuing "disable server XXX / enable server XXX" even when checks are
disabled. The result is a crash when trying to wake up the slowstart
task of that server.

Move the task initialization earlier so that it is done even if the
checks are disabled.

This patch should be backported to 1.4 since the commit above was
backported there.
(cherry picked from commit e7b73485d0a2dbf7572f78756234337d1277b46c)
BUG/MAJOR: server: weight calculation fails for map-based algorithms

A crash was reported by Igor at owind when changing a server's weight
on the CLI. Lukas Tribus could reproduce a related bug where setting
a server's weight would result in the new weight being multiplied by
the initial one. The two bugs are the same.

The incorrect weight calculation results in the total farm weight being
larger than what was initially allocated, causing the map index to be out
of bounds on some hashes. It's easy to reproduce using "balance url_param"
with a variable param, or with "balance static-rr".

It appears that the calculation is made at many places and is not always
right and not always wrong the same way. Thus, this patch introduces a
new function "server_recalc_eweight()" which is dedicated to this task
of computing ->eweight from many other elements including uweight and
current time (for slowstart), and all users now switch to use this
function.

The patch is a bit large but the code was not trivially fixable in a way
that could guarantee this situation would not occur anymore. The fix is
much more readable and has been verified to work with all algorithms,
with both consistent and map-based hashes, and even with static-rr.

Slowstart was tested as well, just like enable/disable server.

The same bug is very likely present in 1.4 as well, so the patch will
probably need to be backported eventhough it will not apply as-is.

Thanks to Lukas and Igor for the information they provided to reproduce it.
(cherry picked from commit 004e045f3141cedcfe578a102a2a0d4e68363a15)
BUG/MINOR: backend: fix target address retrieval in transparent mode

A very old bug resulting from some code refactoring causes
assign_server_address() to refrain from retrieving the destination
address from the client-side connection when transparent mode is
enabled and we're connecting to a server which has address 0.0.0.0.

The impact is low since such configurations are unlikely to ever
be encountered. The fix should be backported to older branches.
(cherry picked from commit 1903acdf3ad70228b7760505c666b754bf86db47)
BUG/MEDIUM: stick: completely remove the unused flag from the store entries

The store[] array in the session holds a flag which probably aimed to
differenciate store entries learned from the request from those learned
from the response, and allowing responses to overwrite only the request
ones (eg: have a server set a response cookie which overwrites the request
one).

But this flag is set when a response data is stored, and is never cleared.
So in practice, haproxy always runs with this flag set, meaning that
responses prevent themselves from overriding the request data.

It is desirable anyway to keep the ability not to override data, because
the override is performed only based on the table and not on the key, so
that would mean that it would be impossible to retrieve two different
keys to store into a same table. For example, if a client sets a cookie
and a server another one, both need to be updated in the table in the
proper order. This is especially true when multiple keys may be tracked
on each side into the same table (eg: list of IP addresses in a header).

So the correct fix which also maintains the current behaviour consists in
simply removing this flag and never try to optimize for the overwrite case.

This fix also has the benefit of significantly reducing the session size,
by 64 bytes due to alignment issues caused by this flag!

The bug has been there forever (since 1.4-dev7), so a backport to 1.4
would be appropriate.
(cherry picked from commit 37e340ce4bdcaa73d10d8f9d538ae02e29b40605)
BUG/MEDIUM: stick-tables: complete the latest fix about store-responses

The commit 37e340c (BUG/MEDIUM: stick: completely remove the unused flag
from the store entries) was incomplete. We also need to ensure that only
the first store-response for a table is applied and that it may coexist
with a possible store-request that was already done on this table.

This patch with the previous one should be backported to 1.4.
(cherry picked from commit 9667a80676f9113f6954366d5ed25012d6b8197b)
BUG/MEDIUM: checks: tracking servers must not inherit the MAINT flag

If a server is disabled in configuration and another one tracks it,
this last one must not inherit the MAINT flag otherwise it needs to
be explicitly enabled afterwards. Just remove this to fix the issue.
(cherry picked from commit 566226b9d7a242ca3cafbc26ea9d70ddb40d4135)
BUG/MINOR: stats: report correct throttling percentage for servers in slowstart

The column used to report the throttle percentage when a server is in
slowstart is based on the time only. This is wrong, because server weights
in slowstart are updated at most once a second, so the reported value is
wrong at least fo rone second during each step, which means all the time
when using short delays (< 20s).

The second point is that it's disturbing to see a weight < 100% without
any throttle at the end of the period (during the last second), because
the effective weight has not yet been updated.

Instead, we now compute the exact ratio between eweight and uweight and
report it. It's always accurate and describes the value being used instead
of using only the date.

It can be backported to 1.4 though it's not particularly important.
(cherry picked from commit d32c399747f77d62dc107854b549d40ac94b835b)
BUG/MINOR: stats: correctly report throttle rate of low weight servers

The throttling of low weight servers (<16) could mistakenly be reported
as > 100% due to a rounding that was performed before a multiply by 100
instead of after. This was introduced in 1.5-dev20 when fixing a previous
reporting issue by commit d32c399 (MINOR: stats: report correct throttling
percentage for servers in slowstart).

It should be backported if the patch above is backported.
(cherry picked from commit e38feed966070142e1fd5d3033c9e999a9ffe83c)
BUG/MINOR: checks: successful check completion must not re-enable MAINT servers

If a server is switched to maintenance mode while a check is in progress,
the successful completion of the check must not switch it back up. This
is still a consequence of using the same function set_server_up() for
every state change. Bug reported by Igor at owind.

This fix should be backported to 1.4 which is affected as well.
(cherry picked from commit 9f708ab7070bce622d867eca3947256d50d9619d)
BUG/MEDIUM: stats: the web interface must check the tracked servers before enabling

When enabling a tracked server via the web interface, we must first
check if the server tracks another one and the state of this tracked
server, just like the command line does.

Failure to do so causes incorrect logs to be emitted when the server
is enabled :

[WARNING] 361/212556 (2645) : Server bck2/srv3 is DOWN via bck2/srv2. 2 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 361/212603 (2645) : Server bck2/srv3 is DOWN for maintenance.
--> enable server now
[WARNING] 361/212606 (2645) : Server bck2/srv3 is UP (leaving maintenance).

With this fix, it's correct now :

[WARNING] 361/212805 (2666) : Server bck2/srv3 is DOWN via bck2/srv2. 2 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 361/212813 (2666) : Server bck2/srv3 is DOWN for maintenance.
--> enable server now
[WARNING] 361/212821 (2666) : Server bck2/srv3 is DOWN via bck2/srv2. 2 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

It does not seem necessary to backport this fix, considering that it
depends on extremely fragile behaviours, there are more risks of breakage
caused by a backport than the current inconvenience.
(cherry picked from commit a3ae932d3498eb154604cf319a9c49636c4f859d)
BUG/MEDIUM: http/auth: Sometimes the authentication credentials can be mix between two requests

The authentication function "get_http_auth()" extract credentials from
the request and keep it this values in shared cache. This function set
a flag in the session indicating that the authentication is already
parsed and the value stored in the cache are avalaible. If this flag is
set the authorization header is not re-parsed and the shared cache is
used.

If two request are simultaneous processsed, the first one check the
credentials. After this, the second request check also it's credentials
and change the data stored in the shared cache. When the first request
re-check credentials (for many reasons), they are changed. The change
can introduce a segfault.

This patch deactivate the cache upon success. When we need
authentication information from one request, they are re-parsed and
re-decoded. However, a failure to retrieve credentials is still
cached to avoid useless lookups.

This fix needs to be backported to 1.4 as well.
(cherry picked from commit 98d9695518283e6fca5fe688fcbb61b77f21ba13)
BUG/MINOR: channel: initialize xfer_small/xfer_large on new buffers

These ones are only reset during transfers. There is a low but non-null
risk that a first full read causes the previous value to be reused and
immediately to immediately set the CF_STREAMER flag. The impact is only
to increase earlier than expected the SSL record size and to use splice().

This bug was already present in 1.4, so a backport is possible.
(cherry picked from commit 8f39dcdc8d48b28c2a76eac27aeb78ee89b3ae3f)
BUG/MINOR: stream-int: also consider ENOTCONN in addition to EAGAIN

A failed send() may return ENOTCONN when the connection is not yet established.
On Linux, we generally see EAGAIN but on OpenBSD we clearly have ENOTCONN, so
let's ensure we poll for write when we encounter this error.
(cherry picked from commit 0ea0cf606e1da866b1c1e1b25dbe3472ccaaa6d8)
BUG/MINOR: stream-int: also consider ENOTCONN in addition to EAGAIN for recv()

I was testing haproxy-1.5-dev22 on SmartOS (an illumos-based system)
and ran into a problem.  There's a small window after non-blocking
connect() is called, but before the TCP connection is established,
where recv() may return ENOTCONN.  On Linux, the behaviour here seems
to be always to return EAGAIN.  The fix is relatively trivial, and
appears to make haproxy work reliably on current SmartOS (see patch
below).  It's possible that other UNIX platforms exhibit this
behaviour as well.

Note: the equivalent was already done for send() in commit 0ea0cf6
("BUG: raw_sock: also consider ENOTCONN in addition to EAGAIN").
Both patches should be backported to 1.4.
(cherry picked from commit 0724903143fc3077a587732fdb4b76a12615a35f)
BUG/MEDIUM: http: don't start to forward request data before the connect

Currently, "balance url_param check_post" randomly works. If the client
sends chunked data and there's another chunk after the one containing the
data, http_request_forward_body() will advance msg->sov and move the start
of data to the beginning of the last chunk, and get_server_ph_post() will
not find the data.

In order to avoid this, we add an HTTP_MSGF_WAIT_CONN flag whose goal is
to prevent the forwarding code from parsing until the connection is
confirmed, so that we're certain not to fail on a redispatch. Note that
we need to force channel_auto_connect() since the output buffer is empty
and a previous analyser might have stopped auto-connect.

The flag is currently set whenever some L7 POST analysis is needed for a
connect() so that it correctly addresses all corner cases involving a
possible rewind of the buffer, waiting for a better fix.

Note that this has been broken for a very long time. Even all 1.4 versions
seem broken but differently, with ->sov pointing to the end of the arguments.
So the fix should be considered for backporting to all stable releases,
possibly including 1.3 which works differently.

(cherry picked from commit 80a92c02f478dc1b836e0c97c891875437fc54da)

Note for 1.4:
-------------

There is no http_msg->flags, and txn->flags is full, so instead the
flag was added to the session's flags, which is acceptable for a
maintenance branch.
DOC: fix misleading information about SIGQUIT

SIGQUIT dumps the pools state to stderr, not to the logs. Thanks to
Jim Freeman for reporting this.
(cherry picked from commit d153b3b09615d850dbced3ff6362b3117182821d)
BUILD: simplify the date and version retrieval in the makefile

The makefile currently uses some complex and non-always portable
methods to retrieve the date and version (eg: linux's date command).

For the date, we can use git log -1 --pretty=format:%ci instead of
date+sed. For the version, it's easier and safer to count single log
lines.

Note that the VERSION variable was wrong since it could contain the
version+subversion instead of just the version. This is now fixed by
adding --abbrev=0 in describe.

(cherry picked from commit 689e4d733f54b12bea8ac9d1768ed8162c69d248)