Blue Coat Systems Proxy SG manual Avoid Conflicting Actions

Chapter 2: Managing Content Policy Language

evaluation order as currently configured. Changes to the policy file evaluation order must be managed with great care.

Remember that properties maintain any setting unless overridden later in the file, so you could implement general policy in early layers by setting a wide number of properties, and then use a later layer to override selected properties.

Avoid Conflicting Actions

Although policy rules within a policy file can set the action property repeatedly, turning individual actions on and off for the transaction being processed, the specific actions can conflict.

•If an action-definition block contains two conflicting actions, a compile-time error results. This conflict would happen if, for example, the action definition consisted of two response.icap_service( ) actions.

•If two different action definitions are executed and they contain conflicting actions, it is a run-time error; a policy error is logged to the event log, and one action is arbitrarily chosen to execute.

The following describes the potential for conflict between various actions:

•Two header modification actions will conflict if they modify the same header. Header modification actions include the append( ), delete( ), delete_matching( ), rewrite(header,...), and set(header,...) actions.

•Two instant message text modification actions will conflict. Instant message text modification actions include the append(im.message.text,...) and set(im.message.text,...) actions.

•Two transform actions of the same type conflict.

•Two rewrite( ) actions conflict.

•Two response.icap_service( ) actions conflict.

Making Policy Definitive

You can make policy definitive two ways. The first is to put that policy into the file; that is, last in the evaluation order. (Remember that the forward file is always the last policy file.) For example, suppose that service was limited to the corporate users identifiable by subnet. Placing a rule such as:

<Proxy> client.address=!my_subnet deny

at the end of the Forward file ensures that no other policy overrides this restriction through accidental use of allow. Although not usually used for this purpose, the fact that the forward file is always last, and the order of the other three files is configurable, makes this the appropriate location for definitive policy in some organizations.

An alternate method has been provided for definitive denial. While a deny or an exception() property can be overridden by a subsequent allow in later rules, CPL provides force_deny and force_exception(). CPL does not offer force_allow, so while the error returned to the user may be reset by subsequent force_deny or force_exception() gestures, the ultimate effect is that the request is denied. Thus these properties provide definitive denial regardless of where they appear in policy.

47