ProxySG policy order does not guarantee the order of evaluation


Article ID: 171404


Updated On:


ProxySG Software - SGOS


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, then it gets authenticated and then the same user make another request going to 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
     exception(content_filter_denied, "bad content")

define proxy policy p2
     deny("policy denied")


   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:

define proxy policy exceptionP1P2
     Condition=condition1 exception(content_filter_denied, "bad content")

     deny("policy denied")


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.