ACCESS::policy result in APM/LTM 11.4

I can't speak for any changes that might relate to this, but using the HTTP_REQUEST event in an APM session can sometimes lead to ambiguity. You could more succinctly insert your code into the middle of the access session by inserting an iRule agent in the visual policy (where you want to do the work), and then add your iRule code in the ACCESS_POLICY_AGENT_EVENT event. If you have multiple points in the access evaluation process that you'd like to insert iRule code, give each iRule agent a different ID value and do something like this in code:

when ACCESS_POLICY_AGENT_EVENT {
    switch [ACCESS::policy agent_id] {
        "before_ad_id" {
             do something
        }
        "after_ad_id" {
             do something else
        }
    }
}

where "before_ad_id" and "after_ad_id" are arbitrary ID names in the iRule agent objects.

I am not sure why this worked in 11.3, but by default HTTP_REQUEST does NOT trigger on the requests that go to the Access Policy engine As such, the very first request that comes in(unauthenticated, presumably), will properly return status of "not_started". What exactly are you trying to do? If you provide a bit more detail, we can certainly try to help steer you towards the proper implementation.

If you truly wanted to interfer with logic within Access Policy execution, then you'd need to enter this event:

when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable }

This will allow HTTP_REQUEST even to fire on all requests - even during Access Policy execution.

Thank you all for your suggestions. However in the if statement also checks for HTTP::cookie exists and ACCESS::session data get and the HTTP:cookie exists cannot be called from the ACCESS_POLICY_AGENT_EVENT.

The ACCESS_POLICY_AGENT_EVENT event is intended to work mid-policy evaluation, which by logic means the cookie exists (you're already in the access session), and that the session table exists and can be queried. In other words, you don't need to check for the cookie because you know it exists if you've triggered this event. And because you've triggered this event in a specific point of the visual policy path, you have relative certainty that the session variable you need also exists.

This method is much easier than having to check if the session exists in the HTTP_REQUEST event.