Early last year I blogged an update to the iRules HTTP event order that F5er John Alam put together. John is back with another update to the drawing, this time, however, including the access policy manager flow. This article will cover the APM events as well as a couple new standard events added back in 11.0.

APM Event Flow

There are eight events specific to the access policy manager in iRules, as well as a dozen or so commands. I’ll focus on the events in this article. Of the eight events, there are only a few events triggered per request.

  • ACCESS_ACL_ALLOWED – triggered right after HTTP_REQUEST (and before CACHE_REQUEST, not included in this drawing) for a request that has been allowed by ACLs. ACCESS checks the request for a valid session, valid policy result, and then evaluates ACLs. If ACL allows a request, it raises ACCESS_ACL_ALLOWED before releasing the request to the upper layers.
  • ACCESS_ACL_DENIED – same process as ACCESS_ACL_ALLOWED, but triggered before the request is denied (by redirecting the request to access denied page)
  • REWRITE_REQUEST_DONE – triggered right after ACCESS_ACL_ALLOWED when a portal access resource is accessed.

The other events are only triggered at some specific processing for a user’s session and access policy. For the ACCESS_POLICY_* events, even though the user’s flow is utilized, the events are triggered in the context of the APM internal request as dictated by the policy.

  • ACCESS_SESSION_STARTED – triggered right after HTTP_REQUEST (before CACHE_REQUEST) when a request is received with no SID or an invalid SID.
  • ACCESS_SESSION_CLOSED – triggered from an internal timer when session is being deleted. This is not triggered in a traffic flow context.
  • ACCESS_POLICY_COMPLETED – triggered when access policy completes.
  • ACCESS_POLICY_AGENT_EVENT – triggered when during access policy execution, and iRule event agent is executed.
  • REWRITE_RESPONSE_DONE – only triggered if REWRITE::post_process is enabled in the REWRITE_REQUEST_DONE event.

A majority of the APM flows occur on the request side, as shown below:


A little further down the processing path on the response flows is the final APM event:


Hidden Events

For APM internal URIs, like /my.policy and /my.logout, the HTTP_REQUEST/HTTP_RESPONSE events don’t fire as you would expect beginning in v11.x. The traditional method to work around this (and other module complexities) is to use the vip targeting vip configuration, where you can have a backend or frontend (or both!) virtual in which to do your iRule processing and another virtual to host the module (APM/ASM/etc). However, with APM, if you require access in your iRules to these internal URIs, you can use the ACCESS::restrict_irule_events command in the CLIENT_ACCEPTED event to expose them. An example:


    ACCESS::restrict_irule_events disable

  if { [HTTP::uri] ends_with "/my.logout.php3?errorcode=19" }{
     HTTP::redirect "/"

New Events

The plugin architecture for TMOS that APM uses results in a lost view/inspection point at the iRules level  of what exactly hits the wire when the request is released to the server or the client. However, two new events were added in v11.0 to provide these last chance inspection points, aptly named HTTP_REQUEST_RELEASE and HTTP_RESPONSE_RELEASE. On the serverside, you can now inspect what APM (or any other module) has done to the request before it hits the wire on the way to the server, and likewise, on the clientside, what APM has done to the response before it hits the wire on the way to the client.

Putting It All Together

Now that the pieces have been dissected, the diagram in its entirety should come together a little easier.



Click here for a full size pdf of the drawing.

Comments on this Article
Comment made 27-Jun-2014 by René Geile 11
In my testing on v11.4.1 HF3 it seems even without any ACL assigned always an "ACCESS_ACL_ALLOWED" is fired. This would mean the decision step "ACL defined" does not seem to exist. I checked this with logging like the following: when ACCESS_ACL_ALLOWED { log local0.info "Event fired in session [ACCESS::session sid] on URI [HTTP::uri], ACLs assigned: [ACCESS::acl lookup ] ACL matched: [ACCESS::acl matched]" } when ACCESS_ACL_DENIED { log local0.info "Event fired in session [ACCESS::session sid] on URI [HTTP::uri], ACLs assigned: [ACCESS::acl lookup ] ACL matched: [ACCESS::acl matched]" }
Comment made 13-Nov-2014 by Walter Kacynski 922
I have come to the same conclusion in my testing.
Comment made 10-Feb-2016 by Walter Kacynski 922
Where does the HTML_TAG_MATCHED event fall within this diagram?
Comment made 03-Jun-2016 by MAG 15
Hi, Looks like summary diagram has mistake."Connection Keepalive" "Yes" decision must be directed to decision "Valid HTTP request", not to EVENT "HTTP_REQUEST"?
Comment made 18-Oct-2016 by AlgebraicMirror 403

One thing this doesn't cover is APM's clientless mode. When in clientless mode, you don't do redirects to my.policy, which means the event flow would be much different than the picture above (the picture above shows you hitting ACCESS_SESSION_STARTED, then responding to the client, and you don't even start the VPE until the second request).

How exactly do the events flow when clientless mode is set?

Comment made 3 months ago by Stanislas Piron 4856

Hi Jason,

It's really a great drawing which helped me to understand how APM work and to write my own irules.

I have some comments about it :

  1. ACCESS_ACL_DENIED doesn't lead to Respond with session terminaison page but to Respond with denial page
  2. I don't understand VPE Allow condition. If VPE is not allowed after ACCESS_POLICY_COMPLETED, session is removed so this condition is always true as only valid session are going there.
  3. As René already said, ACL Defined and Evaluate ACL must be merge into one with Denied by ACL, if not denied, ACCESS_ACL_ALLOWED is evaluated even if no ACL is defined.
  4. ACCESS_POLICY_AGENT_EVENT may loop to VPE calls irule Event as VPE can raise this event multiple times
  5. ACCESS_SESSION_CLOSED is triggered outside of flow context. it doesn't lead to Respond with session terminaison page
  6. if Valid existing session and URI equals APM logout URI (/vdesk/hangup.php3 or /vdesk/my.logout.php3) --> leads to ACCESS_SESSION_CLOSED

Do you agree with these comments? If I am right, is it possible to update the drawing?