Hi there, Handling of multiple ICAP services in Squid3 does not match squid.conf expectations well. Here is a brief summary of the current state, with Squid2 comparison:
load balancing (using similar services in a round-robin): Squid2: via multiple identically named icap_service options Squid3: not documented and not supported. backup (using another service when a similar service is down): Squid2: via multiple identically named icap_service options Squid3: not documented but supported via icap_class option chaining (applying one service after another): Squid2: via icap_class option Squid3: semi-documented but not supported I believe that using multiple identically named icap_service options is a bad interface. Each service should have its own name for configuration clarity, reporting, debugging, and such. The way chaining is explained in squid3.conf will confuse many users. The name of the option (icap_class) does not imply chaining either. Many users will think that icap_class is about backup, not chaining. In fact, the original Squid3 implementation was using icap_class for something resembling backup, not chaining. I would like to polish this for Squid3 STABLE release, but since my proposal requires changing squid.conf option names, I do not want to do it without your feedback. Here is what I would like to do: service naming: Each service must have a unique name. load balancing and backup: Add icap_service_set option. Services (or service chains) listed under this option are load balanced and "down" entries are skipped. chaining: Rename icap_class into icap_service_chain option. Services (or service sets) listed under this option are applied one after another. Any objections or better ideas? Thank you, Alex. P.S. I am not going to implement load balancing and chaining in Squid3 until somebody needs it enough, but the configuration will be cleaned up and ready for that implementation. The backup code is already done.