MEDIUM: http: add a new option http-buffer-request

It is sometimes desirable to wait for the body of an HTTP request before
taking a decision. This is what is being done by "balance url_param" for
example. The first use case is to buffer requests from slow clients before
connecting to the server. Another use case consists in taking the routing
decision based on the request body's contents. This option placed in a
frontend or backend forces the HTTP processing to wait until either the whole
body is received, or the request buffer is full, or the first chunk is
complete in case of chunked encoding. It can have undesired side effects with
some applications abusing HTTP by expecting unbufferred transmissions between
the frontend and the backend, so this should definitely not be used by
default.

Note that it would not work for the response because we don't reset the
message state before starting to forward. For the response we need to
1) reset the message state to MSG_100_SENT or BODY , and 2) to reset
body_len in case of chunked encoding to avoid counting it twice.

MEDIUM: stream: move HTTP request body analyser before process_common

Since 1.5, the request body analyser has become independant from any
other element and does not even disturb the message forwarder anymore.
And since it's disabled by default, we can place it before most
analysers so that it's can preempt any other one if an intermediary
one enables it.

BUG/MAJOR: http: prevent risk of reading past end with balance url_param

The get_server_ph_post() function assumes that the buffer is contiguous.
While this is true for all the header part, it is not necessarily true
for the end of data the fit in the reserve. In this case there's a risk
to read past the end of the buffer for a few hundred bytes, and possibly
to crash the process if what follows is not mapped.

The fix consists in truncating the analyzed length to the length of the
contiguous block that follows the headers.

A config workaround for this bug would be to disable balance url_param.

This fix must be backported to 1.5. It seems 1.4 did have the check.

BUG/MEDIUM: http: wait for the exact amount of body bytes in wait_for_request_body

Due to the fact that we were still considering only msg->sov for the
first byte of data after calling http_parse_chunk_size(), we used to
miscompute the input data size and to count the CRLF and the chunk size
as part of the input data. The effect is that it was possible to release
the processing with 3 or 4 missing bytes, especially if they're typed by
hand during debugging sessions. This can cause the stats page to return
some errors in admin mode, and the url_param balance algorithm to fail
to properly hash a body input.

This fix must be backported to 1.5.

DOC: fix the comments about the meaning of msg->sol in HTTP

It has a meaning while parsing a body when using chunked encoding.
This must be backported to 1.5 since it caused a bug there as well.

DOC: document option http-ignore-probes

This one was forgotten.

DOC: relax the peers restriction to single-process

MAJOR: peers: allow peers section to be used with nbproc > 1

This only works when the peers are bound to exactly one process.

MEDIUM: config: validate that peers sections are bound to exactly one process

If a peers section is bound to no process, it's silently discarded. If its
bound to multiple processes, an error is emitted and the process will not
start.

MEDIUM: init: stop any peers section not bound to the correct process

This will prevent the peers section from remaining in listen state on
the incorrect process. The peers_fe pointer is set to NULL, which will
tell the peers task to commit suicide if it was already scheduled.

MEDIUM: config: propagate the table's process list to the peers sections

Now a peers section has its bind_proc set to the union of all those of
its users.

MEDIUM: peers: unregister peers that were never started

The peers initialization sequence is a bit complex, they're attached
to stick-tables and initialized very early in the boot process. When
we fork, if some must not start, it's too late to find them. Instead,
simply add a guard in their respective tasks to stop them once they
want to start.

MINOR: peers: store the pointer to the signal handler

We'll need it to unregister stopped peers sections.

MEDIUM: peers: add the ability to disable a peers section

Sometimes it's very hard to disable the use of peers because an empty
section is not valid, so it is necessary to comment out all references
to the section, and not to forget to restore them in the same state
after the operation.

Let's add a "disabled" keyword just like for proxies. A ->state member
in the peers struct is even present for this purpose but was never used
at all.

Maybe it would make sense to backport this to 1.5 as it's really cumbersome
there.

