Ordine degli eventi iRule
Scegli lo stack di profili di un virtual server BIG-IP — Client-SSL, HTTP, Server-SSL, pool — e guarda l'ordine in cui scattano gli eventi iRule comuni, da CLIENT_ACCEPTED a CLIENT_CLOSED, come timeline ed elenco. Tutto nel tuo browser.
RetiStack di profili del virtual server
Calcolato nel tuo browser. Niente viene inviato.
Un modello del comportamento documentato di F5 per un virtual server Standard. Non contatta mai un BIG-IP.
Sequenza degli eventi
Eventi in ordine
CLIENT_ACCEPTEDlato clientA client connection is established. On a Standard virtual server this is when the TCP three-way handshake completes; on FastL4 it fires on the initial SYN.
CLIENTSSL_CLIENTHELLOlato clientThe client's TLS ClientHello has been received, before the handshake is processed. Useful for SNI-based decisions.
CLIENTSSL_HANDSHAKElato clientThe client-side TLS handshake has completed successfully.
HTTP_REQUESTlato clientThe system has fully parsed the complete client HTTP request headers.
LB_SELECTEDglobaleThe system has selected a pool member for the connection.
SERVER_CONNECTEDlato serverThe server-side connection to the selected pool member has been established.
SERVERSSL_HANDSHAKElato serverThe server-side TLS handshake has completed successfully.
HTTP_REQUEST_SENDlato serverImmediately before the HTTP request is sent to the server-side TCP stack. Runs in the server-side context.
HTTP_RESPONSElato clientThe system has parsed all of the response status and header lines from the server response.
SERVER_CLOSEDlato serverThe server-side connection has been closed.
CLIENT_CLOSEDlato clientThe client-side connection has been closed.
Eventi condizionali
Questi scattano solo a condizioni specifiche: un TCP::collect o HTTP::collect, un fallimento del bilanciamento, o una risposta 100 Continue.
HTTP_REQUEST_DATA↪ HTTP_REQUESTAfter an HTTP::collect has gathered the specified amount of request payload.
LB_FAILED↪ LB_SELECTEDInstead of LB_SELECTED, when the system fails to select a pool or member, or the selected resource is unreachable.
HTTP_RESPONSE_CONTINUE↪ HTTP_RESPONSEBefore HTTP_RESPONSE, whenever the server sends a 100 Continue interim response.
HTTP_RESPONSE_DATA↪ HTTP_RESPONSEAfter an HTTP::collect has gathered the specified amount of response payload.
- Within a single event, multiple iRules run by priority (default 500, lowest number first); the priority command overrides that. This ordering is across events, not within one.
- Availability also depends on provisioning: module events (APM ACCESS_*, ASM/Advanced WAF, bot defense) only fire when that module is provisioned. And CLIENT_DATA, SERVER_DATA, HTTP_REQUEST_DATA, and HTTP_RESPONSE_DATA need an explicit TCP::collect or HTTP::collect first.