icap-server, test-icap — ICAP server for document inspection
icap-server [-hv] [-d ] debuglev-f cfgfile
test-icap [-hv] [-d ] debuglev-f [cfgfile-r] [-t ]test_expr
The icap-server is a server of the Internet Content Adaptation Protocol (RFC 3507) implementing the security policy for the access control and the document inspection based on the Kernun configuration logic.
The test-icap program checks the syntax and partially the semantics of the configuration; for test expression syntax, see test-expr(5).
The server reads its configuration and starts listening on TCP
sockets (address/port couples) specified by listen-on
configuration section, see listen-on(5).
Format of the configuration file is described in icap-server.cfg(5). General syntax of Kernun configuration files is explained in configuration(7).
The icap-server uses standard Kernun access control (see access-control(7)) with four types of ACLs on three levels:
session-acl (level 1) is checked
once for each client connection and defines general protocol
behavior, or rejecting the connection. In addition to the
generic ACL conditions and actions,
some icap-server-specific
conditions and parameters can be set (see icap-server(5)).
service-acl (level 2I) is checked once
for each ICAP request received and defines the service(s)
and attributes used for the request.
All entry conditions of this level are related
to the ICAP request line and ICAP headers.
Accepting ACLs cause 2xx ICAP response codes
while denying ACLs cause 4xx and 5xx codes.
request-acl (level 2H) is checked once
for each encapsulated (HTTP) request and/or document inspected
and defines the behavior variation
according to the HTTP request URI.
All entry conditions of this level are related
to the encapsulated HTTP request line,
or client data sent by special ICAP headers
X-Client-IP and X-Client-Username.
doc-acl (level 3) is checked once
for each encapsulated (HTTP) document inspected and defines
document processing mode (e.g. document type identification,
filtering, replacing etc.).
Firewall administrator can choose any method described in auth(7) (except for NTLM) for authenticating users on the proxy.
The recognized file type (see doctype-identification(7)) is returned to the client via the ICAP response header (“X-Kernun-Content-Type”).
In the case of request/document allowed by the policy
and processed without any modification,
the Kernun icap-server can return either
the 200 response code (together with the original document)
or the 204 response code (without data,
if client permits it by the Allow header).
In the case of request/document refused by the policy (e.g. due to HTTP request attributes, file extension, recognized file type, virus found etc.), the ICAP response code has value 201 and either a standard or an own error web page is returned.
The “Preview” mode is supported.
In this case, the client sends only a part of the document
to the server, the server makes a decision and responds
by the 100 Continue, or some error response.
After the 100 Continue response, the client
continues sending the rest of the document.
The size of the preview block is recommended by the server
to the client via the OPTIONS request response
according to the services (antivirus, doctype recognition etc.)
offered by corresponding service-acl.
The admin can force another recommendation
by the preview item.
-hPrint usage information.
-vDisplay version information and exit.
-f cfgfileRead cfgfile
for configuration information.
-rResolve names in configuration prior to testing.
-t test_exprTest configuration according to given expression.
Format of the
test_expr is described in test-expr(5).
listen-on(5), mod-antivirus(5), mod-html-filter(5), proxy(5), icap-server(5), icap-server.cfg(5), ssl(5), tcpserver(5), test-expr(5), access-control(7), configuration(7), doctype-identification(7), host-matching(7), logging(7), netio(7), resolving(7), tcpserver(7), time-matching(7), traffic-shaping(7)