ICAP Response of Content Length 1 is stuck on Ubuntu 12.04 LTS’s default Squid 3.1.19

UPDATE: see Squid bug concerning this issue – http://bugs.squid-cache.org/show_bug.cgi?id=3466.

Problem: one of our users reported a never loading web site. Access to the web was managed by Squid installed on Ubuntu Linux 12.04 and integrated with QuintoLabs Content Security performing filtering of the web traffic. The screen of a browser just went blank, status page indicated that browser waits for a resource from hello.myfonts.net (both Firefox and IE were affected).

Reason: after a long debugging session we found out that the ICAP RESPMOD message from Squid asking to adapt the contents of the HTTP response looks a little bit strange.

RESPMOD icap://192.168.178.15:1344/respmod ICAP/1.0
Host: 192.168.178.15:1344
Date: Wed, 21 Aug 2013 07:33:45 GMT
Encapsulated: req-hdr=0, res-hdr=117, res-body=320
Preview: 1
Allow: 204
X-Client-IP: 192.168.178.15

GET http://hello.myfonts.net/count/26d951 HTTP/1.0
User-Agent: Mozilla/5.0
Accept: */*
Host: hello.myfonts.net

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: text/css
Date: Wed, 21 Aug 2013 07:33:43 GMT
Expires: Wed, 21 Aug 2013 07:33:43 GMT
Pragma: no-cache
Server: nginx/1.3.6
Content-Length: 1

1

0; ieof

Nevertheless, it is a legal response so qlproxy scans it as usual, finds nothing and just responds with the following.

ICAP/1.0 204 No Content
ISTAG: "5BDEEEA9-12E4-2"
Encapsulated: null-body=0

After that Squid seems to be stuck in an infinite loop waiting for something forever and as Squid does not send anything to the browser, it continues waiting forever too. On the other hand – if you disable ICAP RESPMOD filtering, everything starts to work normally.

What is worse, the same issue appears on all sites that reference hello.myfonts.net, even on the http://www.myfonts.com itself. We are not sure if we are the problem for this because the response qlproxy gives back to Squid is a usual response for such ICAP messages – just simple 204 Not interesting. It is used quite a lot (almost 90%) of all responses are served with this response, so we might need to go deeper into Squid sources to understand the issue.

For now the solution is NOT to pass the response from hello.myfonts.net to qlproxy like this (assuming your qlproxy RESPMOD filtering service is called qlproxy_2 in squid.conf):

# due to problems with Squid + ICAP for myfonts.net we do NOT pass responses from myfonts.net to ICAP server
acl myfonts_net dstdomain hello.myfonts.net
adaptation_access qlproxy2 deny myfonts_net
adaptation_access qlproxy2 allow all

Restart your Squid and everything is back online again!

Thanks!
Diladele B.V. Team

About sichent

sichent
This entry was posted in Diladele, ICAP, Linux, proxy, qlproxy, squid. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s