Squid Web Cache wiki

Squid Web Cache documentation

🔗 Feature: ICAP (Internet Content Adaptation Protocol)

🔗 Background

Internet Content Adaptation Protocol (RFC 3507, subject to errata) specifies how an HTTP proxy (an ICAP client) can outsource content adaptation to an external ICAP server. Most popular proxies, including Squid, support ICAP. If your adaptation algorithm resides in an ICAP server, it will be able to work in a variety of environments and will not depend on a single proxy project or vendor. No proxy code modifications are necessary for most content adaptations using ICAP.

One proxy may access many ICAP servers, and one ICAP server may be accessed by many proxies. An ICAP server may reside on the same physical machine as Squid or run on a remote host. Depending on configuration and context, some ICAP failures can be bypassed, making them invisible to proxy end-users.

🔗 ICAP Servers

While writing yet another ICAP server from scratch is always a possibility, the following ICAP servers can be modified to support the adaptations you need. Some ICAP servers even accept custom adaptation modules or plugins.

The above list is not comprehensive and is not meant as an endorsement. Any ICAP server will have unique set of pros and cons in the context of your adaptation project.

More information about ICAP is available on the ICAP Forum.

🔗 Squid Details

Squid-3.0 and later come with integrated ICAP support. Pre-cache REQMOD and RESPMOD vectoring points are supported, including request satisfaction. Squid-2 has limited ICAP support via a set of poorly maintained and very buggy patches. It is worth noting that the Squid developers no longer officially support the Squid-2 ICAP work.

Squid supports receiving 204 (no modification) responses from ICAP servers. This is typically used when the server wants to perform no modifications on a HTTP message. It is useful to save bandwidth by preventing the server from sending the HTTP message back to Squid as it was received. There are two situations however where Squid will not accept a 204 response:

The reason for this is simple: If the server is to respond to Squid with a 204, Squid needs to maintain a copy of the original HTTP message in memory. These two basic requirements are a basic optimisation to limit Squid’s memory usage in supporting 204s.

🔗 Squid Configuration

:bulb: ICAP server configuration should be detailed in the server documentation. Squid is expected to work with any of them. :information_source: The configuration of Squid-3 underwent a change between Squid-3.0 and Squid-3.1

🔗 Squid 3.1

The following example instructs Squid-3.1 to talk to two ICAP services, one for request and one for response adaptation:

icap_enable on

icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/request
adaptation_access service_req allow all

icap_service service_resp respmod_precache bypass=0 icap://127.0.0.1:1344/response
adaptation_access service_resp allow all

🔗 Squid 3.0

The following example instructs Squid-3.0 to talk to two ICAP services, one for request and one for response adaptation:

icap_enable on

icap_service service_req reqmod_precache 1 icap://127.0.0.1:1344/request
icap_class class_req service_req
icap_access class_req allow all

icap_service service_resp respmod_precache 0 icap://127.0.0.1:1344/response
icap_class class_resp service_resp
icap_access class_resp allow all

There are other options which can control various aspects of ICAP:

Categories: Feature

Navigation: Site Search, Site Pages, Categories, 🔼 go up