MEDIUM: config: initialize stick-tables after peers, not before

It's dangerous to initialize stick-tables before peers because they
start a task that cannot be stopped before we know if the peers need
to be disabled and destroyed. Move this after.

MINOR: stick-table: don't attach to peers in stopped state

This will be used to disable peers sections.

MEDIUM: init: don't stop proxies in parent process when exiting

That's pointless, and that's confusing when debugging.

BUG/MINOR: config: clear proxy->table.peers.p for disabled proxies

If a table in a disabled proxy references a peers section, the peers
name is not resolved to a pointer to a table, but since it belongs to
a union, it can later be dereferenced. Right now it seems it cannot
happen, but it definitely will after the pending changes.

It doesn't cost anything to backport this into 1.5, it will make gdb
sessions less head-scratching.

MEDIUM: http: add option-ignore-probes to get rid of the floods of 408

Recently some browsers started to implement a "pre-connect" feature
consisting in speculatively connecting to some recently visited web sites
just in case the user would like to visit them. This results in many
connections being established to web sites, which end up in 408 Request
Timeout if the timeout strikes first, or 400 Bad Request when the browser
decides to close them first. These ones pollute the log and feed the error
counters. There was already "option dontlognull" but it's insufficient in
this case. Instead, this option does the following things :
   - prevent any 400/408 message from being sent to the client if nothing
     was received over a connection before it was closed ;
   - prevent any log from being emitted in this situation ;
   - prevent any error counter from being incremented

That way the empty connection is silently ignored. Note that it is better
not to use this unless it is clear that it is needed, because it will hide
real problems. The most common reason for not receiving a request and seeing
a 408 is due to an MTU inconsistency between the client and an intermediary
element such as a VPN, which blocks too large packets. These issues are
generally seen with POST requests as well as GET with large cookies. The logs
are often the only way to detect them.

This patch should be backported to 1.5 since it avoids false alerts and
makes it easier to monitor haproxy's status.

MEDIUM: http: disable support for HTTP/0.9 by default

There's not much reason for continuing to accept HTTP/0.9 requests
nowadays except for manual testing. Now we disable support for these
by default, unless option accept-invalid-http-request is specified,
in which case they continue to be upgraded to 1.0.

MEDIUM: http: restrict the HTTP version token to 1 digit as per RFC7230

While RFC2616 used to allow an undeterminate amount of digits for the
major and minor components of the HTTP version, RFC7230 has reduced
that to a single digit for each.

If a server can't properly parse the version string and falls back to 0.9,
it could then send a head-less response whose payload would be taken for
headers, which could confuse downstream agents.

Since there's no more reason for supporting a version scheme that was
never used, let's upgrade to the updated version of the standard. It is
still possible to enforce support for the old behaviour using options
accept-invalid-http-request and accept-invalid-http-response.

It would be wise to backport this to 1.5 as well just in case.

BUG/MEDIUM: http: remove content-length form responses with bad transfer-encoding

The spec mandates that content-length must be removed from messages if
Transfer-Encoding is present, not just for valid ones.

This must be backported to 1.5 and 1.4.

BUG/MEDIUM: http: incorrect transfer-coding in the request is a bad request

The rules related to how to handle a bad transfer-encoding header (one
where "chunked" is not at the final place) have evolved to mandate an
abort when this happens in the request. Previously it was only a close
(which is still valid for the server side).

This must be backported to 1.5 and 1.4.

BUG/MEDIUM: http: do not restrict parsing of transfer-encoding to HTTP/1.1

While Transfer-Encoding is HTTP/1.1, we must still parse it in HTTP/1.0
in case an agent sends it, because it's likely that the other side might
use it as well, causing confusion. This will also result in getting rid
of the Content-Length header in such abnormal situations and in having
a clean connection.

This must be backported to 1.5 and 1.4.

DOC: http: update the comments about the rules for determining transfer-length

