Hi guys, I may have found a bug related to the ICAP capabilities of Squid 3.1.1 (on RHEL5.4). We are currently evaluating a squid deployment which is referenced by this url [1]. We want to use Squid as Caching/Authentication-Proxy and ICAP Client, which talks to the Webwasher-server (content filtering proxy) via ICAP. Our Squid has following ICAP configuration: #icap icap_enable on icap_send_client_ip on icap_send_client_username on icap_preview_enable on icap_preview_size 30 icap_client_username_encode on icap_client_username_header X-Authenticated-User icap_service service_req reqmod_precache bypass=0 icap://yyy.yyy.yyy.21:1344/wwreqmod adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=0 icap://yyy.yyy.yyy.21:1344/wwrespmod adaptation_access service_resp allow all (Unfortunately, we can only specify one ICAP server per Squid, but that's another issue/limitation) This deployment is supported by McAfee (Webwasher) and there is even an example configuration[2] for squid and documents for configuring the webwasher by McAfee. ICAP reqmod looks good, everything as expected: Host: yyy.yyy.yyy.21:1344 Date: Mon, 12 Apr 2010 10:54:27 GMT Proxy-Authorization: NTLM <BASE64 STRING> Encapsulated: req-hdr=0, null-body=184 Preview: 0 Allow: 204 X-Client-IP: bbb.bbb.bbb.71 X-Authenticated-User: <BASE64 encoded USERNAME> GET / HTTP/1.1 Host: www.playboy.com Accept: text/html, text/plain ICAP/1.0 200 OK Encapsulated: res-hdr=0, res-body=170 ISTAG: "001-000-000003" X-Attribute: sx X-ICAP-Profile: PoC_Policy_TEST X-WWBlockResult: 10 X-WWRepScore: 11 HTTP/1.1 403 Forbidden Content-Length: 1480 Content-Type: text/html; charset=ISO-8859-1 Pragma: no-cache Proxy-Connection: close X-Error-Name: requestdynablocked In that case we were assigned to PoC_Policy_TEST and the request to www.playboy.com was blocked. (It seems that we are not supposed to see nice girls at work ;-)) If we want to serve to a page which is not blocked (e.g. google.com), we get following request: ICAP/1.0 200 OK Encapsulated: res-hdr=0, res-body=166 ISTAG: "001-000-000003" X-ICAP-Profile: default X-WWBlockResult: 81 X-WWRepScore: 0 HTTP/1.1 403 Forbidden Content-Length: 1279 Content-Type: text/html; charset=ISO-8859-1 Pragma: no-cache Proxy-Connection: close X-Error-Name: authorizedonly And there is the problem. The ICAP respmod (3.1.1) request does NOT contain the X-Client-IP: bbb.bbb.bbb.71 and X-Authenticated-User: <BASE64 encoded USERNAME> values and that's why the webwasher cannot assign the right policy! If we are using squid 3.0, it works. So in my opinion, this sound like a bug. Right? Has anyboy experiences with ICAP or ICAP issues with Squid 3.1.1? Anyway, besides that problem which I solved by using squid 3.0, there are a couple of other limitation which I don't really want to implement, but I don't see any other change, do you? ;-) At least it does not sound very complicated to implement in c++ ... - possibility to specify more than one ICAP server for a Squid configuration (for example with round robin load balancing or any other kind of loadbalancing) - the much bigger issue is, that Squid as ICAP client does NOT send any group information to the ICAP server, only X-Client-IP and X-Authenticated-User values and no X-Authenticated-Groups attribute. Unfortunately, a policy will be assigned by a group membership. That's why the ICAP server needs that information and it is not a good idea to let the ICAP server lookup this user again (huge performance issue). So, this is quite a long mail, I would appreciate any feedback. best regards Peter [1] http://img714.imageshack.us/img714/7457/topology.png [2] http://wiki.squid-cache.org/ConfigExamples/Webwasher (they are using a proxy chain instead of a icap solution)
