On 01/24/2017 11:19 AM, Yuri Voinov wrote: > It is downloads directly via proxy from localhost: > As I understand, downloader also access via localhost, right? This is incorrect. Downloader does not have a concept of an HTTP client which sends the request to Squid so "via localhost" or "via any client source address" does not apply to Downloader transactions. In other words, there is no client [source address] for Downloader requests. Unfortunately, I do not know exactly what effect that lack of info has on what ACLs (in part because there are too many of them and because lack of info is often treated inconsistently by various ACLs). Thus, I continue to recommend finding out which directive/ACL denied Downloader access as the first step. Alex. > 25.01.2017 0:16, Alex Rousskov пишет: >> On 01/24/2017 10:48 AM, Yuri Voinov wrote: >> >>> It seems 4.0.17 tries to download certs but gives deny somewhere. >>> However, same URL with wget via same proxy works >>> Why? >> Most likely, your http_access or similar rules deny internal download >> transactions but allow external ones. This is possible, for example, if >> your access rules use client information. Internal transactions (ESI, >> missing certificate fetching, Cache Digests, etc.) do not have an >> associated client. >> >> The standard denial troubleshooting procedure applies here: Start with >> finding out which directive/ACL denies access. I am _not_ implying that >> this is easy to do. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
