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

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

For most functions iRules are executed for each request. If you use when HTTP_REQUEST or HTTP_RESPONSE it/they will be executed on each HTTP request and response.

Now if you use when CLIENT_ACCEPTED that is not executed on each request, just when the TCP connection is established.

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.

irule1:
 when HTTP_request {
  if xxx {
  do something
  }
 }

 irule2:

 when HTTP_request {
  if xxx {
  do something
  }
 }

after irule1 is evaluated, I want to disable irule2 in the http request level , not the tcp connection level

Right, so something like this:

irule1:

when HTTP_request {
    if xxx {
        do something
        event HTTP_REQUEST disable
    }
}

irule2:

when HTTP_request {
    if xxx {
        do something
    }
}

So you only want the HTTP request in iRule 2 to be disabled? Do you need to disable the event itself, or just the stuff inside the event (ie. is it okay if iRule 2's HTTP_REQUEST event still fires even if its content it blocked?).

It'd be trickier if you wanted to disable the event completely (for that TCP connection), but you could do something like this to disable the contents of the event:

irule1:

when HTTP_request {
    if xxx {
        do something
        set disable 1
    }
}

irule2:

when HTTP_request {
    if { [info exists disable] } {
        log local0. "event disabled"
    } else {
        if xxx {
            do something
        }
    }
}

one question:

Yes. iRules variables are TCP connection scoped - meaning they exist for the life of a discreet TCP connection. If you create a variable in one event you can manipulate it in another if their both in the same TCP connection. I'd also point out here that when you add multiple iRules to a VIP, and those iRules contain the same events (ex. HTTP_REQUEST), these events are compiled into one event. That's why the order of the iRules (an option in the GUI in 11.x and a "priority" option in the event declaration otherwise) is so important.

but if in http request 1, variable is set as 0, the response for this request 1 is not coming back from server.then request 2 hit irule , then change the variable to another value . is it possible? I don't wanna this happen