Commit Graph

4129 Commits

Author SHA1 Message Date
Willy Tarreau
b1982e27aa BUG/MEDIUM: http/session: disable client-side expiration only after body
For a very long time, back in the v1.3 days, we used to rely on a trick
to avoid expiring the client side while transferring a payload to the
server. The problem was that if a client was able to quickly fill the
buffers, and these buffers took some time to reach the server, the
client should not expire while not sending anything.

In order to cover this situation, the client-side timeout was disabled
once the connection to the server was OK, since it implied that we would
at least expire on the server if required.

But there is a drawback to this : if a client stops uploading data before
the end, its timeout is not enforced and we only expire on the server's
timeout, so the logs report a 504.

Since 1.4, we have message body analysers which ensure that we know whether
all the expected data was received or not (HTTP_MSG_DATA or HTTP_MSG_DONE).
So we can fix this problem by disabling the client-side or server-side
timeout at the end of the transfer for the respective side instead of
having it unconditionally in session.c during all the transfer.

With this, the logs now report the correct side for the timeout. Note that
this patch is not enough, because another issue remains : the HTTP body
forwarders do not abort upon timeout, they simply rely on the generic
handling from session.c. So for now, the session is still aborted when
reaching the server timeout, but the culprit is properly reported. A
subsequent patch will address this specific point.

This bug was tagged MEDIUM because of the changes performed. The issue
it fixes is minor however. After some cooling down, it may be backported
to 1.4.

It was reported by and discussed with Rachel Chavez and Patrick Hemmer
on the mailing list.
2014-05-07 14:21:47 +02:00
William Lallemand
07c8b24edb MINOR: http: export the smp_fetch_cookie function
Remove the static attribute of smp_fetch_cookie, and declare the
function in proto/proto_http.h for future use.
2014-05-02 18:05:15 +02:00
Emeric Brun
b73a9b039c MINOR: ssl: convert to binary ssl_fc_unique_id and ssl_bc_unique_id.
Previously ssl_fc_unique_id and ssl_bc_unique_id return a string encoded
in base64 of the RFC 5929 TLS unique identifier. This patch modify those fetches
to return directly the ID in the original binary format. The user can make the
choice to encode in base64 using the converter.

i.e. : ssl_fc_unique_id,base64
2014-04-30 22:31:11 +02:00
Emeric Brun
53d1a98270 MINOR: ssl: adds sample converter base64 for binary type.
The new converter encode binary type sample to base64 string.

i.e. : ssl_c_serial,base64
2014-04-30 22:31:11 +02:00
Emeric Brun
55f4fa8825 MINOR: ssl: adds ssl_f_sha1 fetch to return frontend's certificate fingerprint
ssl_f_sha1 is a binary binary fetch used to returns the SHA-1 fingerprint of
the certificate presented by the frontend when the incoming connection was
made over an SSL/TLS transport layer. This can be used to know which
certificate was chosen using SNI.
2014-04-30 22:31:11 +02:00
Emeric Brun
ba841a1da1 MINOR: ssl: merge client's and frontend's certificate functions. 2014-04-30 22:31:11 +02:00
Emeric Brun
645ae79b40 MINOR: ssl: adds fetchs and ACLs for ssl back connection.
Adds ssl fetchs and ACLs for outgoinf SSL/Transport layer connection with their
docs:
ssl_bc, ssl_bc_alg_keysize, ssl_bc_cipher, ssl_bc_protocol, ssl_bc_unique_id,
ssl_bc_session_id and ssl_bc_use_keysize.
2014-04-30 22:31:11 +02:00
Emeric Brun
5bd99b4bd6 MINOR: ssl: clean unused ACLs declarations
Now those ACLs are automatically created from pattern fetch declare.
2014-04-30 22:16:39 +02:00
Willy Tarreau
644c101e2d BUG/MAJOR: http: connection setup may stall on balance url_param
On the mailing list, seri0528@naver.com reported an issue when
using balance url_param or balance uri. The request would sometimes
stall forever.

Cyril Bonté managed to reproduce it with the configuration below :

  listen test :80
    mode http
    balance url_param q
    hash-type consistent
    server s demo.1wt.eu:80