Let's now use the text from RFC7230 which is stricter and more precise.

This must be backported to 1.5 and 1.4.

BUG/MEDIUM: http: remove content-length from chunked messages

RFC7230 clarified the behaviour to adopt when facing both a
content-length and a transfer-encoding: chunked in a message. While
haproxy already complied with the method for getting the message
length right, and used to detect improper content-length duplicates,
it still did not remove the content-length header when facing a
transfer-encoding: chunked. Usually it is not a problem since other
agents (clients and servers) are required to parse the message
according to the rules that have been in place since RFC2616 in
1999.

However Régis Leroy reported the existence of at least one such
non-compliant agent so haproxy could be abused to get out of sync
with it on pipelined requests (HTTP request smuggling attack),
it consider part of a payload as a subsequent request.

The best thing to do is then to remove the content-length according
to RFC7230. It used to be in the todo list with a fixme in the code
while waiting for the standard to stabilize, let's apply it now that
it's published.

Thanks to Régis for bringing that subject to our attention.

This fix must be backported to 1.5 and 1.4.

MEDIUM: Document when email-alerts are sent

Document the influence of email-alert level and other configuration
parameters on when email-alerts are sent.

Signed-off-by: Simon Horman <horms@verge.net.au>

MEDIUM: Send email alerts when servers are marked as UP or enter the drain state

This is similar to the way email alerts are sent when servers are marked as
DOWN.

Like the log messages corresponding to these state changes the messages
have log level notice. Thus they are suppressed by the default email-alert
level of 'alert'. To allow these messages the email-alert level should
be set to 'notice', 'info' or 'debug'. e.g:

email-alert level notice

"email-alert mailers" and "email-alert to" settings are also required in
order for any email alerts to be sent.

A follow-up patch will document the above.

Signed-off-by: Simon Horman <horms@verge.net.au>

MEDIUM: Lower priority of email alerts for log-health-checks messages

Lower the priority of email alerts for log-health-checks messages from
LOG_NOTICE to LOG_INFO.

This is to allow set-ups with log-health-checks enabled to disable email
for health check state changes while leaving other email alerts enabled.

In order for email alerts to be sent for health check state changes
"log-health-checks" needs to be set and "email-alert level" needs to be 'info'
or lower. "email-alert mailers" and "email-alert to" settings are also
required in order for any email alerts to be sent.

A follow-up patch will document the above.

Signed-off-by: Simon Horman <horms@verge.net.au>

MAJOR: pattern: add LRU-based cache on pattern matching

The principle of this cache is to have a global cache for all pattern
matching operations which rely on lists (reg, sub, dir, dom, ...). The
input data, the expression and a random seed are used as a hashing key.
The cached entries contains a pointer to the expression and a revision
number for that expression so that we don't accidently used obsolete
data after a pattern update or a very unlikely hash collision.

Regarding the risk of collisions, 10k entries at 10k req/s mean 1% risk
of a collision after 60 years, that's already much less than the memory's
reliability in most machines and more durable than most admin's life
expectancy. A collision will result in a valid result to be returned
for a different entry from the same list. If this is not acceptable,
the cache can be disabled using tune.pattern.cache-size.

A test on a file containing 10k small regex showed that the regex
matching was limited to 6k/s instead of 70k with regular strings.
When enabling the LRU cache, the performance was back to 70k/s.

MEDIUM: pattern: add a revision to all pattern expressions

This will be used to detect any change on the pattern list between
two operations, ultimately making it possible to implement a cache
which immediately invalidates obsolete keys after an update. The
revision is simply taken from the timestamp counter to ensure that
even upon a pointer reuse we cannot accidently come back to the
same (expr,revision) tuple.

IMPORT: hash: import xxhash-r39

The xxhash library provides a very fast and excellent hash algorithm
suitable for many purposes. It excels at hashing large blocks but is
also extremely fast on small ones. It's distributed under a 2-clause
BSD license (GPL-compatible) so it can be included here. Updates are
distributed here :

      https://github.com/Cyan4973/xxHash

