Tab – ICAP

ICAP services are defined on the Network Services page. Handlers to ICAP services are defined on mappings and can be hooked in at different points of view:

  • ICAP Request Client View: Requests are handled after they have been filtered (e.g. the allow rules and the deny rules have already been applied), but before evaluating client fingerprinting. At this point, configured request rewrites have not been applied yet.
  • ICAP Request Back-end View: Requests are handled just before they are sent to the back-end server. At this point, all configured request rewrites were already applied to the request.
  • ICAP Response Back-end View: Responses are handled just after they were returned from the back-end servers. At this point, configured response rewrites (including URL encryption) have not been applied yet.
  • ICAP Response Client View: Responses are handled just before they are sent to the client. At this point, configured response rewrites (including URL encryption) were already applied.

Multiple ICAP handlers can be defined for each point of view. For each point of view, handlers are processed in the order of definition, i.e., the first entry in the table is the first to be processed. One of the ICAP service entries configured on the Network Services page must be selected for each handler. Additional conditions for URL patterns, HTTP methods or HTTP headers allow selective handling of certain requests/responses.

Examples for ICAP handler conditions

  • All requests to a certain server:
  • URL Pattern – can be left blank if all requests should be processed via ICAP.
    Example pattern: ^https?://server.intra.net
  • All requests to the /download directory:
  • URL Pattern: – ^/download/
  • Only requests with HTTP methods GET or POST:
  • HTTP Method Pattern – ^(GET|POST)$
  • Only responses with an X-Header and value myApp:
  • Response Header Name Pattern – ^X-Header$
  • Response Header Value Pattern – ^myApp$