iRule-hendelsesrekkefølge
Velg profilstakken på en BIG-IP-virtuell server — Client-SSL, HTTP, Server-SSL, pool — og se rekkefølgen de vanlige iRule-hendelsene utløses i, fra CLIENT_ACCEPTED til CLIENT_CLOSED, som tidslinje og liste. Alt i nettleseren.
NettverkDen virtuelle serverens profilstakk
Beregnet i nettleseren din. Ingenting sendes noe sted.
En modell av dokumentert F5-atferd for en Standard-virtuell server. Den kontakter aldri en BIG-IP.
Hendelsessekvens
Hendelser i rekkefølge
CLIENT_ACCEPTEDklientsidenA 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_CLIENTHELLOklientsidenThe client's TLS ClientHello has been received, before the handshake is processed. Useful for SNI-based decisions.
CLIENTSSL_HANDSHAKEklientsidenThe client-side TLS handshake has completed successfully.
HTTP_REQUESTklientsidenThe system has fully parsed the complete client HTTP request headers.
LB_SELECTEDglobaltThe system has selected a pool member for the connection.
SERVER_CONNECTEDserversidenThe server-side connection to the selected pool member has been established.
SERVERSSL_HANDSHAKEserversidenThe server-side TLS handshake has completed successfully.
HTTP_REQUEST_SENDserversidenImmediately before the HTTP request is sent to the server-side TCP stack. Runs in the server-side context.
HTTP_RESPONSEklientsidenThe system has parsed all of the response status and header lines from the server response.
SERVER_CLOSEDserversidenThe server-side connection has been closed.
CLIENT_CLOSEDklientsidenThe client-side connection has been closed.
Betingede hendelser
Disse utløses bare under bestemte betingelser: en TCP::collect eller HTTP::collect, en lastbalanseringsfeil, eller et 100 Continue-svar.
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.