IMPORT: lru: import simple ebtree-based LRU functions

This will be usable to implement some maps/acl caches for heavy datasets
loaded from files (mostly regex-based but in general anything that cannot
be indexed in a tree).

MINOR: tools: provide an rdtsc() function for time comparisons

This one returns a timestamp, either the one from the CPU or from
gettimeofday() in 64-bit format. The purpose is to be able to compare
timestamps on various entities to make it easier to detect updates.
It can also be used for benchmarking in certain situations during
development.

BUG/MEDIUM: check: tcpcheck regression introduced by e16c1b3f

The commit e16c1b3f changed the way the function tcpcheck_get_step_id is
now called (check instead of server).
This change introduced a regression since now this function would return
0 all the time because of:
 if (check->current_step)
   return 0;

This patch fixes this issue by inversing the test: you want to return 0
only if current_step is not yet set :)

No backport is needed.

MEDIUM: logs: Add HTTP request-line log format directives

This commit adds 4 new log format variables that parse the
HTTP Request-Line for more specific logging than "%r" provides.

For example, we can parse the following HTTP Request-Line with
these new variables:

  "GET /foo?bar=baz HTTP/1.1"

- %HM: HTTP Method ("GET")
- %HV: HTTP Version ("HTTP/1.1")
- %HU: HTTP Request-URI ("/foo?bar=baz")
- %HP: HTTP Request-URI without query string ("/foo")

BUG/MEDIUM: peers: recent applet changes broke peers updates scheduling

Since appctx are scheduled out of streams, it's pointless to wake up
the task managing the stream to push updates, they won't be seen. In
fact unit tests work because silent sessions are restarted after 5s of
idle and the exchange is correctly scheduled during startup!

So we need to notify the appctx instead. For this we add a pointer to
the appctx in the peer session.

No backport is needed of course.

BUG/MEDIUM: peers: fix applet scheduling

Consecutive to the recent changes brought to applets, peers properly
connect but do not exchange data anymore because the stream interface
is not marked as waiting for data.

No backport is needed.

BUG/MEDIUM: http: functions set-{path,query,method,uri} breaks the HTTP parser

When one of these functions replaces a part of the query string by
a shorter or longer new one, the header parsing is broken. This is
because the start of the first header is not updated.

In the same way, the total length of the request line is not updated.
I dont see any bug caused by this miss, but I guess than it is better
to store the good length.

This bug is only in the development version.

BUG/MAJOR: tcp: only call registered actions when they're registered

Commit cc87a11 ("MEDIUM: tcp: add register keyword system.") introduced
the registration of new keywords for TCP rulesets. Unfortunately it
replaced the "accept" action with an unconditionnal call to the rule's
action function, resulting in an immediate segfault when using the
"accept" action in a TCP ruleset.

This bug reported by Baptiste Assmann was introduced in 1.6-dev1, no
backport is needed.

MEDIUM: stream-int: pause the appctx if the task is woken up

If we're going to call the task we don't need to call the appctx anymore
since the task may decide differently in the end and will do the proper
thing using ->update(). This reduces one wake up call per session and
may go down to half in case of high concurrency (scheduling races).

MEDIUM: applet: make the applets only use si_applet_{cant|want|stop}_{get|put}

The applets don't fiddle with SI_FL_WAIT_ROOM anymore, instead they indicate
what they want, possibly that they failed (eg: WAIT_ROOM), and it's done() /
update() which finally updates the WAIT_* flags according to the channels'
and stream interface's states. This solves the issue of the pauses during a
"show sess" without creating busy loops.

MINOR: stream-int: add two flags to indicate an applet's wishes regarding I/O

Currently we have a problem. There are some cases where a sleeping applet
is not woken up (eg: show sess during an injection). The reason is that
the applet is marked WAIT_DATA and is not woken up when WAIT_ROOM leaves,
because we wait for both flags to be cleared in order to call it.

