| ----------------------------------------------- |
| Stream Processing Offload Engine (SPOE) |
| Version 1.0 |
| ( Last update: 2016-11-07 ) |
| ----------------------------------------------- |
| Author : Christopher Faulet |
| Contact : cfaulet at haproxy dot com |
| |
| |
| SUMMARY |
| -------- |
| |
| 0. Terms |
| 1. Introduction |
| 2. SPOE configuration |
| 2.1. SPOE scope |
| 2.2. "spoe-agent" section |
| 2.3. "spoe-message" section |
| 2.4. Example |
| 3. SPOP specification |
| 3.1. Data types |
| 3.2. Frames |
| 3.2.1. Frame capabilities |
| 3.2.2. Frame types overview |
| 3.2.3. Workflow |
| 3.2.4. Frame: HAPROXY-HELLO |
| 3.2.5. Frame: AGENT-HELLO |
| 3.2.6. Frame: NOTIFY |
| 3.2.7. Frame: ACK |
| 3.2.8. Frame: HAPROXY-DISCONNECT |
| 3.2.9. Frame: AGENT-DISCONNECT |
| 3.3. Events & messages |
| 3.4. Actions |
| 3.5. Error & timeouts |
| |
| |
| 0. Terms |
| --------- |
| |
| * SPOE : Stream Processing Offload Engine. |
| |
| A SPOE is a filter talking to servers managed ba a SPOA to offload the |
| stream processing. An engine is attached to a proxy. A proxy can have |
| several engine. Each engine is linked to an agent and only one. |
| |
| * SPOA : Stream Processing Offload Agent. |
| |
| A SPOA is a service that will receive info from a SPOE to offload the |
| stream processing. An agent manages several servers. It uses a backend to |
| reference all of them. By extension, these servers can also be called |
| agents. |
| |
| * SPOP : Stream Processing Offload Protocol, used by SPOEs to talk to SPOA |
| servers. |
| |
| This protocol is used by engines to talk to agents. It is an in-house |
| binary protocol described in this documentation. |
| |
| |
| 1. Introduction |
| ---------------- |
| |
| SPOE is a feature introduced in HAProxy 1.7. It makes possible the |
| communication with external components to retrieve some info. The idea started |
| with the problems caused by most ldap libs not working fine in event-driven |
| systems (often at least the connect() is blocking). So, it is hard to properly |
| implement Single Sign On solution (SSO) in HAProxy. The SPOE will ease this |
| kind of processing, or we hope so. |
| |
| Now, the aim of SPOE is to allow any kind of offloading on the streams. First |
| releases, besides being experimental, won't do lot of things. As we will see, |
| there are few handled events and even less actions supported. Actually, for |
| now, the SPOE can offload the processing before "tcp-request content", |
| "tcp-response content", "http-request" and "http-response" rules. And it only |
| supports variables definition. But, in spite of these limited features, we can |
| easily imagine to implement SSO solution, ip reputation or ip geolocation |
| services. |
| |
| |
| 2. SPOE configuration |
| ---------------------- |
| |
| Because SPOE is implemented as a filter, To use it, you must declare a "filter |
| spoe" line in a proxy section (frontend/backend/listen) : |
| |
| frontend my-front |
| ... |
| filter spoe [engine <name>] config <file> |
| ... |
| |
| The "config" parameter is mandatory. It specififies the SPOE configuration |
| file. The engine name is optional. It can be set to declare the scope to use in |
| the SPOE configuration. So it is possible to use the same SPOE configuration |
| for several engines. If no name is provided, the SPOE configuration must not |
| contain any scope directive. |
| |
| We use a separate configuration file on purpose. By commenting SPOE filter |
| line, you completly disable the feature, including the parsing of sections |
| reserved to SPOE. This is also a way to keep the HAProxy configuration clean. |
| |
| A SPOE configuration file must contains, at least, the SPOA configuration |
| ("spoe-agent" section) and SPOE messages ("spoe-message" section) attached to |
| this agent. Unused messages (not reference in "spoe-agent" section) will be |
| ignored. |
| |
| IMPORTANT : The configuration of a SPOE filter must be located in a dedicated |
| file. But the backend used by a SPOA must be declared in HAProxy configuration |
| file. |
| |
| 2.1. SPOE scope |
| ------------------------- |
| |
| If you specify an engine name on the SPOE filter line, then you need to define |
| scope in the SPOE configuration with the same name. You can have several SPOE |
| scope in the same file. In each scope, you must define one and only one |
| "spoe-agent" section to configure the SPOA linked to your SPOE and several |
| "spoe-message" sections to describe messages sent to servers mananger by your |
| SPOA. |
| |
| A SPOE scope starts with this kind of line : |
| |
| [<name>] |
| |
| where <name> is the same engine name specified on the SPOE filter line. The |
| scope ends when the file ends or when another scope is found. |
| |
| Example : |
| [my-first-engine] |
| spoe-agent my-agent |
| ... |
| spoe-message msg1 |
| ... |
| spoe-message msg2 |
| ... |
| |
| [my-second-engine] |
| ... |
| |
| If no engine name is provided on the SPOE filter line, no SPOE scope must be |
| found in the SPOE configuration file. All the file is considered to be in the |
| same anonymous and implicit scope. |
| |
| 2.2. "spoe-agent" section |
| -------------------------- |
| |
| For each engine, you must define one and only one "spoe-agent" section. In this |
| section, you will declare SPOE messages and the backend you will use. You will |
| also set timeouts and options to customize your agent's behaviour. |
| |
| |
| spoe-agent <name> |
| Create a new SPOA with the name <name>. It must have one and only one |
| "spoe-agent" definition by SPOE scope. |
| |
| Arguments : |
| <name> is the name of the agent section. |
| |
| following keywords are supported : |
| - messages |
| - option var-prefix |
| - timeout hello|idle|ack |
| - use-backend |
| |
| |
| messages <msg-name> ... |
| Declare the list of SPOE messages that an agent will handle. |
| |
| Arguments : |
| <msg-name> is the name of a SPOE message. |
| |
| Messages declared here must be found in the same engine scope, else an error |
| is triggered during the configuration parsing. You can have many "messages" |
| lines. |
| |
| See also: "spoe-message" section. |
| |
| |
| option var-prefix <prefix> |
| Define the prefix used when variables are set by an agent. |
| |
| Arguments : |
| |
| <prefix> is the prefix used to limit the scope of variables set by an |
| agent. |
| |
| To avoid conflict with other variables defined by HAProxy, all variables |
| names will be prefixed. By default, the "spoe-agent" name is used. This |
| option can be used to customize it. |
| |
| The prefix will be added between the variable scope and its name, separated |
| by a '.'. It may only contain characters 'a-z', 'A-Z', '0-9', '.' and '_', as |
| for variables name. In HAProxy configuration, you need to use this prefix as |
| a part of the variables name. For example, if an agent define the variable |
| "myvar" in the "txn" scope, with the prefix "my_spoe_pfx", then you should |
| use "txn.my_spoe_pfx.myvar" name in your HAProxy configuration. |
| |
| An agent will never set new variables at runtime. It can only set new value |
| for existing ones. |
| |
| |
| timeout ack <timeout> |
| Set the maximum time to wait for an agent to receive the acknowledgement to a |
| NOTIFY frame. |
| |
| Arguments : |
| <timeout> is the timeout value specified in milliseconds by default, but |
| can be in any other unit if the number is suffixed by the unit, |
| as explained at the top of this document. |
| |
| |
| timeout hello <timeout> |
| Set the maximum time to wait for an agent to receive the AGENT-HELLO frame. |
| |
| Arguments : |
| <timeout> is the timeout value specified in milliseconds by default, but |
| can be in any other unit if the number is suffixed by the unit, |
| as explained at the top of this document. |
| |
| This timeout is an applicative timeout. It differ from "timeout connect" |
| defined on backends. |
| |
| |
| timeout idle <timeout> |
| Set the maximum time to wait for an agent to close an idle connection. |
| |
| Arguments : |
| <timeout> is the timeout value specified in milliseconds by default, but |
| can be in any other unit if the number is suffixed by the unit, |
| as explained at the top of this document. |
| |
| |
| use-backend <backend> |
| Specify the backend to use. It must be defined. |
| |
| Arguments : |
| <backend> is the name of a valid "backend" section. |
| |
| |
| 2.3. "spoe-message" section |
| ---------------------------- |
| |
| To offload the stream processing, SPOE will send messages with specific |
| information at a specific moment in the stream life and will wait for |
| corresponding replies to know what to do. |
| |
| |
| spoe-message <name> |
| Create a new SPOE message with the name <name>. |
| |
| Arguments : |
| <name> is the name of the SPOE message. |
| |
| Here you define a message that can be referenced in a "spoe-agent" |
| section. Following keywords are supported : |
| - args |
| - event |
| |
| See also: "spoe-agent" section. |
| |
| |
| args [name=]<sample> ... |
| Define arguments passed into the SPOE message. |
| |
| Arguments : |
| <sample> is a sample expression. |
| |
| When the message is processed, if a sample expression is not available, it is |
| set to NULL. Arguments are processed in their declaration order and added in |
| the message in that order. It is possible to declare named arguements. |
| |
| For example: |
| args frontend=fe_id src dst |
| |
| |
| event <name> |
| Set the event that triggers sending of the message. |
| |
| Argument : |
| <name> is the event name. |
| |
| Supported events are: |
| - on-client-session |
| - on-server-connectiob |
| - on-frontend-tcp-request |
| - on-backend-tcp-request |
| - on-tcp-response |
| - on-frontend-http-request |
| - on-backend-http-request |
| - on-http-response |
| |
| See section 3.5 about Events. |
| |
| 2.4. Example |
| ------------- |
| |
| Here is a simple but complete example that sends client-ip address to a ip |
| reputation service. This service can set the variable "ip_score" which is an |
| integer between 0 and 100, indicating its reputation (100 means totally safe |
| and 0 a blacklisted IP with no doubt). |
| |
| ### |
| ### HAProxy configuration |
| frontend www |
| mode http |
| bind *:80 |
| |
| filter spoe engine ip-reputation config spoe-ip-reputation.conf |
| |
| # Reject connection if the IP reputation is under 20 |
| tcp-request content reject if { var(sess.iprep.ip_score) -m int lt 20 } |
| |
| default_backend http-servers |
| |
| backend http-servers |
| mode http |
| server http A.B.C.D:80 |
| |
| backend iprep-servers |
| mode tcp |
| balance roundrobin |
| |
| timeout connect 5s # greater than hello timeout |
| timeout server 3m # greater than idle timeout |
| |
| server iprep1 A1.B1.C1.D1:12345 |
| server iprep2 A2.B2.C2.D2:12345 |
| |
| #### |
| ### spoe-ip-reputation.conf |
| [ip-reputation] |
| |
| spoe-agent iprep-agent |
| messages get-ip-reputation |
| |
| option var-prefix iprep |
| |
| timeout hello 2s |
| timeout ack 10ms |
| timeout idle 2m |
| |
| use-backend iprep-servers |
| |
| spoe-message get-ip-reputation |
| args ip=src |
| event on-client-session |
| |
| |
| 3. SPOP specification |
| ---------------------- |
| |
| 3.1. Data types |
| ---------------- |
| |
| Here is the bytewise representation of typed data: |
| |
| TYPED-DATA : <TYPE:4 bits><FLAGS:4 bits><DATA> |
| |
| Supported types and their representation are: |
| |
| TYPE | ID | DESCRIPTION |
| -----------------------------+-----+---------------------------------- |
| NULL | 0 | NULL : <0> |
| Boolean | 1 | BOOL : <1+FLAG> |
| 32bits signed integer | 2 | INT32 : <2><VALUE:varint> |
| 32bits unsigned integer | 3 | UINT32 : <3><VALUE:varint> |
| 64bits signed integer | 4 | INT64 : <4><VALUE:varint> |
| 32bits unsigned integer | 5 | UNIT64 : <5><VALUE:varint> |
| IPV4 | 6 | IPV4 : <6><STRUCT IN_ADDR:4 bytes> |
| IPV6 | 7 | IPV6 : <7><STRUCT IN_ADDR6:16 bytes> |
| String | 8 | STRING : <8><LENGTH:varint><BYTES> |
| Binary | 9 | BINARY : <9><LENGTH:varint><BYTES> |
| 10 -> 15 unused/reserved | - | - |
| -----------------------------+-----+---------------------------------- |
| |
| Variable-length integer (varint) are encoded using Peers encoding: |
| |
| |
| 0 <= X < 240 : 1 byte (7.875 bits) [ XXXX XXXX ] |
| 240 <= X < 2288 : 2 bytes (11 bits) [ 1111 XXXX ] [ 0XXX XXXX ] |
| 2288 <= X < 264432 : 3 bytes (18 bits) [ 1111 XXXX ] [ 1XXX XXXX ] [ 0XXX XXXX ] |
| 264432 <= X < 33818864 : 4 bytes (25 bits) [ 1111 XXXX ] [ 1XXX XXXX ]*2 [ 0XXX XXXX ] |
| 33818864 <= X < 4328786160 : 5 bytes (32 bits) [ 1111 XXXX ] [ 1XXX XXXX ]*3 [ 0XXX XXXX ] |
| ... |
| |
| For booleans, the value (true or false) is the first bit in the FLAGS |
| bitfield. if this bit is set to 0, then the boolean is evaluated as false, |
| otherwise, the boolean is evaluated as true. |
| |
| 3.2. Frames |
| ------------ |
| |
| Exchange between HAProxy and agents are made using FRAME packets. All frames |
| must be prefixed with their size encoded on 4 bytes in network byte order: |
| |
| <FRAME-LENGTH:4 bytes> <FRAME> |
| |
| A frame always starts with its type, on one byte, followed by metadata |
| containing flags, on 4 bytes and a two variable-length integer representing the |
| stream identifier and the frame identifier inside the stream: |
| |
| FRAME : <FRAME-TYPE:1 byte> <METADATA> <FRAME-PAYLOAD> |
| METADATA : <FLAGS:4 bytes> <STREAM-ID:varint> <FRAME-ID:varint> |
| |
| Then comes the frame payload. Depending on the frame type, the payload can be |
| of three types: a simple key/value list, a list of messages or a list of |
| actions. |
| |
| FRAME-PAYLOAD : <LIST-OF-MESSAGES> | <LIST-OF-ACTIONS> | <KV-LIST> |
| |
| LIST-OF-MESSAGES : [ <MESSAGE-NAME> <NB-ARGS:1 byte> <KV-LIST> ... ] |
| MESSAGE-NAME : <STRING> |
| |
| LIST-OF-ACTIONS : [ <ACTION-TYPE:1 byte> <NB-ARGS:1 byte> <ACTION-ARGS> ... ] |
| ACTION-ARGS : [ <TYPED-DATA>... ] |
| |
| KV-LIST : [ <KV-NAME> <KV-VALUE> ... ] |
| KV-NAME : <STRING> |
| KV-VALUE : <TYPED-DATA> |
| |
| FLAGS : 0 1-31 |
| +---+-----------+ |
| | F| | |
| | I| RESERVED | |
| | N| | |
| +--+------------+ |
| |
| FIN: Indicates that this is the final payload fragment. The first fragment |
| may also be the final fragment. |
| |
| Frames cannot exceed a maximum size negociated between HAProxy and agents |
| during the HELLO handshake. Most of time, payload will be small enough to send |
| it in one frame. But when supported by the peer, it will be possible to |
| fragment huge payload on many frames. This ability is announced during the |
| HELLO handshake and it can be asynmetric (supported by agents but not by |
| HAProxy or the opposite). The following rules apply to fragmentation: |
| |
| * An unfragemnted payload consists of a single frame with the FIN bit set. |
| |
| * A fragemented payload consists of several frames with the FIN bit clear and |
| terminated by a single frame with the FIN bit set. All these frames must |
| share the same STREAM-ID and FRAME-ID. And, of course, the FRAME-TYPE must |
| be the same. |
| |
| Beside the support of fragmented payload by a peer, some payload must not be |
| fragmented. See below for details. |
| |
| IMPORTANT : The maximum size supported by peers for a frame must be greater or |
| equal to 256 bytes. |
| |
| 3.2.1. Frame capabilities |
| -------------------------- |
| |
| Here are the list of official capabilities that HAProxy and agents can support: |
| |
| * fragmentation: This is the abaility for a peer to support fragmented |
| payload in received frames. |
| |
| Unsupported or unknown capabilities are silently ignored, when possible. |
| |
| 3.2.2. Frame types overview |
| ---------------------------- |
| |
| Here are types of frame supported by SPOE. Frames sent by HAProxy come first, |
| then frames sent by agents : |
| |
| TYPE | ID | DESCRIPTION |
| -----------------------------+-----+------------------------------------- |
| HAPROXY-HELLO | 1 | Sent by HAProxy when it opens a |
| | | connection on an agent. |
| | | |
| HAPROXY-DISCONNECT | 2 | Sent by HAProxy when it want to close |
| | | the connection or in reply to an |
| | | AGENT-DISCONNECT frame |
| | | |
| NOTIFY | 3 | Sent by HAProxy to pass information |
| | | to an agent |
| -----------------------------+-----+------------------------------------- |
| AGENT-HELLO | 101 | Reply to a HAPROXY-HELLO frame, when |
| | | the connection is established |
| | | |
| AGENT-DISCONNECT | 102 | Sent by an agent just before closing |
| | | the connection |
| | | |
| ACK | 103 | Sent to acknowledge a NOTIFY frame |
| -----------------------------+-----+------------------------------------- |
| |
| Unknown frames may be silently skipped. |
| |
| 3.2.3. Workflow |
| ---------------- |
| |
| * Successful HELLO handshake: |
| |
| HAPROXY AGENT SRV |
| | HAPROXY-HELLO | |
| | (healthcheck: false) | |
| | --------------------------> | |
| | | |
| | AGENT-HELLO | |
| | <-------------------------- | |
| | | |
| |
| * Successful HELLO healthcheck: |
| |
| HAPROXY AGENT SRV |
| | HAPROXY-HELLO | |
| | (healthcheck: true) | |
| | --------------------------> | |
| | | |
| | AGENT-HELLO + close() | |
| | <-------------------------- | |
| | | |
| |
| |
| * Error encountered by agent during the HELLO handshake: |
| |
| HAPROXY AGENT SRV |
| | HAPROXY-HELLO | |
| | --------------------------> | |
| | | |
| | DISCONNECT + close() | |
| | <-------------------------- | |
| | | |
| |
| * Error encountered by HAProxy during the HELLO handshake: |
| |
| HAPROXY AGENT SRV |
| | HAPROXY-HELLO | |
| | --------------------------> | |
| | | |
| | AGENT-HELLO | |
| | <-------------------------- | |
| | | |
| | DISCONNECT | |
| | --------------------------> | |
| | | |
| | DISCONNECT + close() | |
| | <-------------------------- | |
| | | |
| |
| * Notify / Ack exchange: |
| |
| HAPROXY AGENT SRV |
| | NOTIFY | |
| | --------------------------> | |
| | | |
| | ACK | |
| | <-------------------------- | |
| | | |
| |
| * Connection closed by haproxy: |
| |
| HAPROXY AGENT SRV |
| | DISCONNECT | |
| | --------------------------> | |
| | | |
| | DISCONNECT + close() | |
| | <-------------------------- | |
| | | |
| |
| * Connection closed by agent: |
| |
| HAPROXY AGENT SRV |
| | DISCONNECT + close() | |
| | <-------------------------- | |
| | | |
| |
| 3.2.4. Frame: HAPROXY-HELLO |
| ---------------------------- |
| |
| This frame is the first one exchanged between HAProxy and an agent, when the |
| connection is established. The payload of this frame is a KV-LIST. It cannot be |
| fragmented. STREAM-ID and FRAME-ID are must be set 0. |
| |
| Following items are mandatory in the KV-LIST: |
| |
| * "supported-versions" <STRING> |
| |
| Last SPOP major versions supported by HAProxy. It is a comma-separated list |
| of versions, following the format "Major.Minor". Spaces must be ignored, if |
| any. When a major version is announced by HAProxy, it means it also support |
| all previous minor versions. |
| |
| Example: "2.0, 1.5" means HAProxy supports SPOP 2.0 and 1.0 to 1.5 |
| |
| * "max-frame-size" <UINT32> |
| |
| This is the maximum size allowed for a frame. The HAPROXY-HELLO frame must |
| be lower or equal to this value. |
| |
| * "capabilities" <STRING> |
| |
| This a comma-separated list of capabilities supported by HAProxy. Spaces |
| must be ignored, if any. |
| |
| Following optional items can be added in the KV-LIST: |
| |
| * "healthcheck" <BOOLEAN> |
| |
| If this item is set to TRUE, then the HAPROXY-HELLO frame is sent during a |
| SPOE health check. When set to FALSE, this item can be ignored. |
| |
| To finish the HELLO handshake, the agent must return an AGENT-HELLO frame with |
| its supported SPOP version, the lower value between its maximum size allowed |
| for a frame and the HAProxy one and capabilities it supports. If an error |
| occurs or if an incompatibility is detected with the agent configuration, an |
| AGENT-DISCONNECT frame must be returned. |
| |
| 3.2.5. Frame: AGENT-HELLO |
| -------------------------- |
| |
| This frame is sent in reply to a HAPROXY-HELLO frame to finish a HELLO |
| handshake. As for HAPROXY-HELLO frame, STREAM-ID and FRAME-ID are also set |
| 0. The payload of this frame is a KV-LIST and it cannot be fragmented. |
| |
| Following items are mandatory in the KV-LIST: |
| |
| * "version" <STRING> |
| |
| This is the SPOP version the agent supports. It must follow the format |
| "Major.Minor" and it must be lower or equal than one of major versions |
| announced by HAProxy. |
| |
| * "max-frame-size" <UINT32> |
| |
| This is the maximum size allowed for a frame. It must be lower or equal to |
| the value in the HAPROXY-HELLO frame. This value will be used for all |
| subsequent frames. |
| |
| * "capabilities" <STRING> |
| |
| This a comma-separated list of capabilities supported by agent. Spaces must |
| be ignored, if any. |
| |
| At this time, if everything is ok for HAProxy (supported version and valid |
| max-frame-size value), the HELLO handshake is successfully completed. Else, |
| HAProxy sends a HAPROXY-DISCONNECT frame with the corresponding error. |
| |
| If "healthcheck" item was set to TRUE in the HAPROXY-HELLO frame, the agent can |
| safely close the connection without DISCONNECT frame. In all cases, HAProxy |
| will close the connexion at the end of the health check. |
| |
| 3.2.6. Frame: NOTIFY |
| --------------------- |
| |
| Information are sent to the agents inside NOTIFY frames. These frames are |
| attached to a stream, so STREAM-ID and FRAME-ID must be set. The payload of |
| NOTIFY frames is a LIST-OF-MESSAGES and, if supported by agents, it can be |
| fragmented. |
| |
| NOTIFY frames must be acknowledge by agents sending an ACK frame, repeating |
| right STREAM-ID and FRAME-ID. |
| |
| 3.2.7. Frame: ACK |
| ------------------ |
| |
| ACK frames must be sent by agents to reply to NOTIFY frames. STREAM-ID and |
| FRAME-ID found in a NOTIFY frame must be reuse in the corresponding ACK |
| frame. The payload of ACK frames is a LIST-OF-ACTIONS and, if supported by |
| HAProxy, it can be fragmented. |
| |
| 3.2.8. Frame: HAPROXY-DISCONNECT |
| --------------------------------- |
| |
| If an error occurs, at anytime, from the HAProxy side, a HAPROXY-DISCONNECT |
| frame is sent with information describing the error. HAProxy will wait an |
| AGENT-DISCONNECT frame in reply. All other frames will be ignored. The agent |
| must then close the socket. |
| |
| The payload of this frame is a KV-LIST. It cannot be fragmented. STREAM-ID and |
| FRAME-ID are must be set 0. |
| |
| Following items are mandatory in the KV-LIST: |
| |
| * "status-code" <UINT32> |
| |
| This is the code corresponding to the error. |
| |
| * "message" <STRING> |
| |
| This is a textual message describing the error. |
| |
| For more information about known errors, see section "Errors & timeouts" |
| |
| 3.2.9. Frame: AGENT-DISCONNECT |
| ------------------------------- |
| |
| If an error occurs, at anytime, from the agent size, a AGENT-DISCONNECT frame |
| is sent, with information desribing the error. such frame is also sent in reply |
| to a HAPROXY-DISCONNECT. The agent must close the socket just after sending |
| this frame. |
| |
| The payload of this frame is a KV-LIST. It cannot be fragmented. STREAM-ID and |
| FRAME-ID are must be set 0. |
| |
| Following items are mandatory in the KV-LIST: |
| |
| * "status-code" <UINT32> |
| |
| This is the code corresponding to the error. |
| |
| * "message" <STRING> |
| |
| This is a textual message describing the error. |
| |
| For more information about known errors, see section "Errors & timeouts" |
| |
| 3.3. Events & Messages |
| ----------------------- |
| |
| Information about streams are sent in NOTIFY frames. You can specify which kind |
| of information to send by defining "spoe-message" sections in your SPOE |
| configuration file. for each "spoe-message" there will be a message in a NOTIFY |
| frame when the right event is triggered. |
| |
| A NOTIFY frame is sent for an specific event when there is at least one |
| "spoe-message" attached to this event. All messages for an event will be added |
| in the same NOTIFY frame. |
| |
| Here is the list of supported events: |
| |
| * on-client-session is triggered when a new client session is created. |
| This event is only available for SPOE filters |
| declared in a frontend or a listen section. |
| |
| * on-frontend-tcp-request is triggered just before the evaluation of |
| "tcp-request content" rules on the frontend side. |
| This event is only available for SPOE filters |
| declared in a frontend or a listen section. |
| |
| * on-backend-tcp-request is triggered just before the evaluation of |
| "tcp-request content" rules on the backend side. |
| This event is skipped for SPOE filters declared |
| in a listen section. |
| |
| * on-frontend-http-request is triggered just before the evaluation of |
| "http-request" rules on the frontend side. This |
| event is only available for SPOE filters declared |
| in a frontend or a listen section. |
| |
| * on-backend-http-request is triggered just before the evaluation of |
| "http-request" rules on the backend side. This |
| event is skipped for SPOE filters declared in a |
| listen section. |
| |
| * on-server-session is triggered when the session with the server is |
| established. |
| |
| * on-tcp-response is triggered just before the evaluation of |
| "tcp-response content" rules. |
| |
| * on-http-response is triggered just before the evaluation of |
| "http-response" rules. |
| |
| |
| The stream processing will loop on these events, when triggered, waiting the |
| agent reply. |
| |
| 3.4. Actions |
| ------------- |
| |
| An agent must acknowledge each NOTIFY frame by sending the corresponding ACK |
| frame. Actions can be added in these frames to dynamically take action on the |
| processing of a stream. |
| |
| Here is the list of supported actions: |
| |
| * set-var set the value for an existing variable. 3 arguments must be |
| attached to this action: the variable scope (proc, sess, txn, |
| req or req), the variable name (a string) and its value. |
| |
| ACTION-SET-VAR : <SET-VAR:1 byte><NB-ARGS:1 byte><VAR-SCOPE:1 byte><VAR-NAME><VAR-VALUE> |
| |
| SET-VAR : <1> |
| NB-ARGS : <3> |
| VAR-SCOPE : <PROCESS> | <SESSION> | <TRANSACTION> | <REQUEST> | <RESPONSE> |
| VAR-NAME : <STRING> |
| VAR-VALUE : <TYPED-DATA> |
| |
| PROCESS : <0> |
| SESSION : <1> |
| TRANSACTION : <2> |
| REQUEST : <3> |
| RESERVED : <4> |
| |
| * unset-var unset the value for an existing variable. 2 arguments must be |
| attached to this action: the variable scope (proc, sess, txn, |
| req or req) and the variable name (a string). |
| |
| ACTION-UNSET-VAR : <SET-VAR:1 byte><NB-ARGS:1 byte><VAR-SCOPE:1 byte><VAR-NAME> |
| |
| SET-VAR : <1> |
| NB-ARGS : <3> |
| VAR-SCOPE : <PROCESS> | <SESSION> | <TRANSACTION> | <REQUEST> | <RESPONSE> |
| VAR-NAME : <STRING> |
| |
| PROCESS : <0> |
| SESSION : <1> |
| TRANSACTION : <2> |
| REQUEST : <3> |
| RESERVED : <4> |
| |
| |
| NOTE: Name of the variables will be automatically prefixed by HAProxy to avoid |
| name clashes with other variables used in HAProxy. Moreover, unknown |
| variable will be silently ignored. |
| |
| 3.5. Error & timeouts |
| ---------------------- |
| |
| Here is the list of all known errors: |
| |
| STATUS CODE | DESCRIPTION |
| ----------------+-------------------------------------------------------- |
| 0 | normal (no error occurred) |
| 1 | I/O error |
| 2 | A timeout occurred |
| 3 | frame is too big |
| 4 | invalid frame received |
| 5 | version value not found |
| 6 | max-frame-size value not found |
| 7 | capabilities value not found |
| 8 | unsupported version |
| 9 | max-frame-size too big or too small |
| 99 | an unknown error occurrde |
| ----------------+-------------------------------------------------------- |
| |
| An agent can define its own errors using a not yet assigned status code. |
| |
| IMPORTANT NOTE: For a specific stream, when an abnormal/unexpected error |
| occurs, the SPOE is disabled for all the transaction. So if you |
| have several events configured, such error on an event will |
| disabled all followings. For TCP streams, this will disable the |
| SPOE for the whole session. For HTTP streams, this will disable |
| it for the transaction (request and response). |
| |
| To avoid a stream to wait infinitly, you must carefully choose the |
| acknowledgement timeout. In most of cases, it will be quiet low. But it depends |
| on the responsivness of your service. |
| |
| You must also choose idle timeout carefully. Because connection with your |
| service depends on the backend configuration used by the SPOA, it is important |
| to use a lower value for idle timeout than the server timeout. Else the |
| connection will be closed by HAProxy. The same is true for hello timeout. You |
| should choose a lower value than the connect timeout. |
| |
| |
| /* |
| * Local variables: |
| * fill-column: 79 |
| * End: |
| */ |