and found it appeared with this commit : 80a92c0 ("BUG/MEDIUM: http:
don't start to forward request data before the connect").

The bug is subtle but real. The problem is that the HTTP request
forwarding analyzer refrains from starting to parse the request
body when some LB algorithms might need the body contents, in order
to preserve the data pointer and avoid moving things around during
analysis in case a redispatch is later needed. And in order to detect
that the connection establishes, it watches the response channel's
CF_READ_ATTACHED flag.

The problem is that a request analyzer is not subscribed to a response
channel, so it will only see changes when woken for other (generally
correlated) reasons, such as the fact that part of the request could
be sent. And since the CF_READ_ATTACHED flag is cleared once leaving
process_session(), it is important not to miss it. It simply happens
that sometimes the server starts to respond in a sequence that validates
the connection in the middle of process_session(), that it is detected
after the analysers, and that the newly assigned CF_READ_ATTACHED is
not used to detect that the request analysers need to be called again,
then the flag is lost.

The CF_WAKE_WRITE flag doesn't work either because it's cleared upon
entry into process_session(), ie if we spend more than one call not
connecting.

Thus we need a new flag to tell the connection initiator that we are
specifically interested in being notified about connection establishment.
This new flag is CF_WAKE_CONNECT. It is set by the requester, and is
cleared once the connection succeeds, where CF_WAKE_ONCE is set instead,
causing the request analysers to be scanned again.

For future versions, some better options will have to be considered :
  - let all analysers subscribe to both request and response events ;
  - let analysers subscribe to stream interface events (reduces number
    of useless calls)
  - change CF_WAKE_WRITE's semantics to persist across calls to
    process_session(), but that is different from validating a
    connection establishment (eg: no data sent, or no data to send)

The bug was introduced in 1.5-dev23, no backport is needed.
2014-04-30 20:02:02 +02:00
Willy Tarreau
7c29f1edca BUILD: config: remove a warning with clang
Commit fc6c032 ("MEDIUM: global: add support for CPU binding on Linux ("cpu-map")")
merged into 1.5-dev13 involves a useless test that clang reports as a warning. The
"low" variable cannot be negative here. Issue reported by Charles Carter.
2014-04-29 19:55:25 +02:00
Willy Tarreau
86e0fc1739 BUG/MINOR: auth: fix wrong return type in pat_match_auth()
Commit 5338eea ("MEDIUM: pattern: The match function browse itself the
list or the tree") changed the return type of pattern matching functions.
One enum was left over in pat_match_auth(). Fortunately, this one equals
zero where a null pointer is expected, so it's cast correctly.

This detected and reported by Charles Carter was introduced in 1.5-dev23,
no backport is needed.
2014-04-29 19:52:16 +02:00
Willy Tarreau
ed44649eb7 MEDIUM: config: warn that '{cli,con,srv}timeout' are deprecated
It's been like this since version 1.3 in 2007. It's time to clean
up configurations. The warning explains what to use depending on
the timeout name.
2014-04-29 01:09:56 +02:00
Willy Tarreau
a3c504c032 MEDIUM: config: inform the user only once that "redispatch" is deprecated
It may go away in 1.6, but there's no point reporting it for each and
every occurrence.
2014-04-29 01:09:40 +02:00
Willy Tarreau
40bac83734 MEDIUM: config: inform the user that "reqsetbe" is deprecated
It will go away in 1.6.
2014-04-29 00:46:01 +02:00
Willy Tarreau
de9d2d7b86 MEDIUM: config: inform the user about the deprecatedness of "block" rules
It's just a warning emitted once.
2014-04-29 00:46:01 +02:00
Willy Tarreau
ff05550b5d MINOR: config: add minimum support for emitting warnings only once
This is useful to explain to users what to do during a migration.
2014-04-29 00:46:01 +02:00
Willy Tarreau
0b7483385e MEDIUM: http: make http-request rules processing return a verdict instead of a rule
Till now we used to return a pointer to a rule, but that makes it
complicated to later add support for registering new actions which
may fail. For example, the redirect may fail if the response is too
large to fit into the buffer.

So instead let's return a verdict. But we needed the pointer to the
last rule to get the address of a redirect and to get the realm used
by the auth page. So these pieces of code have moved into the function
and they produce a verdict.
2014-04-29 00:46:01 +02:00
Willy Tarreau
ae3c010226 MEDIUM: http: factorize the "auth" action of http-request and stats
Both use exactly the same mechanism, except for the choice of the
default realm to be emitted when none is selected. It can be achieved
by simply comparing the ruleset with the stats' for now. This achieves
a significant code reduction and further, removes the dependence on
the pointer to the final rule in the caller.
2014-04-29 00:46:01 +02:00
Willy Tarreau
f75e5c3d84 MINOR: http: remove the now unused loop over "block" rules
This ruleset is now always empty, simply remove it.
2014-04-28 22:15:00 +02:00
Willy Tarreau
b3dc39dfe1 MEDIUM: http: emulate "block" rules using "http-request" rules
The "block" rules are redundant with http-request rules because they
are performed immediately before and do exactly the same thing as
"http-request deny". Moreover, this duplication has led to a few
minor stats accounting issues fixed lately.

Instead of keeping the two rule sets, we now build a list of "block"
rules that we compile as "http-request block" and that we later insert
at the beginning of the "http-request" rules.

The only user-visible change is that in case of a parsing error, the
config parser will now report "http-request block rule" instead of
"blocking condition".
2014-04-28 22:06:57 +02:00
Willy Tarreau
353bc9f43f CLEANUP: proxy: rename "block_cond" to "block_rules"
Next patch will make them real rules, not only conditions. This separate
patch makes the next one more readable.
2014-04-28 22:05:31 +02:00
Willy Tarreau
5bd6759a19 MINOR: http: silently support the "block" action for http-request
This one will be used to convert "block" rules into "http-request block".
2014-04-28 22:00:46 +02:00
Willy Tarreau
5254259609 MEDIUM: http: remove even more of the spaghetti in the request path
Some of the remaining interleaving of request processing after the
http-request rules can now safely be removed, because all remaining
actions are mutually exclusive.

So we can move together all those related to an intercepting rule,
then proceed with stats, then with req*.

We still keep an issue with stats vs reqrep which forces us to
keep the stats split in two (detection and action). Indeed, from the
beginning, stats are detected before rewriting and not after. But a
reqdeny rule would stop stats, so in practice we have to first detect,
then perform the action. Maybe we'll be able to kill this in version
1.6.
2014-04-28 21:35:30 +02:00
Willy Tarreau
179085ccac MEDIUM: http: move Connection header processing earlier
Till now the Connection header was processed in the middle of the http-request
rules and some reqadd rules. It used to force some http-request actions to be
cut in two parts.

Now with keep-alive, not only that doesn't make any sense anymore, but it's
becoming a total mess, especially since we need to know the headers contents
before proceeding with most actions.

The real reason it was not moved earlier is that the "block" or "http-request"
rules can see a different version if some fields are changed there. But that
is already not reliable anymore since the values observed by the frontend
differ from those in the backend.

This patch is the equivalent of commit f118d9f ("REORG: http: move HTTP
Connection response header parsing earlier") but for the request side. It
has been tagged MEDIUM as it could theorically slightly affect some setups
relying on corner cases or invalid setups, though this does not make real
sense and is highly unlikely.
2014-04-28 21:35:29 +02:00
Willy Tarreau
65410831a1 BUG/MINOR: http: block rules forgot to increment the session's request counter
The session's backend request counters were incremented after the block
rules while these rules could increment the session's error counters,
meaning that we could have more errors than requests reported in a stick
table! Commit 5d5b5d8 ("MEDIUM: proto_tcp: add support for tracking L7
information") is the most responsible for this.

This bug is 1.5-specific and does not need any backport.
2014-04-28 21:34:43 +02:00
Willy Tarreau
5fa7082911 BUG/MINOR: http: block rules forgot to increment the denied_req counter
"block" rules used to build the whole response and forgot to increment
the denied_req counters. By jumping to the general "deny" label created
in previous patch, it's easier to fix this.

The issue was already present in 1.3 and remained unnoticed, in part
because few people use "block" nowadays.
2014-04-28 18:46:40 +02:00
Willy Tarreau
bbba2a8ecc MEDIUM: http: jump to dedicated labels after http-request processing
Continue the cleanup of http-request post-processing to remove some
of the interleaved tests. Here we set up a few labels to deal with
the deny and tarpit actions and avoid interleaved ifs.
2014-04-28 18:46:20 +02:00
Willy Tarreau
5e9edce0f0 MEDIUM: http: move reqadd after execution of http_request redirect
We still have a plate of spaghetti in the request processing rules.
All http-request rules are executed at once, then some responses are
built interlaced with other rules that used to be there in the past.
Here, reqadd is executed after an http-req redirect rule is *decided*,
but before it is *executed*.

So let's match the doc and config checks, to put the redirect actually
before the reqadd completely.
2014-04-28 17:25:40 +02:00
Willy Tarreau
cfe7fdd02d MINOR: http: rely on the message body parser to send 100-continue
There's no point in open-coding the sending of 100-continue in
the stats initialization code, better simply rely on the function
designed to process the message body which already does it.
2014-04-28 17:25:40 +02:00
Willy Tarreau
e6d24163e5 BUG/MINOR: http: log 407 in case of proxy auth
Commit 844a7e7 ("[MEDIUM] http: add support for proxy authentication")
merged in v1.4-rc1 added the ability to emit a status code 407 in auth
responses, but forgot to set the same status in the logs, which still
contain 401.

The bug is harmless, no backport is needed.
2014-04-28 17:24:42 +02:00
Willy Tarreau
f767ac55a2 BUG/MINOR: proxy: unsafe initialization of HTTP transaction when switching from TCP frontend
A switch from a TCP frontend to an HTTP backend initializes the HTTP
transaction. txn->hdr_idx.size is used by hdr_idx_init() but not
necessarily initialized yet here, because the first call to hdr_idx_init()
is in fact placed in http_init_txn(). Moving it before the call is
enough to fix it. We also remove the useless extra confusing call
to hdr_idx_init().

The bug was introduced in 1.5-dev8 with commit ac1932d ("MEDIUM:
tune.http.maxhdr makes it possible to configure the maximum number
of HTTP headers"). No backport to stable is needed.
2014-04-28 17:24:39 +02:00
Thierry FOURNIER
e47e4e2385 BUG/MEDIUM: patterns: last fix was still not enough
Last fix did address the issue for inlined patterns, but it was not
enough because the flags are lost as well when updating patterns
dynamically over the CLI.

Also if the same file was used once with -i and another time without
-i, their references would have been merged and both would have used
the same matching method.

It's appear that the patterns have two types of flags. The first
ones are relative to the pattern matching, and the second are
relative to the pattern storage. The pattern matching flags are
the same for all the patterns of one expression. Now they are
stored in the expression. The storage flags are information
returned by the pattern mathing function. This information is
relative to each entry and is stored in the "struct pattern".

Now, the expression matching flags are forwarded to the parse
and index functions. These flags are stored during the
configuration parsing, and they are used during the parse and
index actions.

This issue was introduced in dev23 with the major pattern rework,
and is a continuation of commit a631fc8 ("BUG/MAJOR: patterns: -i
and -n are ignored for inlined patterns"). No backport is needed.
2014-04-28 14:19:17 +02:00
Willy Tarreau
a631fc8de8 BUG/MAJOR: patterns: -i and -n are ignored for inlined patterns
These flags are only passed to pattern_read_from_file() which
loads the patterns from a file. The functions used to parse the
patterns from the current line do not provide the means to pass
the pattern flags so they're lost.

This issue was introduced in dev23 with the major pattern rework,
and was reported by Graham Morley. No backport is needed.
2014-04-27 09:21:08 +02:00
Willy Tarreau
3b78696858 BUG/MEDIUM: pattern: a typo breaks automatic acl/map numbering
Dmitry Sivachenko reported that nice warning :
src/pattern.c:2243:43: warning: if statement has empty body [-Wempty-body]
                                if (&ref2->list == &pattern_reference);
                                                                      ^
src/pattern.c:2243:43: note: put the semicolon on a separate line to silence
      this warning

It was merged as is with the code from commit af5a29d ("MINOR: pattern:
Each pattern is identified by unique id").

So it looks like we can reassign an ID which is still in use because of
this.
2014-04-26 12:41:32 +02:00
Willy Tarreau
8860dcd70a [RELEASE] Released version 1.5-dev24
Released version 1.5-dev24 with the following main changes :
    - MINOR: pattern: find element in a reference
    - MEDIUM: http: ACL and MAP updates through http-(request|response) rules
    - MEDIUM: ssl: explicitly log failed handshakes after a heartbeat
    - DOC: Full section dedicated to the converters
    - MEDIUM: http: register http-request and http-response keywords
    - BUG/MINOR: compression: correctly report incoming byte count
    - BUG/MINOR: http: don't report server aborts as client aborts
    - BUG/MEDIUM: channel: bi_putblk() must not wrap before the end of buffer
    - CLEANUP: buffers: remove unused function buffer_contig_space_with_res()
    - MEDIUM: stats: reimplement HTTP keep-alive on the stats page
    - BUG/MAJOR: http: fix timeouts during data forwarding
    - BUG/MEDIUM: http: 100-continue responses must process the next part immediately
    - MEDIUM: http: move skipping of 100-continue earlier
    - BUILD: stats: let gcc know that last_fwd cannot be used uninitialized...
    - CLEANUP: general: get rid of all old occurrences of "session *t"
    - CLEANUP: http: remove the useless "if (1)" inherited from version 1.4
    - BUG/MEDIUM: stats: mismatch between behaviour and doc about front/back
    - MEDIUM: http: enable analysers to have keep-alive on stats
    - REORG: http: move HTTP Connection response header parsing earlier
    - MINOR: stats: always emit HTTP/1.1 in responses
    - MINOR: http: add capture.req.ver and capture.res.ver
    - MINOR: checks: add a new global max-spread-checks directive
    - BUG/MAJOR: http: fix the 'next' pointer when performing a redirect
    - MINOR: http: implement the max-keep-alive-queue setting
    - DOC: fix alphabetic order of tcp-check
    - MINOR: connection: add a new error code for SSL with heartbeat
    - MEDIUM: ssl: implement a workaround for the OpenSSL heartbleed attack
    - BUG/MEDIUM: Revert "MEDIUM: ssl: Add standardized DH parameters >= 1024 bits"
    - BUILD: http: remove a warning on strndup
    - BUILD: ssl: avoid a warning about conn not used with OpenSSL < 1.0.1
    - BUG/MINOR: ssl: really block OpenSSL's response to heartbleed attack
    - MINOR: ssl: finally catch the heartbeats missing the padding
2014-04-26 00:08:14 +02:00
Willy Tarreau
aeed672a6d MINOR: ssl: finally catch the heartbeats missing the padding
Previous patch only focused on parsing the packet right and blocking
it, so it relaxed one test on the packet length. The difference is
not usable for attacking but the logs will not report an attack for
such cases, which is probably bad. Better report all known invalid
packets cases.
2014-04-26 00:03:48 +02:00
Willy Tarreau
3b2fdb6f55 BUG/MINOR: ssl: really block OpenSSL's response to heartbleed attack
Recent commit f51c698 ("MEDIUM: ssl: implement a workaround for the
OpenSSL heartbleed attack") did not always work well, because OpenSSL
is fun enough for not testing errors before sending data... So the
output sometimes contained some data.

The OpenSSL code relies on the max_send_segment value to limit the
packet length. The code ensures that a value of zero will result in
no single byte leaking. So we're forcing this instead and that
definitely fixes the issue. Note that we need to set it the hard
way since the regular API checks for valid values.
2014-04-25 23:48:21 +02:00
Willy Tarreau
84815006a0 BUILD: ssl: avoid a warning about conn not used with OpenSSL < 1.0.1
Building with a version of openssl without heartbeat gives this since
latest 29f037d ("MEDIUM: ssl: explicitly log failed handshakes after a
heartbeat") :

src/ssl_sock.c: In function 'ssl_sock_msgcbk':
src/ssl_sock.c:188: warning: unused variable 'conn'

Simply declare conn inside the ifdef. No backport is needed.
2014-04-25 21:40:27 +02:00
Willy Tarreau
6c09c2ceae BUILD: http: remove a warning on strndup
The latest commit about set-map/add-acl/... causes this warning for
me :

src/proto_http.c: In function 'parse_http_req_cond':
src/proto_http.c:8863: warning: implicit declaration of function 'strndup'
src/proto_http.c:8863: warning: incompatible implicit declaration of built-in function 'strndup'
src/proto_http.c:8890: warning: incompatible implicit declaration of built-in function 'strndup'
src/proto_http.c:8917: warning: incompatible implicit declaration of built-in function 'strndup'
src/proto_http.c:8944: warning: incompatible implicit declaration of built-in function 'strndup'

Use my_strndup() instead of strndup() which is not portable. No backport
needed.
2014-04-25 21:39:17 +02:00
Willy Tarreau
6e774b455f BUG/MEDIUM: Revert "MEDIUM: ssl: Add standardized DH parameters >= 1024 bits"
This reverts commit 9ece05f590.

Sander Klein reported an important performance regression with this
patch applied. It is not yet certain what is exactly the cause but
let's not break other setups now and sort this out after dev24.

The commit was merged into dev23, no need to backport.
2014-04-25 21:35:23 +02:00
Willy Tarreau
f51c6989b0 MEDIUM: ssl: implement a workaround for the OpenSSL heartbleed attack
Using the previous callback, it's trivial to block the heartbeat attack,
first we control the message length, then we emit an SSL error if it is
out of bounds. A special log is emitted, indicating that a heartbleed
attack was stopped so that they are not confused with other failures.

That way, haproxy can protect itself even when running on an unpatched
SSL stack. Tests performed with openssl-1.0.1c indicate a total success.
2014-04-25 20:06:33 +02:00
Emeric Brun
29f037d872 MEDIUM: ssl: explicitly log failed handshakes after a heartbeat
Add a callback to receive the heartbeat notification. There, we add
SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen.

If a handshake fails, we log a different message to mention the fact that
a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 19:25:33 +02:00
Willy Tarreau
b3966377d8 MINOR: connection: add a new error code for SSL with heartbeat
Users have seen a huge increase in the rate of SSL handshake failures
starting from 2014/04/08 with the release of the Heartbleed OpenSSL
vulnerability (CVE-2014-0160). Haproxy can detect that a heartbeat
was received in the incoming handshake, and such heartbeats are not
supposed to be common, so let's log a different message when a
handshake error happens after a heartbeat is detected.

This patch only adds the new message and the new code.
2014-04-25 18:56:57 +02:00
William Lallemand
73025dd7e2 MEDIUM: http: register http-request and http-response keywords
The http_(res|req)_keywords_register() functions allow to register
new keywords.

You need to declare a keyword list:

struct http_req_action_kw_list test_kws = {
	.scope = "testscope",
	.kw = {
		{ "test", parse_test },
		{ NULL, NULL },
	}
};

and a parsing function:

int parse_test(const char **args, int *cur_arg, struct proxy *px, struct http_req_rule *rule, char **err)
{
	rule->action = HTTP_REQ_ACT_CUSTOM_STOP;
	rule->action_ptr = action_function;

	return 0;
}

http_req_keywords_register(&test_kws);

The HTTP_REQ_ACT_CUSTOM_STOP action stops evaluation of rules after
your rule, HTTP_REQ_ACT_CUSTOM_CONT permits the evaluation of rules
after your rule.
2014-04-25 18:48:35 +02:00
Baptiste Assmann
fabcbe0de6 MEDIUM: http: ACL and MAP updates through http-(request|response) rules
This patch allows manipulation of ACL and MAP content thanks to any
information available in a session: source IP address, HTTP request or
response header, etc...

It's an update "on the fly" of the content  of the map/acls. This means
it does not resist to reload or restart of HAProxy.
2014-04-25 18:48:35 +02:00
Baptiste Assmann
953f74d1b3 MINOR: pattern: find element in a reference
This function can be used to look for an entry in either an ACL or a
MAP.
2014-04-25 17:31:13 +02:00
Willy Tarreau
938c7fec87 DOC: fix alphabetic order of tcp-check 2014-04-25 14:21:39 +02:00
Willy Tarreau
c35362a94a MINOR: http: implement the max-keep-alive-queue setting
Finn Arne Gangstad suggested that we should have the ability to break
keep-alive when the target server has reached its maxconn and that a
number of connections are present in the queue. After some discussion
around his proposed patch, the following solution was suggested : have
a per-proxy setting to fix a limit to the number of queued connections
on a server after which we break keep-alive. This ensures that even in
high latency networks where keep-alive is beneficial, we try to find a
different server.

This patch is partially based on his original proposal and implements
this configurable threshold.
2014-04-25 14:14:41 +02:00
Willy Tarreau
6d8bac7ddc BUG/MAJOR: http: fix the 'next' pointer when performing a redirect
Commit bed410e ("MAJOR: http: centralize data forwarding in the request path")
has woken up an issue in redirects, where msg->next is not reset when flushing
the input buffer. The result is an attempt to forward a negative amount of
data, making haproxy crash.

This bug does not seem to affect versions prior to dev23, so no backport is
needed.
2014-04-25 12:21:09 +02:00
Willy Tarreau
1746eecc52 MINOR: checks: add a new global max-spread-checks directive
This directive ensures that checks with a huge interval do not start
too far apart at the beginning.
2014-04-25 10:52:25 +02:00