On tor, 2007-09-27 at 12:08 +1200, Amos Jeffries wrote:
icap_class even says If there are multiple services per vectoring point,
they are processed in the specified order.
Yes.. config syntax already supports it, just never gets called..
Regards
Henrik
signature.asc
Description: This is a
On Thu, 2007-09-27 at 12:08 +1200, Amos Jeffries wrote:
icap_class even says If there are multiple services per vectoring
point, they are processed in the specified order.
Not any more. We now also warn if multiple services are configured per
class. Despite the warning, we still allow a
On ons, 2007-09-26 at 11:53 +1200, Amos Jeffries wrote:
It occurs to me that a method superficially similar to that used for
cache_peer could look nice here.
- define icap_service with specific details, options +name on a single line
- define icap_access name acl ...
Isn't that what is
On ons, 2007-09-26 at 11:53 +1200, Amos Jeffries wrote:
It occurs to me that a method superficially similar to that used for
cache_peer could look nice here.
- define icap_service with specific details, options +name on a single
line
- define icap_access name acl ...
Isn't that what is
Alex,
Firstly, please disregard some of what I said in my previous email. Having had
another good look over the code I've identified that I did make some mistakes
in my interpretations. The statement posted on the 3.x developer guide - The
code is often difficult to follow because there are
On Tue, 2007-09-25 at 13:08 -0400, Richard Bishop wrote:
Between sending email my and receiving your I have been having a play
around with this idea. I've gotten to the point where I have multiple
ICAP services being processed for REQMOD methods
Glad you made it work for your needs!
though
On Tue, 2007-09-25 at 13:08 -0400, Richard Bishop wrote:
I would suggest that there should be an option to bypass particular
services based on the results of earlier services - i.e. values of
ICAP headers returned in the response. In the case of multiple
chained virus scanners, this would
On Wed, 2007-09-19 at 17:02 -0400, Richard Bishop wrote:
As far as I can see, all ICAP transactions themselves (once we have
indentified a suitable service from the candidates in squid.conf) are
fired as asynchronous events. Events are then fired in the order they
are pushed onto the events
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
