> The default flow is REQ_ICAP1->REQ_ICAP2->RESP_ICAP1->RESP_ICAP2
> using the dynamic routing i'm able to skip REQ_ICAP2 (by setting
> X-Next-Services to 'RESP_ICAP1, RESP_ICAP2')
> I'm also able to skip RESP_ICAP1 (by setting X-Next-Services to RESP_ICAP2')
> What i didn't manage to do is to stop adaption completely by returning
> an empty value for X-Next-Services
> According to the documentation: "An empty X-Next-Services value results
> in an empty plan which ends the current adaptation."
> So i'm not sure what am i missing. Maybe with empty value it simply
> skips to the response chain?
If that is what happens, then it is probably a Squid bug. AFAICT, an
empty plan returned by a routing REQMOD service should prevent RESPMOD
adaptation by design -- a routing service is supposed to have full
I checked the code that processes X-Next-Services and did not notice any
red flags, but the bug may be located deeper in the code, where Squid
reacts to the remaining adaptation plan. I suspect somewhere an empty
plan is misinterpreted as no plan.
If the bug is confirmed, we may have to preserve it for backward
compatibility sake and add two special X-Next-Services values (e.g.,
"END_ADAPTATION" and "JUMP_TO_RESPMOD") to allow updated services to
distinguish the two use cases instead of returning an empty list with an
arguably ambiguous meaning.
> Should i use the adaptations in a different configuration?
Ideally, the bug should be confirmed and fixed. If you cannot
(facilitate a) fix, then you may be able to work around the bug using
service-set annotations and adaptation_access directives (for all or
just the buggy cases). Unfortunately, I do not remember whether Squid
supports setting transaction annotations using ICAP services. IIRC,
Squid supports that for eCAP services.