HTTP Event Order -- Access Policy Manager

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 a plethora of events and commands specific to the access policy manager in iRules, which you can find here on Clouddocs. 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.


Drawing: BIGIP_Events_Visio.pdf


Published Jun 26, 2012
Version 1.0

Was this article helpful?


  • 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 "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 "Event fired in session [ACCESS::session sid] on URI [HTTP::uri], ACLs assigned: [ACCESS::acl lookup ] ACL matched: [ACCESS::acl matched]" }
  • Hi, Looks like summary diagram has mistake."Connection Keepalive" "Yes" decision must be directed to decision "Valid HTTP request", not to EVENT "HTTP_REQUEST"?
  • 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?


  • 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
      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?

  • I am working on some updates for this. Jason, can I get the VSD so I don't have to draw from scratch?


  • i fixed the article links. I don't have the source visio, but I'll follow up with the author to see if there is an update to this file.