Defines a single ICAP service using the following format:

	icap_service id vectoring_point uri [option ...]

	id: ID
		an opaque identifier or name which is used to direct traffic to
		this specific service. Must be unique among all adaptation
		services in squid.conf.

	vectoring_point: reqmod_precache|reqmod_postcache|respmod_precache|respmod_postcache
		This specifies at which point of transaction processing the
		ICAP service should be activated. *_postcache vectoring points
		are not yet supported.

	uri: icap://servername:port/servicepath
		ICAP server and service location.

	ICAP does not allow a single service to handle both REQMOD and RESPMOD
	transactions. Squid does not enforce that requirement. You can specify
	services with the same service_url and different vectoring_points. You
	can even specify multiple identical services as long as their
	service_names differ.

	To activate a service, use the adaptation_access directive. To group
	services, use adaptation_service_chain and adaptation_service_set.

	Service options are separated by white space. ICAP services support
	the following name=value options:

	bypass=on|off|1|0
		If set to 'on' or '1', the ICAP service is treated as
		optional. If the service cannot be reached or malfunctions,
		Squid will try to ignore any errors and process the message as
		if the service was not enabled. No all ICAP errors can be
		bypassed.  If set to 0, the ICAP service is treated as
		essential and all ICAP errors will result in an error page
		returned to the HTTP client.

		Bypass is off by default: services are treated as essential.

	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.

	ipv6=on|off
		Only has effect on split-stack systems. The default on those systems
		is to use IPv4-only connections. When set to 'on' this option will
		make Squid use IPv6-only connections to contact this ICAP service.

	on-overload=block|bypass|wait|force
		If the service Max-Connections limit has been reached, do
		one of the following for each new ICAP transaction:
		  * block:  send an HTTP error response to the client
		  * bypass: ignore the "over-connected" ICAP service
		  * wait:   wait (in a FIFO queue) for an ICAP connection slot
		  * force:  proceed, ignoring the Max-Connections limit 

		In SMP mode with N workers, each worker assumes the service
		connection limit is Max-Connections/N, even though not all
		workers may use a given service.

		The default value is "bypass" if service is bypassable,
		otherwise it is set to "wait".
		

	max-conn=number
		Use the given number as the Max-Connections limit, regardless
		of the Max-Connections value given by the service, if any.

	Older icap_service format without optional named parameters is
	deprecated but supported for backward compatibility.

Example:
icap_service svcBlocker reqmod_precache icap://icap1.mydomain.net:1344/reqmod bypass=0
icap_service svcLogger reqmod_precache icap://icap2.mydomain.net:1344/respmod routing=on