Filter
Top Products
Chapter 2: Managing Content Policy Language
47
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.