Appendix E: Filter File Syntax
303
•protocol=value—An optional protocol= condition expression. Available values are http,
https, ftp, mms, rtsp, tcp, aol-im, msn-im, or yahoo-im. For details, see "url=" on page137.
•property=value—An optional property setting. For a list of properties available in filter files, see
Table1, “Properties available in CacheOS 4.x filter files,” on page 301.
Access-Control List (ACL) Definitions
The only definition appearing in the filter part of a filter file is the define acl definition block, which
defines access-control lists. It does this by binding a user-defined label to a set of IP addresses or IP
subnet patterns. This label can then be used in an acl= expression on a filter line.
This definition block has the same syntax and semantics as a CPL define subnet definition block,
except that the keyword subnet is replaced by the keyword acl. The IP addresses or subnets are
considered to have a Boolean OR relationship, no matter whether they are all on one line or separate
lines. The syntax for the define acl definition block is as follows:
define acl label
{ip_address|subnet} {ip_address|subnet}...
...
end acl label
where:
•label—A user-defined identifier for this subnet definition.
•ip_address—IP address; for example, 10.1.198.0.
•subnet—Subnet specification; for example, 10.25.198.0/16.
Sections
Filter files support three kinds of sections:
• Prefix sections, for prefix-pattern filters (CPL equivalent: [url]).
• Domain-suffix sections, for domain-suffix filters (CPL equivalent: [url.domain]).
• Regular-expression sections, for regular-expression filters (CPL equivalent: [url.regex]).
A section within a filter file is similar to the equivalent section that appears in a standard CPL policy
file; however, filter-file sections do not support guard expressions, and they cannot include [Rule]
sections.
The appearance of a section header within a filter file indicates that all subsequent filter entries are to
be interpreted as specified within the section header. In addition, sections may contain ALL
statements and define acl definition blocks, but these do not affect the semantics of the section or the
way in which the ALL statement and definitions are evaluated.
Note that in the absence of filter section headers, filters are considered to be prefix filters unless they
contain one or more regular expression metacharacters. If a filter entry does contain regular expression
metacharacters, it is considered to be a regular expression. If section headers are used, the ProxySG
automatically checks to ensure that regular expression filter entries only appear within the
[Regular-Expression] filter section.
Prefix Sections