On 09/26/2016 10:42 AM, Yuri Voinov wrote: > 26.09.2016 22:25, Alex Rousskov пишет: >> I assume you meant that Squid should >> not send service B non-text messages at all. > And how to do it? I gave a specific example. > To adapt the chain is only one access control list. You are approaching this problem from the wrong angle: adaptation_access rules are not attached to a specific adaptation service, set, or chain. Those rules are like routing tables -- they send each message to one of the existing services, sets, or chains (the first matching rule wins). This is the same as cache_peer_access rules sending each message to a specific cache peer. More on that below. > How can I make a chain of adaptation with > different acl's for different chained services? By configuring several chains and then writing adaptation_access rules to select the right chain for a given message. >> adaptation_service_chain vegetarianChain serviceA serviceB >> >> acl messageIsText ... >> adaptation_access vegetarianChain messageIsText >> adaptation_access serviceA all > Here from this place can be a bit more detail. The above contains everything except for the messageIsText ACL definition (which I do not know). Please let me know what other details are missing... > A service > receives all of the transactions, and the service B is limited to text > answers? That is exactly what the above configuration accomplishes. Service A receives all messages because this service is present no matter which adaptation_access rule matches. Service B only receives messageIsText messages (after they are processed by Service A). >> 2. Dynamic decision inside ServiceA: > >> Modify ServiceA to emit an appropriate ICAP X-Next-Services header >> [for text messages]. Do not forget to configure ServiceA with >> routing=on! Search for X-Next-Services in squid.conf.documented. > As I understand it, there is required a modification service code, right? Yes, unless ServiceA already has some configuration options to accomplish this. > And is it possible specific example here: A specific example for dynamic routing would be service A returning an ICAP header like this: X-Next-Services: serviceB (when and only when service A wants service B to be applied next). In this case, Squid configuration becomes trivial: adaptation_access serviceA all > # routing=on|off|1|0 > # If set to 'on' or '1', the ICAP service is allowed to > # dynamically change the current message adaptation plan by > # returning a chain of services to be used next. The services > # are specified using the X-Next-Services ICAP response header > # value, formatted as a comma-separated list of service names. > # Each named service should be configured in squid.conf. Other > # services are ignored. An empty X-Next-Services value results > # in an empty plan which ends the current adaptation. > # > # Dynamic adaptation plan may cross or cover multiple supported > # vectoring points in their natural processing order. > # > # Routing is not allowed by default: the ICAP X-Next-Services > # response header is ignored. > > For me personally, this paragraph does not explain anything. I am sorry to hear that, but I cannot explain it better. Perhaps you can ask specific questions and/or others can pitch in. > we can not set > different access to services in the chain and the chain can have only > one level of access is the same for all the services within it? Yes, dynamic routing aside, Squid builds a message adaptation plan and then follows it. That plan is built at adaptation_access evaluation time. That evaluation happens once per virgin message at each vectoring point (REQMOD and RESPMOD). During that evaluation, the first adaptation_access rule wins and the winning set/chain/service becomes that adaptation plan. There are some minor caveats like "down" services and adaptation plans that span vectoring points, but I do not think they are important in this context. > Because then this assertion is contrary to the above. I do not see a contradiction. What contradicts what, exactly? Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
