Issue metadata
Sign in to add a comment
|
Chrome is unable to use PAC/WPAD file - Always returns DIRECT
Reported by
pepis...@cisco.com,
Nov 13 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Example URL: facebook.com Steps to reproduce the problem: 1. load PAC file 2. 3. What is the expected behavior? chrome should use the proxy per PAC file, but returns DIRECT instead. Even if the proxy is accessible What went wrong? Chrome is returning DIRECT for all requests than proxy. Issue is not seen when using IE or Firefox Did this work before? N/A Chrome version: 61.0.3163.100 Channel: n/a OS Version: 10.0 Flash Version:
,
Nov 13 2017
Could you please export a log from about:net-export, and upload it? It should let us see if the issue is with retrieving the pac script, or running it, at least. Visited URLs will be visible in the log, but cookies, upload bodies, and credentials will not be.
,
Nov 13 2017
Thanks, will work on getting the logs from end customer
,
Nov 13 2017
Thank you for providing more feedback. Adding requester "mmenke@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 13 2017
,
Nov 13 2017
Chrome logs
,
Nov 13 2017
Thank you for providing more feedback. Adding requester "mmenke@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 13 2017
The PAC file given in comment #1 isn't consistent with the log in comment #7. It is more likely that your PAC script is doing something like: return "PROXY torproxy01.apotex.ca:80;DIRECT"; In other words, specifying a fallback to direct. The log file indicates that your PAC script is being used, however torproxy01.apotex.ca:80 has failed requests in the past and has been de-prioritized. Hence it sends to DIRECT. The solution should be to remove DIRECT as a fallback if you don't want it to use DIRECT.
,
Nov 13 2017
Forgot to say in comment #8: thanks for attaching the log file!
,
Nov 13 2017
Chrome will mark proxies as bad if requests sent to other ports through the proxy fail, but direct requests succeed, which may be the reason you're only seeing this with Chrome. See issue 680837 .
,
Nov 13 2017
Many thanks! Peter Episcopo Cisco TAC – Web Security Phone: +1 919 574 3766 Email:pepiscop@cisco.com<mailto:pepiscop@cisco.com> Office hours: 8:00 AM – 4:00 PM (Eastern Time US) To update your case (requires a support contract): https://tools.cisco.com/ServiceRequestTool/scm/mgmt/case Cisco Worldwide Contact: http://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.html ------------------------------------------- Jamie Herubin jherubin@cisco.com<mailto:jherubin@cisco.com> 9193929343 From: mme… via monorail [mailto:monorail+v2.3079273537@chromium.org] Sent: Monday, November 13, 2017 5:20 PM To: Peter Episcopo (pepiscop) <pepiscop@cisco.com> Subject: Issue 784463 in chromium: Chrome is unable to use PAC/WPAD file - Always returns DIRECT
,
Nov 15 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by pepis...@cisco.com
, Nov 13 2017315 bytes
315 bytes Download