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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
