Blue Coat Systems Time Clock Proxy SG Manual De Usuario
Chapter 1: Overview of Content Policy Language
21
For new ProxySG appliances, the default is to deny all requests. For ProxySG appliances being
upgraded from 4.x, the default is to allow all requests. In either case, the ProxySG can be
configured for either default. The default setting is displayed in policy listings.
upgraded from 4.x, the default is to allow all requests. In either case, the ProxySG can be
configured for either default. The default setting is displayed in policy listings.
The proper approach to writing
<proxy>
layer policy depends on whether or not the default is to
allow or deny requests. The default proxy policy is configurable and represents the starting point for
writing policy to control proxy transactions. The default proxy policy is reported at the top of every
policy listing generated by the ProxySG.
writing policy to control proxy transactions. The default proxy policy is reported at the top of every
policy listing generated by the ProxySG.
; Default proxy policy is DENY
That line in a policy listing is a CPL comment, defining the starting point for proxy policy.
Role of CPL
CPL is the language used to express policy that depends on the runtime evaluation of each
transaction. Policy is written in CPL, installed on the ProxySG, and is evaluated during request
processing to override any default decisions taken from configuration.
transaction. Policy is written in CPL, installed on the ProxySG, and is evaluated during request
processing to override any default decisions taken from configuration.
CPL Language Basics
The following sections provide an overview of the CPL language. In order to concentrate on higher
level themes, CPL elements are informally introduced and discussed. Detailed specifications for each
of these elements is left to the reference portion of this manual.
level themes, CPL elements are informally introduced and discussed. Detailed specifications for each
of these elements is left to the reference portion of this manual.
Comments
Any line starting with ‘
;
’ is a comment.
A semicolon (
;
) following a space or tab introduces a comment that extends to the end of the line
(except where the semicolon appears inside quotes as part of a trigger pattern expression or property
setting).
setting).
For example:
; This is a comment.
Comments can appear anywhere in policy.
Rules
A policy rule consists of a condition and some number of property settings, written in any order. Rules
are generally written on a single line, but can be split across lines using a special line continuation
character. When a rule is evaluated, the condition is tested for that particular transaction. If the
condition evaluates to True, then all of the listed property settings are executed and evaluation of the
current layer ends. The rule is said to match. If the condition evaluates to False for that transaction, it is
said to miss.
are generally written on a single line, but can be split across lines using a special line continuation
character. When a rule is evaluated, the condition is tested for that particular transaction. If the
condition evaluates to True, then all of the listed property settings are executed and evaluation of the
current layer ends. The rule is said to match. If the condition evaluates to False for that transaction, it is
said to miss.
In turn, a condition is a boolean combination of trigger expressions. Triggers are individual tests that
can be made against components of the request (
can be made against components of the request (
url=
), response (
response.header.Content-Type=
),
related user (
user=
,
group=
), or system state (
time=
).