Re: [squid-users] ICAP failure when using clamav scan denied reply

On 1/08/2013 9:24 p.m., John Xue wrote:
> I am using squid 3.2.3
> + http://www.squid-cache.org/Versions/v3/3.2/changesets/squid-3.2-11699.patch(Polish:
> replace several assert(isOpen(fd)))
> + c-icap 0.1.7
> + squidclamav 6.9
> + squidGuard 1.4
>
> as default I deny all application/octet-stream reply access, and
> disable virus scan picture ^.*\.(ico|gif|png|jpg)$ in squidclamav.

NP: it would be a better idea to setup an ACL so that those disabled
replies are not even sent to the ICAP scanner. Particularly if the
problem is an overloaded scanner. It will save you a lot of I/O
buffering and parsing work in Squid along with similar resource
consumptions and CPU cycles in the scanner.

> my problem is when user try to access a link that end of .gif but
> reply content type is application/octet-stream, c-icap will store that
> content to /var/tmp and keep it, then die in icap process, even I
> reload icap.

<snip>

> my squid log
> 1375345064.448 6471 1.1.2.3 TCP_DENIED_REPLY/403 9044 GET
> http://bbs.chinaacc.com/getresource.php?thumb=1&rid=104959 user_Name
> FIRSTUP_PARENT/1.1.2.2 text/html

NOTE: The above request URL does not contain any match for
^.*\.(ico|gif|png|jpg)$

> firebug report:
>
> GET getresource.php?thumb=1&rid=104959 200 OK bbs.chinaacc.com
> 3.7 MB 1.1.2.2:8000 8.43s
> ParamsHeadersResponseCookies
> Response Headersview source
> Connection keep-alive
> Content-Disposition inline; filename="62037b5agw1droqc7t0qeg.gif"

Is this what you are looking at when you call it a .gif? This is the
content disposition. It is simply a hint for what the browser is to call
the file if it were being saved to a file.

> Content-Encoding none
> Content-Length 3924554
> Content-Type application/octet-stream

This is the type of object which is being transferred. As you can see it
is not a GIF type. I agree it is probably wrong type assignment by the
sender, but we (and definitely Squid) has no way to be certain of that.

So in the end what this comes down to is whether squidclamav tool treats
content-disposition filename as if it were the URL for deciding the
abort/abandon handling. I suspect it is doing the same thing as Squid
using just the request URL, since there is no mention of
content-disposition in the changelog and that has only recently been
standardized as a header.

Amos
Received on Thu Aug 01 2013 - 10:18:13 MDT