tree ac4d577b29147a03438748a954c3a9f990d76e27
parent b8ffd378f0dfe57e4b613db80600816e83d8e2fa
author Willy Tarreau <w@1wt.eu> 1348782536 +0200
committer Willy Tarreau <w@1wt.eu> 1348783282 +0200

MEDIUM: monitor: simplify handling of monitor-net and mode health

We were having several different behaviours with monitor-net and
"mode health" :
  - monitor-net on TCP connections was evaluated just after accept(),
    did not count a connection on the frontend and were not subject
    to tcp-request connection rules, and caused an immediate close().

  - monitor-net in HTTP mode was evaluated once the session was
    accepted (eg: on top of SSL), returned "HTTP/1.0 200 OK\r\n\r\n"
    over the connection's data layer and instanciated a session which
    was responsible for closing this connection. A connection AND a
    session were counted for the frontend ;

  - "mode health" with "option httpchk" would do exactly the same as
    monitor-net in HTTP mode ;

  - "mode health" without "option httpchk" would do the same as above
    except that "OK" was returned instead of "HTTP/1.0 200 OK\r\n\r\n".

None of them took care of cleaning the input buffer, sometimes resulting
in a TCP reset to be emitted after the last packet if a request was received
over the connection.

Given the inconsistencies and the complexity in keeping all these features
handled at the right position, we now slightly changed the way they are
handled :

  - all of them are handled just after the "tcp-request connection" rules,
    so that all of them may be blocked using such rules, offering more
    flexibility and consistency ;

  - no connection handshake is performed anymore for non-TCP modes

  - all of them send the response as raw data over the socket, there is no
    more difference between TCP and HTTP mode for example (these rules were
    never meant to be served over SSL connections and were never documented
    as able to do that).

  - any possible pending data on the incoming socket is drained before the
    response is sent, in order to avoid the risk of a reset.

  - none of them exactly did what was documented !

This results in more consistent, more flexible and more accurate handling of
monitor rules, with smaller and more robust code.