Forum Discussion

Robert_47833's avatar
Robert_47833
Icon for Altostratus rankAltostratus
Jul 22, 2015

disable irule process for the request not for the whole tcp connection

hi ,Iurle I need to stop irule process for the exact http request ,not for the whole tcp connection ,how to achieve this?  
application delivery
design
LTM
  • Kiozs_131042's avatar
    Kiozs_131042
    Jul 26, 2015

    Understood this topic is discussing some race conditions applied on iRule http events;

    client 1 --> http request1 --> F5 --> http request1 --> server
client 1 --> http request2 --> F5 --> http request2 --> server
client 1 --> http request3 --> F5 --> http request3 --> server
client 1 <-- http request1 <-- F5 <-- http response1 <-- server
client 1 <-- http request2 <-- F5 <-- http response2 <-- server
client 1 <-- http request3 <-- F5 <-- http response3 <-- server

    From LTM perspective, LTM will not process the subsequent request (but rather put it on the request queue instead)until first response is back from backend pool memeber.

    Even pipelining is enabled on client side and multiple requests come in at same time, LTM will still serialize them and process them according to the sequence (FIFO).

    So in our case, variable has been set in request 1 will not be messed up even request 2 comes in earlier than response 1.

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Jul 23, 2015

It's important to realize that (most) iRule events are based on OSI layer events.

CLIENT_ACCEPTED is triggered when the TCP handshake completes

HTTP_REQUEST is triggered when all of the headers from the client's HTTP request are consumed

HTTP_RESPONSE is triggered when all of the headers from the server's HTTP response are consumed

SERVER_CONNECTED is triggered when the server side TCP handshake completes

And so on. It's also important to understand that the proxy triggers these events in the order of the OSI model.

TCP events (4) -> SSL events (5/6) -> HTTP events (7)

and that multiple HTTP requests can exist inside a single TCP connection, and that a single SSL session can exist across multiple TCP connections. So to roughly answer your question, when a client makes an HTTP request, it must first initiate a TCP connection (if one doesn't already exist). Variables and (layer 5+) events live inside that TCP connection, so if you issue and event HTTP_REQUEST disable or HTTP::disable command, it affects all of the HTTP_REQUEST events within a single TCP connection. A new TCP connection resets that state.

out of curiosity, when the pool is selected , why it still need to process the other irules.

There are events that aren't specifically triggered by OSI layer events, including the LB events. The LB events generally happen after the HTTP request and before server side TCP.