And if we wait for either flag, then we have the opposite situation, which
is that we're not waiting for room in the output buffer so we're spinning
calling the applet to do nothing.

What is missing is an indication of what the applet needs. Since it only
manipulates the WAIT_ROOM/WAIT_DATA which are overwritten later, that cannot
work. In the case of connections, the problem doesn't happen because the
connection maintains these extra states. Ideally we'd need to have similar
states for each appctx and to store those information there. But it would
be overcomplicated given that an applet doesn't exist alone without a
stream-int, so we can safely put these information into the stream int and
make the code simpler.

With this patch we introduce two new flags in the stream interface :
  - SI_FL_WANT_PUT : the applet wants to put something into the buffer
  - SI_FL_WANT_GET : the applet wants to get something from the buffer

We also have the new functions si_applet_{stop|want|cant}_{get|put}
to make the code look similar to the connection code.

For now these flags are not used yet.

MAJOR: stream: do not allocate request buffers anymore when the left side is an applet

We used to allocate a request buffer so that we could process applets
from process_stream(), and this was causing some trouble because it was
not possible for an analyzer to return an error to an applet, which
we'll need for HTTP/2. Now that we don't call applets anymore from
process_stream() we can simplify this and ensure that a response is
always allocated to process a stream.

MEDIUM: applet: centralize the call to si_applet_done() in the I/O handler

It's much easier to centralize this call into the I/O handler than to
do it everywhere with the risk to miss it. Applets are not allowed to
unregister themselves anyway so their SI is still present and it is
possible to update all the context.

MEDIUM: dumpstats: don't unregister the applet anymore

Let the session do the job, the applet I/O handler doesn't have to unregister
itself.

MAJOR: stream: use a regular ->update for all stream interfaces

Now si->update() is used to update any type of stream interface, whether
it's an applet, a connection or even nothing. We don't call si_applet_call()
anymore at the end of the resync and we don't have the risk that the
stream's task is reinserted into the run queue, which makes the code
a bit simpler.

The stream_int_update_applet() function was simplified to ensure that
it remained compatible with this standardized calling convention. It
was almost copy-pasted from the update code dedicated to connections.
Just like for si_applet_done(), it seems that it should be possible to
merge the two functions except that it would require some slow operations,
except maybe if the type of end point is tested inside the update function
itself.

MAJOR: applet: now call si_applet_done() instead of si_update() in I/O handlers

The applet I/O handlers now rely on si_applet_done() which itself decides
to wake up or sleep the appctx. Now it becomes critical that applte handlers
properly call this on every exit path so that the appctx is removed from the
active list after I/O have been handled. One such call was added to the Lua
socket handler. It used to work without it probably because the main task is
woken up by the parent task but now it's needed.

MEDIUM: stream-int: add a new function si_applet_done()

This is the equivalent of si_conn_wake() but for applets. It will be
called after changes to the stream interface are brought by the applet
I/O handler. Ultimately it will release buffers and may be even wake
the stream's task up if some important changes are detected.

It would be nice to be able to merge it with the connection's wake
function since it mostly manipulates the stream interface, but there
are minor differences (such as how to enable/disable polling on a fd
vs applet) and some specificities to applets (eg: don't wake the
applet up until the output is empty) which would require abstract
functions which would slow down everything.

MEDIUM: applet: implement a run queue for active appctx

The new function is called for each round of polling in order to call any
active appctx. For now we pick the stream interface from the appctx's
owner. At the moment there's no appctx queued yet, but we have everything
needed to queue them and remove them.

MEDIUM: applet: add basic support for an applet run queue

This will be needed so that we can schedule applets out of the streams.
For now nothing calls the queue yet.

REORG: stream-int: create si_applet_ops dedicated to applets

These functions are dedicated to applets so that we don't use the default
ones anymore in this case.

CLEANUP: applet: rename struct si_applet to applet

