Your ICAP server is not responding properly. The ICAP request is correct.
The ICAP server is specifying Preview: 0 in the OPTIONS command.
When MWG is honoring that by sending the preview with a 0 byte body in the response body terminated by \r\n0\r\n
The ICAP server is supposed to respond with ICAP/1.0 100 Continue in order to receive the remaining data. There are still 68 bytes left to send.
The correct conversation should look like this:
RESPMOD icap://192.168.2.23:1344/respmod ICAP/1.0
Encapsulated: req-hdr=0, res-hdr=413, res-body=719
GET http://www.eicar.org/download/eicar.com.txt HTTP/1.1
Accept-Encoding: gzip, deflate
HTTP/1.1 200 OK
Date: Tue, 29 Dec 2015 14:58:34 GMT
X-Cache: MISS from 192.168.2.231
Keep-Alive: timeout=15, max=100
Content-disposition: attachment; filename="eicar.com.txt"
ICAP/1.0 100 Continue
ICAP/1.0 200 OK
Encapsulated: res-hdr=0, res-body=38
(ICAP Response Headers)
HTTP/1.0 430 Blocked
(HTTP Response Body)
The ICAP server is prematurely terminating the session based on thinking that \r\n0\r\n is the end of the entire request, which it is not. The Content-length needs to finish sending.
If you can get the ICAP server to send a larger value in the preview response on the OPTIONS command (like 256 bytes), you will see the entire body coming though in the preview and see the blocked response. However, that is not a long term solution. The ICAP server has to correctly conform to the protocol in order to work properly.
Thanks for replying.
As you said, the problem was handling preview icap request.
I asked this issue to AV scanner's vendor.
So.. thank you for helping me.
Happy new year!