iRule assistance

It's a matter of personal preference, but I like to consolidate iRules into one as much as possible.

You can use the return statement to prevent further logic from being executed under the same event within the same iRule

Does the following help?

when HTTP_REQUEST {
    if { [HTTP::path] starts_with "/resources/" } {
        pool pool_atldevngn
        return
    } 
    if { !( [class match [HTTP::uri] contains api_string] ) } {
        discard
        log local0. "connection DISCARDED from [IP::client_addr]"
        return
    }
    pool pool_atlapipool1
}

Michael,

Thanks for the quick reply! I am not familiar with the return statement. Would you be willing to explain the program flow of the consolidated iRule using the return statement? I would like the "resources" logic to be processed first, if the traffic does not meet that criteria then I want the F5 to move to the next statement in the iRule which is the "api_string". if again that condition is not met then just send the traffic to the atlapipool1 pool. Does this combined iRule do that?

Thanks!

What you just described is exactly the order in which the iRule will get processed.

 

You can find more information on the return statement here:

 

https://clouddocs.f5.com/api/irules/return.html

 

The return statement will make the F5 stop processing further logic within the same event within the same iRule (there are certain caveats to this e.g. if you specify priorities on the event)

 

For the above iRule in question, there is only one event i.e. HTTP_REQUEST so if the first IF statement evaluates as true, the return statement will stop the subsequent IF statements from being executed.

 

With the return statement, it is important to note that if you were to for example add another event further down to this iRule e.g. HTTP_RESPONSE, then this will still get executed since it's a different event. In addition, if you were to add a second separate iRule to the virtual server with the HTTP_REQUEST event, this will also still get executed even if the return statement got hit in the first iRule.

 

If you wanted to disable ALL further iRule execution (all events and all iRules applied to the virtual server) then you can use the event disable all command

 

Looks like this iRule you require. condition sequence can be changed based on the preference.

when HTTP_REQUEST { if { !([class match [HTTP::uri] contains api_string])} { discard log local0. "connection DISCARDED from [IP::client_addr]" } elseif { [HTTP::path] starts_with "/resources/" } { pool pool_atldevngn } else { pool pool_atlapipool1 } }

Looks like this iRule you require. condition sequence can be changed based on the preference.

when HTTP_REQUEST { if { !([class match [HTTP::uri] contains api_string])} { discard log local0. "connection DISCARDED from [IP::client_addr]" } elseif { [HTTP::path] starts_with "/resources/" } { pool pool_atldevngn } else { pool pool_atlapipool1 } }

return is nasty. Suppose u discarded in HTTP request, Here the http packet will be discarded but connection will be opened to server. Which can be a security hole.

event disable will cause all other event not to be executed for this connection, But securtity hole still exist.

Ideal way should be to respond back with error response and make sure connection is closed after that. Even if we discard the request, rule should be resetting the connection.

Good point about the return statement Uzair, I did not know it could potentially create a security hole.

You need to be really careful closing a TCP connection. If you are behind a service such as Akamai, closing a TCP connection for one HTTP request could drop connections for thousands of legitimate requests as Akamai multiplex (like OneConnect) connections from end clients.

Lee, that's another very good point! :-D