[squid-users] ftp_port and squidclamav

[Alex Rousskov]

On 10/12/21 9:58 AM, Andrea Venturoli wrote:

> On 8/28/21 17:10, Alex Rousskov wrote:
>> Reproduce the problem using a single transaction on an otherwise idle
>> Squid with full debugging enabled and share the corresponding cache.log:
>> https://wiki.squid-cache.org/SquidFaq/BugReporting#Debugging_a_single_transaction
>>
> 
> It's here:
> https://www.netfence.it/download/cache.log.bz2

I am not sure, but I suspect that you are suffering from your ICAP
service inability to handle REQMOD transactions with HTTP 100-Conntinue
semantics, including (but not limited to) FTP STOR requests (translated
into HTTP by Squid).

Squid has a configuration option to work around such adaptation service
deficiencies: force_request_body_continuation. Please see if enabling
that workaround helps in your environment:
http://www.squid-cache.org/Doc/config/force_request_body_continuation/

HTH,

Alex.
P.S. When you sanitized your cache.log, you have stripped lines dumping
message headers. Those lines do not start with the usual
"2021/10/12...|" prefix. Stripping them complicates triage.




>>> Or, is there any way I can tell Squid to avoid passing FTP traffic
>>> (coming on port 2121) to ICAP (while of course doing that for the rest)?
>>
>> Yes, the adaptation_access directive controls what traffic goes to your
>> ICAP services. To match ftp_port traffic, I would give the ftp_port a
>> name and then try using that name in a myportname ACL. Other ACLs may
>> also work, but I would start with myportname. If myportname does not
>> work for ftp_port traffic, it is a Squid bug.
> 
> This works.
> Thanks!
> 
>  bye
>     av.