On 22.05.2012 02:02, Nobuhiro Nikushi wrote:
Hi, folks.
I am using Squid 3.1.19 as a client-side cache server which is
compiled with --enable-icap-client option.
I have a problem, Squid can not finish HTTP request from browser
under
specific conditions: as follow.
- Squid is configured to forward response body to an ICAP respmod
server,
AND
- When a Web server answers content length equals 1 byte.
The following is the curl's output.
$ curl -o /dev/null -v -x 192.168.1.1:8080
http://radiant-water-7466.herokuapp.com/1
* About to connect() to proxy 192.168.1.1 port 8080
* Trying 192.168.1.1... connected
* Connected to 192.168.1.1 (192.168.1.1) port 8080
> GET http://radiant-water-7466.herokuapp.com/1 HTTP/1.1
> User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5
OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: radiant-water-7466.herokuapp.com
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 OK
< Date: Mon, 21 May 2012 13:24:54 GMT
< Content-Type: text/html;charset=utf-8
< Server: thin 1.3.1 codename Triple Espresso
< Content-Length: 1
* HTTP/1.0 connection set to keep alive!
< Connection: keep-alive
% Total % Received % Xferd Average Speed Time Time
Time Current
Dload Upload Total Spent
Left Speed
0 1 0 0 0 0 0 0 --:--:-- 0:00:20
--:--:-- 0
~~~~~
http://radiant-water-7466.herokuapp.com/1 return single char with
Content-Length: 1.
In this case, the connection should be closed by Squid, but Squid was
keeping connection.
Please notice: "Proxy-Connection: Keep-Alive" was requested by curl.
3.1 series does have a hanging problem with ICAP on 1-byte traffic but
it is not being demonstrated by the above.
no problem if content-lengh is more than 1 or if icap repomod is
disabled.
This is http://bugs.squid-cache.org/show_bug.cgi?id=3466.
You need the latest daily snapshot of 3.2 or 3.HEAD Squid to get a
fixed version. There is a patch in the bug report you are free to
use/test, we are just not confident enough about the impact on 3.1 for
it to go into stable.
Amos
