file://xxx/proxy.pac always resolves to DIRECT by googleupdate.exe

[GoogleCodeExporter]

The following was originally reported in Chromium Issue 42615.

What steps will reproduce the problem?

1. Open Chrome's proxy settings (i.e. Internet Properties->Connections->LAN 
Settings...)
2. Set [x] Use automatic configuration script to 
file://c:/some/path/proxy.pac
Where proxy.pac might contain something like:
function FindProxyForURL(url, host) { return "PROXY 
<your_proxy>:<your_proxy_port>"; }
3. Reboot to allow the "Google Update" (GoogleUpdate.exe /c) startup entry 
to run, or more 
easily, select "About Google Chrome" under Chrome's Alt-F menu.
4. Since direct connections are blocked where I'm at, I'll see a waiting 
SYN_SENT to 
74.125.153.x in 'netstat -n' or TCPView[1] 

[1] http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx

What is the expected output? What do you see instead?
Issue 1. Use the proxy server as return by the configured script.
Issue 2 . If a script cannot be supported, at least fallback to the 
settings in "[x] Use a 
proxy server for your LAN". (Which currently gets ignored when it's used 
together with "Use 
automatic configuration script".)

What version of the product are you using? On what operating system?
1-3 instances of googleupdate.exe will repeatedly attempt and fail to make 
outbound 
connections for ten or so minutes.  The Event Log gets filled with a 
"Google Update" error 
entries of one or two every hour.  (Though this is probably from the tasks 
scheduled for 
Google Update.)

Please provide any additional information below.
-------------------- Excerpt (partial) from a Google Update event log entry
Network Request Error.
Error: 0x80072ee2. Http status code: 0.
Url=https://tools.google.com/service/update2
Trying config: source=IE, wpad=0, script=file://c:/proxy.pac.
trying CUP:WinHTTP.
Send request returned 0x80072ee2. Http status code 0.
trying WinHTTP.
Send request returned 0x80072ee2. Http status code 0.
trying CUP:iexplore.
Send request returned 0x80004005. Http status code 0.
Trying config: source=auto, wpad=1, script=.
trying CUP:WinHTTP.
Send request returned 0x80072ee2. Http status code 0.
trying WinHTTP.
Send request returned 0x80072ee2. Http status code 0.
trying CUP:iexplore.
Send request returned 0x80004005. Http status code 0.
Trying config: source=IE, wpad=0, script=file://c:/proxy.pac.
trying CUP:WinHTTP.
Send request returned 0x80072ee2. Http status code 0.
trying WinHTTP.
Send request returned 0x80072ee2. Http status code 0.
trying CUP:iexplore.
Send request returned 0x80004005. Http status code 0.
Trying config: source=auto, wpad=1, script=.
trying CUP:WinHTTP.
----------------------------------------

Original issue reported on code.google.com by ddor...@google.com on 3 Jun 2010 at 5:50

[GoogleCodeExporter]

Maybe Omaha does not like file://.

Original comment by ddor...@google.com on 3 Jun 2010 at 5:51

[GoogleCodeExporter]

Looks that's the issue. Actually Omaha doesn't use the proxy script URI 
directly but 
passes it to function WinHttpGetProxyForUrl. WinHttpGetProxyForUrl then calls 
WinHttpSendRequest to get the script file. Unfortunately WinHttpSendRequest 
can't 
handle scheme file:// and fails with 12006 (ERROR_WINHTTP_UNRECOGNIZED_SCHEME) 
whiche 
translates to HRESULT 0x80072ee6. Directly specifying c:\proxy.pac doesn't work 
either. 
The fix maybe to use InternetGetProxyInfo() from wininet. End user can also 
move the 
wpad.dat file to a http server to workaround the issue.

Original comment by xiaoling...@gmail.com on 3 Jun 2010 at 7:22

[GoogleCodeExporter]

I only copied the first user report. More user reports can be found in the 
original 
Chromium bug at http://crbug.com/42615.

Original comment by ddor...@google.com on 3 Jun 2010 at 7:26

[GoogleCodeExporter]

In the following thread, someone from Microsoft confirms that WinHttp does not 
support 
local files and that WinINET does. He also suggests a solution at the end of 
the 
thread.

https://groups.google.com/group/microsoft.public.winhttp/browse_thread/thread/43
fc7c8c1
7aa4e62?pli=1

Original comment by ddor...@google.com on 3 Jun 2010 at 7:33

[GoogleCodeExporter]

Omaha3 has been released, and adds support for local .PAC files.

Original comment by ryanmyers@google.com on 19 Aug 2011 at 7:40

• Changed state: Fixed