About the parallel processing of iRules

However, the thing which I would like to do is just this.

 

"wait for the application server to decide for each request at request time and wait for that answer."

 

 

 

If that's really really what you want to do, then I can see two approaches. Both of them will very likely require some work on your part to make your verification server function in a way that's compatible with the solution.

 

 

The first approach is to use HTTP::retry. The way to do that is to have all requests go to a verification server pool by default, then check their result in HTTP_RESPONSE, and then use HTTP::retry to send the request to the real application pool (or not, depending on the result from the verification server).

 

 

The second approach is to use the DNS or AUTH functionality. The way to do that is to use HTTP::collect without a length parameter to buffer the entire client request, then send whatever data the verification server needs via a DNS request or authentication request, and wait for the verification GO/NO-GO decision via the NAME_RESOLVED or AUTH_RESULT events.

 

 

Like I said above, you'll need to make one of these approaches compatible with your verification server. One way to do this is to create some server which will listen for these HTTP, DNS, or authentication requests, translate them into some form appropriate for your verification server, send them, and translate the responses back for the BIG-IP system in some way to make the GO/NO-GO decision (for example, if you go the HTTP route, a 200 response could be GO, and a 404 response could be NO-GO).