There is a transaction that matches rules in multiple layers that trigger custom exceptions. Instead of the exception page defined in the last matched rule being displayed, the exception page in the first rule is displayed.
When a transaction matches multiple rules that set the same property, doesn't the property defined on the last matched rule prevail? This does not seem to be the case.
The order of policy evaluation depends on the condition timing that guards the rule. So it does not matter on how many times the policy has been evaluated.
For example, if there is an authentication rule getting involved, all the transactions will go through the same policy evaluation regardless of whether the transaction had been authenticated or not.
Note: the situation described above is a case with exception pages, the issue is not specific to exception page only, it could be caused by other type of objects as well like not matching an ICAP scanning, etc.
For example, user goes to www.abc.com/object1, then it gets authenticated and then the same user make another request going to www.abc.com/object2 which already gets authenticated. So both the requests will still go through the same set of policy evaluations, in our example here, both requests will be evaluated with policy P1 and P2 which end up, P1 will be evaluated later and it gets applied.
So it depends on the timing of the rule or policy been evaluated especially if those policies are in a different policy definition. For example, P1 and P2 are in a different policy definition and been called in a different ‘proxy’ layers, so there is a timing involved here when it gets to which policy been evaluated first or later.
define proxy policy p1 <proxy> exception(content_filter_denied, "bad content") end
define proxy policy p2 <proxy> deny("policy denied") end
<proxy> user=!guest policy.p1
If desired to make sure that P2 will be always evaluated later and gets applied, here is an example recommended by engineering using the same example above:
So in the example above, the two polices – P1 and P2 are in the same policy definition and in separate ‘proxy’ layers but the outcome is different. Assuming the user matched ‘condition1’, the outcome will be the user will get ‘policy denied’ (P2) been applied to the user transaction instead of P1.
Subscribing will provide email updates when this Article is updated. Login is required.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
Subscribed to the Article.
Unable to subscribe
Thanks for your additional feedback !!!
Enterprise Support Virtual Agent
Rate Me :
Tell us more:
Welcome! My name is Sami, the Enterprise Support Virtual Agent answering technical support questions.