Re: [squid-users] ICAP service adaptation with service sets

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sat, 21 Apr 2012 11:39:36 +1200

On 21/04/2012 5:53 a.m., Francis Fauteux wrote:
> We are using Squid as an adaptation proxy, with a farm of ICAP RESPMOD servers running on a single host. Our (partial) configuration is thus:
>
> icap_enable on
>
> icap_service respmod_service1 respmod_precache 0 icap://<host>:<ip_1>/RESPMOD
> icap_service respmod_service2 respmod_precache 0 icap://<host>:<ip_2>/RESPMOD
>
> adaptation_service_set respmod_set respmod_service1 respmod_service2
>
> adaptation_access respmod_set allow all
>
> We would like to add an additional service to our proxy, which our current RESPMOD server would route our requests to in specific cases. If I understand the configuration guide correctly (http://www.squid-cache.org/Doc/config/icap_service/), I need to make the following changes:
>
> * Modify the RESPMOD server to inject an "X-Next-Services: new_respmod_service<n>" header to activate the new service, and inject an "X-Next-Services: " header to deactivate the new service.

Um, "activate" is a tricky word here. X-Next-Service tells Squid to use
the named service(s) on the currently processing request. It does not do
anything for other requests which "activate" implies.

>
> * Modify the squid configuration thus:
>
> icap_enable on
>
> icap_service respmod_service1 respmod_precache 0 icap://<host>:<ip_1>/RESPMOD routing=1
> icap_service respmod_service2 respmod_precache 0 icap://<host>:<ip_2>/RESPMOD routing=1
>
> icap_service new_respmod_service1 respmod_precache 0 icap://<host>:<ip_3>/RESPMOD
> icap_service new_respmod_service2 respmod_precache 0 icap://<host>:<ip_4>/RESPMOD
>
> adaptation_service_set respmod_set respmod_service1 respmod_service2
> adaptation_service_set new_respmod_set new_respmod_service1 new_respmod_service2
>
> adaptation_access respmod_set allow all
> adaptation_access new_respmod_set allow all
>
>
> Can you tell us whether this configuration is correct, and clarify the following:
>
> * Does the RESPMOD server need to inject an "X-Next-Services: " header with no value to deactivate the new service, or will it be bypassed by default?

The header is per-request. Squid starts off with a plan for doing A then
B then C filters from the squid.conf settings. X-Next-Services is an
explicit instruction to erase that plan and replace it with a new set
starting immediately.
With that I believe empty header to mean discard the old set and finish
adaptation immediately.

> * Each service has a farm of server processes for failover in case of error, but it seems the "X-Next-Services: new_respmod_server<n>" header will route to a specific service, not a service set. Is there a way to route requests to a service set or, if not, to provide failover for the new service?

Hmm. I think you just have it send back the service set name
"X-Next-Services: new_respmod_set". I'm not very familiar with the ICAP
internal specifics though.

>
> * We are using squid version 3.1.14, for which we cannot find the release notes (3.1.15 is the earliest version we found). Can you confirm that 3.1.14 supports service adaptation ?

http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.14-RELEASENOTES.html
ftp://ftp.squid-cache.org/pub/archive/3.1/
No ICAP related changes from the current latest series release notes though.

Amos
Received on Fri Apr 20 2012 - 23:39:45 MDT

This archive was generated by hypermail 2.2.0 : Mon Apr 23 2012 - 12:00:04 MDT