Since this one does not depend on stream_interface anymore, remove the
"si_" prefix.

REORG: applet: move the applet definitions out of stream_interface

We're tidying the definitions so that appctx lives on its own. A new
set of applet.h files has been added for this purpose.

MEDIUM: applet: make the applet not depend on a stream interface anymore

Now that applet's functions only take an appctx in argument, not a
stream interface. This slightly simplifies the code and will be needed
to take the appctx out of the stream interface.

MINOR: applet: add a new "owner" pointer in the appctx

This pointer indicates what stream-interface the appctx belongs to, just
like we have for the connections.

MEDIUM: stats: Differentiate between DRAIN and DRAIN (agent)

Differentiate between DRAIN and DRAIN (agent) when reporting stats.
This is consistent with the distinction made between DOWN and DOWN (agent).

Signed-off-by: Simon Horman <horms@verge.net.au>

MEDIUM: stats: Only report drain state in stats if server has SRV_ADMF_DRAIN set

There are some similarities between a weight of zero and the
administratively set drain state: both allow existing connections
to continue while not accepting any new ones.

However, when reporting a server state generally a distinction is made
between state=UP,weight=0 and state=DRAIN,weight=*. This patch makes
stats reporting consistent in this regard.

This patch does not alter the behaviour that if a server's weight
is zero then its stats row is blue when accessed via HTML. This remains
the case regardless of if the state is UP or DRAIN.

Signed-off-by: Simon Horman <horms@verge.net.au>

MEDIUM: stats: Separate server state and colour in stats

There is a relationship between the state and colour of a server in
stats, however, it is not a one-to-one relationship and the current
implementation has proved fragile.

This patch attempts to address that problem by clearly separating
state and colour.

A follow-up patch will further distinguish between DRAIN states
and DRAINING colours.

Signed-off-by: Simon Horman <horms@verge.net.au>

MEDIUM: stats: Add enum srv_stats_state

Add an enumeration to make the handling of the states of servers
in status messages somewhat clearer.

This is the first of a two-step attempt to disentangle the state and
colour of status information. A subsequent patch will separate state
colours from the states themselves.

This patch should not make any functional changes.

Signed-off-by: Simon Horman <horms@verge.net.au>

DOC: Fix L4TOUT typo in documentation

Fix documentation typo. L4TMOUT->L4TOUT.

BUG/MEDIUM: http: properly retrieve the front connection

Commit 350f487 ("CLEANUP: session: simplify references to chn_{prod,cons}(&s->{req,res})")
introduced a regression causing the cli_conn to be picked from the server
side instead of the client side, so the XFF header is not appended anymore
since the connection is NULL.

Thanks to Reinis Rozitis for reporting this bug. No backport is needed
as it's 1.6-specific.

DOC: update the entities diagrams

The recent changes were significant enough to warrant an update to the
entities diagram. It tries to be accurate, though it doesn't represent
applets.

BUG/MEDIUM: stream-int: always reset si->ops when si->end is nullified

It happened after changing the stream interface deinitialization
sequence that we got random crashes with si_shutw() being called
on NULL si->end. The reason was that si->ops was not reset after
a call to si_release_endpoint() which is sometimes called directly.

Thus we now move the resetting of si->ops just after any si->end
assignment. It happens that si_detach() is now just the same as
si_release_endpoint() and stream_int_unregister_handler(). Some
cleanup will have to be performed there.

It's not sure whether this problem can impact 1.5 since in 1.5
applets are part of the default embedded stream handler. The only
way it could cause some trouble is if it's used with a connection,
which doesn't seem possible at first glance.

BUG/MAJOR: tcp/http: fix current_rule assignment when restarting over a ruleset

