How do I make an iRule read each connection?

An iRule attached to the CLIENT_ACCEPTED event will be executed for each connection.

What you may be seeing is that a refresh on a browser window will not necessarily create new connections. It will re-use existing connections to get your information. This is the default standard for HTTP 1.1.

It is easy to test this behaviour. Attach this iRule to your virtual and watch the logs /var/log/ltm as you hit refresh on your browser. You may get the desired behaviour with shift-refresh but your milage will vary depending on the browser's implementation.

when CLIENT_ACCEPTED {
  set cid [clock clicks]
  log local0. "\[$cid\] Found... TCP CONNECTION!"
}

when HTTP_REQUEST {
  log local0. "\[$cid\] Found... HTTP REQUEST!"
}

The number in brackets [451544] at the start of each log message will be a unique number representing that TCP connection. Because the BIGIP handles many connections in parallel this helps you to determine which connection the log entry belongs to.

Hi Kevin, Thank you

I am testing this but I think it is going to do the trick.

when CLIENT_ACCEPTED { set cid [clock clicks] }

Thanks to you, I found the documentation I had been searching for.

Writing iRules "iRules are therefore evaluated whenever an event occurs that you have specified in the iRule. For example, if an iRule includes the event declaration CLIENT_ACCEPTED, then the iRule is triggered whenever the BIG-IP system accepts a client connection. The BIG-IP system then follows the directions in the remainder of the iRule to determine the destination of the packet."

Hi Kevin, I think I found the problem in my iRule.

I have been trying to prevent further processing of the iRule if an event was found.

"To prevent further processing of an event in the current rule or other rules for the current TCP connection, you can use 'event EVENT_NAME disable'."

I have found with placing "event HTTP_REQUEST disable" before the "return", I was preventing even the CLIENT_ACCEPTED from being processed after the initial connection.

I had to code the "return" before the event was disabled.

Thank you for your assistance.

(I was using LTM Policies but you can't specify a 301 return code.)

Here is an example of a portion of the iRule I was processing that was failing.

when CLIENT_ACCEPTED {
  set cid [clock clicks]
  log local0. "\[$cid\] Troubleshooting host-Found... TCP CONNECTION!"
}


when HTTP_REQUEST {

Assign Redirect from subdomain.domain to domain_org-subdomain
log local0. "Troubleshooting host-REDIRECTS HOST [HTTP::host] PATH [HTTP::path] REFERER [HTTP::header "Referer"] "
    if {[class match [string tolower [HTTP::host]] ends_with host_org_redirects]} {
        set hostredirect [class match -value -- [HTTP::host] ends_with host_org_redirects]
log local0. "Troubleshooting host-FOUND MATCH $hostredirect"

        HTTP::respond 301 Location $hostredirect[HTTP::uri]
        PLACING THE return AFTER THE event HTTP_REQUEST disable PREVENTED THE iRule FROM BEING PROCESSED MORE THAN ONCE.
        event HTTP_REQUEST disable
        event HTTP_RESPONSE disable
        return
    }
log local0. "Troubleshooting host-REDIRECTS DONT PROCESS THIS PORTION OF THE IRULE"
}

Cory,

You want every single HTTP request to be evaluated for a destination? By using disable you are only allowing the iRule to check the very first one that matches. It will never check any subsequent HTTP requests in the same connection. The iRules execution environment is for the life of the connection, this means any and all HTTP requests that come through that TCP connection until it is closed. The way this is written, one a condition is matched, subsequent HTTP requests in the same TCP connection will no longer trigger any HTTP_REQUEST event at all. Is that what you intended?

TCP connection open
HTTP request
HTTP request (match!)
HTTP request (ignored - will not trigger any events)
HTTP request (ignored - will not trigger any events)
HTTP request (ignored - will not trigger any events)
HTTP request (ignored - will not trigger any events)
HTTP request (ignored - will not trigger any events)
TCP connection closed

Thank you for this information. Learning everyday!

Excellent, glad to help. The other thing I should have mentioned is variables use the same scope across all events for that TCP connection, so for hostredirect, it will look like this... (assumes disable commands were removed)

TCP connection open
HTTP request
HTTP request (match! hostredirect=123)
HTTP request (no match)(hostredirect=123)
HTTP request (no match)(hostredirect=123)
HTTP request (match)(hostredirect=234)
HTTP request (nomatch)(hostredirect=234)
HTTP request (nomatch)(hostredirect=234)
TCP connection closed

So be mindful that HTTP_REQUEST events can be triggering multiple times per connection and their variables may have already been set from a previous match. Even if they don't match this time around the variable may still be set that way from a previous iteration. Watch out for variable poisoning from a previous run through of your HTTP_REQUEST events.

Thank you, That is very helpful. I will be sure to review my iRules and "unset" if I need to.