Hello, Ok it seems to be working now (10 bytes by 10 bytes and then the rest of the file) the browser download gauge is useless but I suppose it's normal behavior. Here is my conf : ecap_service clamav_service_req reqmod_precache uri=ecap://e-cap.org/ecap/services/clamav?mode=REQMOD <http://e-cap.org/ecap/services/clamav?mode=REQMOD> bypass=off ecap_service clamav_service_resp respmod_precache uri=ecap://e-cap.org/ecap/services/clamav?mode=RESPMOD <http://e-cap.org/ecap/services/clamav?mode=RESPMOD> bypass=on staging_dir=/var/eclamav/resp- trickling_drop_size=10 Do you think it's ok ? Regards 25 nov. 2019 à 18:57 de rousskov@xxxxxxxxxxxxxxxxxxxxxxx: > On 11/25/19 12:31 PM, zbox wrote: > >> I already have this line before your snippet : >> >> ecap_service clamav_service_resp respmod_precache uri=ecap://e-cap.org/ecap/services/clamav?mode=RESPMOD bypass=on >> >> Sould I try to merge them ? >> > > Short answer: Yes. > > You should have one ecap_service directive per unique eCAP service (that > could mean one ecap_service directive per service URI, but Squid also > takes into account the vectoring point IIRC). Each ecap_service > directive tells Squid everything about the service expectations and > behavior. If you tell Squid two different sets of facts about the same > service, Squid would not know which set is the correct one. > > I do not know whether modern Squids warn admins about > conflicting/duplicated ecap_service directives. If Squid does not, that > is a bug. Eventually, duplicated ecap_service directives should be > treated as fatal configuration errors. > > > HTH, > > Alex. > > > >> 19 nov. 2019 à 23:41 de rousskov@xxxxxxxxxxxxxxxxxxxxxxx: >> >>> On 11/19/19 5:24 AM, zbox wrote: >>> >>>> I've made the changes, the files are now downloaded in the temp dir >>>> but the behaviour is the same on the browser... >>>> >>> >>> Glad your configuration problem got resolved. >>> >>> There is not enough information to figure out what else, if anything, is >>> broken (and where that breakage is). However, if the adapter was >>> configured to trickle, and you see a temporary download file growing in >>> size _while_ Squid sends _nothing_ to the client (at HTTP level) for >>> several seconds, then there is probably a bug in Squid and/or the >>> adapter. At the very least, Squid should sent the response header to the >>> client. >>> >>> Without looking at low-level debugging logs (at least), I cannot tell >>> who is at fault, but perhaps others on the list can share trickling >>> success stories or help you with the triage. >>> >>> Alex. >>> _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
