Many thanks for the explanation There is a miss configuration in config file:
"cache deny all" It's a shame... -----Message d'origine----- De : squid-users <squid-users-boun...@lists.squid-cache.org> De la part de Alex Rousskov Envoyé : samedi 23 février 2019 23:16 À : squid-users@lists.squid-cache.org Objet : Re: [squid-users] squid 4.x: decided: do not cache but share because the entry has been released On 2/23/19 10:17 AM, Amos Jeffries wrote: > On 24/02/19 5:33 am, David Touzeau wrote: >> http.cc(982) haveParsedReplyHeaders: decided: do not cache but share >> because the entry has been released; HTTP status 200 >> What “but share because the entry has been released” event means ? > 'do not cache but share' means the reply may still be shared with > other concurrent clients (eg. collapsed forwarding), but not to bother > trying to cache it. Correct. To participate in that sharing, those concurrent clients must already have a lock on this entry. In other words, "concurrency" here is determined by having guaranteed access to the Store entry rather than just overlapping transaction lifetimes. > 'entry has been released' means something else already caused the disk > copy in cache to be removed or replaced. Yes, and this is not limited to the old entries in the disk cache. Entry "release" may happen even before the entry is earmarked for any of the caches, and the release affects both disk and memory caches. If you want to figure out why this response is not being cached, you may need to figure out why the corresponding Store entry was marked for release. Look for releaseRequest lines in the debugging cache.log that match the same entry and try to determine why releaseRequest was called. Alex. _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