Commit bc4c1ac ("MEDIUM: http/tcp: permit to resume http and tcp custom
actions") introduced the ability to interrupt and restart processing in
the middle of a TCP/HTTP ruleset. But it doesn't do it in a consistent
way : it checks current_rule_list, immediately dereferences current_rule,
which is only set in certain cases and never cleared. So that broke the
tcp-request content rules when the processing was interrupted due to
missing data, because current_rule was not yet set (segfault) or could
have been inherited from another ruleset if it was used in a backend
(random behaviour).

The proper way to do it is to always set current_rule before dereferencing
it. But we don't want to set it for all rules because we don't want any
action to provide a checkpointing mechanism. So current_rule is set to NULL
before entering the loop, and only used if not NULL and if current_rule_list
matches the current list. This way they both serve as a guard for the other
one. This fix also makes the current rule point to the rule instead of its
list element, as it's much easier to manipulate.

No backport is needed, this is 1.6-specific.

BUG/MEDIUM: init: don't limit cpu-map to the first 32 processes only

We have to allow 32 or 64 processes depending on the machine's word
size, and on 64-bit machines only the first 32 processes were properly
bound.

This fix should be backported to 1.5.

BUG/MEDIUM: listener: don't report an error when resuming unbound listeners

Pavlos Parissis reported that a sequence of disable/enable on a frontend
performed on the CLI can result in an error if the frontend has several
"bind" lines each bound to different processes. This is because the
resume_listener() function returns a failure for frontends not part of
the current process instead of returning a success to pretend there was
no failure.

This fix should be backported to 1.5.

CLEANUP: poll: move the conditions for waiting out of the poll functions

The poll() functions have become a bit dirty because they now check the
size of the signal queue, the FD cache and the number of tasks. It's not
their job, this must be moved to the caller. In the end it simplifies the
code because the expiration date is now set to now_ms if we must not wait,
and this achieves in exactly the same result and is cleaner. The change
looks large due to the change of indent for blocks which were inside an
"if" block.

MEDIUM: http: configurable http result codes for http-request deny

This patch adds support for error codes 429 and 405 to Haproxy and a
"deny_status XXX" option to "http-request deny" where you can specify which
code is returned with 403 being the default. We really want to do this the
"haproxy way" and hope to have this patch included in the mainline. We'll
be happy address any feedback on how this is implemented.

BUG/MINOR: ssl: Display correct filename in error message

This patch should be backported to 1.5.

MINOR: stream: pass the pointer to the origin explicitly to stream_new()

We don't pass sess->origin anymore but the pointer to the previous step. Now
it should be much easier to chain elements together once applets are moved out
of streams. Indeed, the session is only used for configuration and not for the
dynamic chaining anymore.

MEDIUM: session: adjust the connection flags before stream_new()

It's not the stream's job to manipulate the connection's flags, it's
more related to the session that accepted the new connection. And the
only case where we have to do it conditionally is based on the frontend
which is known from the session, thus it makes sense to do it there.

MINOR: session: maintain the session count stats in the session, not the stream

This has nothing to do in the stream, as we'll face absurdities when chaining
multiple streams. The session is where it must be accounted for.

CLEANUP: namespaces: fix protection against multiple inclusions

The include file did not protect correctly against multiple inclusions,
as it didn't define the file name after checking for it. That's currently
harmless as the file is only included from .c but that could change.

MINOR: lua: map system integration in Lua

This patch cretes a new Map class that permits to do some lookup in
HAProxy maps. This Map class is integration in the HAProxy update
system, so we can modify the map throught the socket.

MINOR: lua: (req|res)_get_headers return more than one header value

the functions (req|res)_get_headers() return only the last entry
for each header with the same name. This patch fix this behavior.
Each header name contain an array of values.

DOC: lua: some fixes

 - remove trailing spces
 - update fetches ans converters documentation

CLEANUP: stream-int: swap stream-int and appctx declarations

This is just in order to remove two forward declarations of si_applet
and stream_interface that are not needed once properly ordered.

MINOR: peers: no need for setting timeouts / conn_retries in peer_session_create()

For the client side this is done already by stream_new(). For the
server side it will be done when establishing the connection.

MINOR: lua: no need for setting timeouts / conn_retries in hlua_socket_new()

For the client side this is done already by stream_new(). For the
server side it will be done when establishing the connection.

MINOR: lua: minor cleanup in hlua_socket_new()

Just limit the number of dereferences of socket-> since we allocate
the stream at the beginning.

MEDIUM: lua: make use of stream_new() to create an outgoing connection

This significantly simplifies the session management because we don't
have to know all the intimate tricks of setting up a stream and a
session.

MEDIUM: stream: don't rely on the session's listener anymore in stream_new()

When the stream is instanciated from an applet, it doesn't necessarily
have a listener. The listener was sparsely used there, just to retrieve
the task function, update the listeners' stats, and set the analysers
and default target, both of which are often zero from applets. Thus
these elements are now initialized with default values that the caller
is free to change if desired.

CLEANUP: frontend: remove one useless local variable

"p" was a copy of sess->fe which itself is also used. It's used in a
few cases, let's remove it and reduce the code as well.

MEDIUM: frontend: move some remaining stream settings to stream_new()

The auto-forwarding mechanism in case no analyser is set is generic
to the streams. Also the timeouts on the client side are better preset
in the stream initialization as well.

MEDIUM: frontend: don't restrict frontend_accept() to connections anymore

Now it can also initialize streams initiated by applets. This will be
needed for HTTP/2.

MEDIUM: frontend: move the fd-specific settings to session_accept_fd()

The frontend is generic and does not depend on a file descriptor,
so applying some socket options to the incoming fd is not its role.
Let's move the setsockopt() calls earlier in session_accept_fd()
where others are done as well.

MEDIUM: frontend: move some stream initialisation to stream_new()

This is mostly what is related to logging, and which is more of
a stream initialization than anything frontend-specific.

MEDIUM: stream: return the stream upon accept()

The function was called stream_accept_session(), let's rename it
stream_new() and make it return the newly allocated pointer. It's
more convenient for some callers who need it.

MEDIUM: frontend: make ->accept only return +/-1

This function was specified as being able to return 3 states, which had
repercussions to the stream accept function. It was used at the time
when the frontend would do the monitoring itself. This is not the case
anymore, so let's simplify this.

MEDIUM: peers: make use of stream_accept_session()

Instead of going through some obscure initialization sequences, we now
rely on the stream code to initialize our stream. Some parts are still
a bit tricky as we cannot call the frontend's accept code which is only
made for appctx in input. So part of the initialization past the stream
code is what ought to be in the frontend code instead. Still, even
without this, these are 71 lines that were removed.

MEDIUM: stream: also accept appctx as origin in stream_accept_session()

It's likely that the code could be simplified a bit though.

MEDIUM: stream: isolate connection-specific initialization code

In stream_accept_session(), we perform some operations that explicitly
want a connection as the origin, but we'll soon have other types of
origin (eg: applet). Thus change the test to ensure we only call this
code with connections. Additionally, we refrain from calling fe->accept()
if the origin is not a connection, because for now the only fe->accept()
may only use a connection (frontend_accept).

CLEANUP: stream.c: do not re-attach the connection to the stream

This was a leftover from the initial code, it's not needed at all
anymore.

MINOR: session: set the CO_FL_CONNECTED flag on the connection once ready

If we know there's no handshake, we must set the flag on the connection,
it's not the job of the stream initializer to do it.

MEDIUM: peers: initialize the task before the stream

Thanks to this we should be able to make use of stream_accept_session()
now.

MINOR: peers: make use of session_new() when creating a new session

It's better than open-coding it.

MINOR: session: make use of session_new() when creating a new session

It's better than open-coding it.

MINOR: session: introduce session_new()

This one creates a new session and does the minimum initialization.

MEDIUM: peers: move the appctx initialization earlier

The purpose is to initialize the appctx prior to the stream in
order to reuse stream_accept_session().