http://bugs.winehq.org/show_bug.cgi?id=28552
Bug #: 28552 Summary: winhttp proxy doesn't work Product: Wine Version: 1.3.28 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winhttp AssignedTo: wine-bugs@winehq.org ReportedBy: jiri.humpolicek@seznam.cz Classification: Unclassified
Created attachment 36666 --> http://bugs.winehq.org/attachment.cgi?id=36666 Binary and sources of test application
Hi, I have similar problem as was solved in Bug 15393. I tested this behavior on lasted version of Wine (wine-1.3.28), but it seems still not working. When we are behind proxy and using WinHttp, applications are trying to connect direct. I attached simple .net console application and its sources.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #1 from Hans Leidekker hans@meelstraat.net 2011-10-02 14:38:53 CDT --- Confirmed, WinHttpDetectAutoProxyConfigUrl is a stub. Do you know how the PAC url is advertised on your network? Via DHCP or DNS?
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #2 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-10-03 02:05:53 CDT --- I guess that in my network PAC url is not used at all. I tested it on my ubuntu linux machine, with manual proxy settings by exporting http_proxy variable. When I run it in mono in same shell proxy is detected correctly.
http://bugs.winehq.org/show_bug.cgi?id=28552
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase
http://bugs.winehq.org/show_bug.cgi?id=28552
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #3 from Austin English austinenglish@gmail.com 2011-10-03 13:38:17 CDT --- (In reply to comment #1)
Confirmed, WinHttpDetectAutoProxyConfigUrl is a stub. Do you know how the PAC url is advertised on your network? Via DHCP or DNS?
Forgot to confirm :)
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #4 from Hans Leidekker hans@meelstraat.net 2011-10-03 14:46:21 CDT --- (In reply to comment #2)
I guess that in my network PAC url is not used at all. I tested it on my ubuntu linux machine, with manual proxy settings by exporting http_proxy variable.
Does the test app work on a Windows machine in the same network?
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #5 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-10-04 00:58:59 CDT --- Yes, it works. I tested it with direct connection as well as with proxy server (I set it up in IE lan settings).
http://bugs.winehq.org/show_bug.cgi?id=28552
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #6 from André H. nerv@dawncrow.de 2011-10-05 12:20:23 CDT --- after viewing some logs it really only uses ws2_32, but no wininet, mshtml or something. so ws2_32 should detect that it's connecting to a proxy and then authenticate as wininet does, but that seems like major changes...
http://bugs.winehq.org/show_bug.cgi?id=28552
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com 2011-10-05 22:13:49 CDT --- André, can you elaborate on that conclusion? You mean connect/WSAConnect detects the system proxy and try to communicate over it?
What if only a HTTP proxy is configured it would be impossible to tunnel raw TCP sockets through HTTP in most of the cases due to the way http proxy works.
If a SOCKS proxy is configured then I would agree it's possible to tunnel any connection through proxy.
Or you mean when the connect/WSAConnect IP is the proxy IP the winsock dll tries to authenticate by itself using the correct configured protocol?
I would like to understand how did you concluded about that.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #8 from Hans Leidekker hans@meelstraat.net 2011-10-06 07:24:37 CDT --- (In reply to comment #7)
André, can you elaborate on that conclusion? You mean connect/WSAConnect detects the system proxy and try to communicate over it?
What if only a HTTP proxy is configured it would be impossible to tunnel raw TCP sockets through HTTP in most of the cases due to the way http proxy works.
If a SOCKS proxy is configured then I would agree it's possible to tunnel any connection through proxy.
Or you mean when the connect/WSAConnect IP is the proxy IP the winsock dll tries to authenticate by itself using the correct configured protocol?
I would like to understand how did you concluded about that.
My understanding is that .NET has its own HTTP stack implemented on top of ws2_32, which calls WinHttpDetectAutoProxyConfigUrl to retrieve proxy settings. So ws2_32 itself has nothing to do with detecting proxies.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #9 from Hans Leidekker hans@meelstraat.net 2011-11-12 09:29:21 CST --- (In reply to comment #5)
Yes, it works. I tested it with direct connection as well as with proxy server (I set it up in IE lan settings).
Did you set up the proxy server in the same way on Wine?
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #10 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-11-14 03:11:51 CST --- I setup proxy on Wine by exporting http_proxy variable or by changing registry [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #11 from Austin English austinenglish@gmail.com 2011-11-15 14:35:28 CST --- Committed: http://source.winehq.org/git/wine.git/commitdiff/96f2e7139cb14b1711c0dc22fea...
please retest.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #12 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-11-16 04:03:15 CST --- (In reply to comment #11)
Committed: http://source.winehq.org/git/wine.git/commitdiff/96f2e7139cb14b1711c0dc22fea...
please retest.
Good work, I built wine and it goes through configured proxy. I will do more tests in the evening. Thanks, Jirka
http://bugs.winehq.org/show_bug.cgi?id=28552
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |96f2e7139cb14b1711c0dc22fea | |1f9eb47802df5 Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #13 from André H. nerv@dawncrow.de 2011-11-16 05:16:45 CST --- fixed
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #14 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-11-18 08:42:12 CST --- (In reply to comment #12)
Good work, I built wine and it goes through configured proxy. I will do more tests in the evening. Thanks, Jirka
It works in network, where auto-configuration wpad script is available, but for example in my home where no wpad script is available and I setup proxy by hand (by setting http_proxy or proxy settings in registry) application ignore these settings and goes direct.
Another point is how to implement user autoconfiguration url entering.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #15 from Hans Leidekker hans@meelstraat.net 2011-11-18 10:57:17 CST --- (In reply to comment #14)
(In reply to comment #12)
Good work, I built wine and it goes through configured proxy. I will do more tests in the evening. Thanks, Jirka
It works in network, where auto-configuration wpad script is available, but for example in my home where no wpad script is available and I setup proxy by hand (by setting http_proxy or proxy settings in registry) application ignore these settings and goes direct.
With native .NET I see only a call to WinHttpDetectAutoProxyConfigUrl. Does it work on a Windows machine in your home network?
I would expect it to fall back to importing proxy settings from IE. Did you try installing native IE yet? That will also give you a dialog to configure the proxy...
http://bugs.winehq.org/show_bug.cgi?id=28552
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org 2011-11-18 13:03:50 CST --- Closing bugs fixed in 1.3.33.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #17 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-11-21 01:50:16 CST --- (In reply to comment #15)
With native .NET I see only a call to WinHttpDetectAutoProxyConfigUrl. Does it work on a Windows machine in your home network?
I would expect it to fall back to importing proxy settings from IE. Did you try installing native IE yet? That will also give you a dialog to configure the proxy...
It behaves a little bit strange. On 64-bit ubuntu I am able to configure proxy by setting http_proxy variable, but ie6 fails after installation and crashes during every start. On 32-bit ubuntu I am unable to make proxy working (exporting http_proxy or registry). But installation of ie6 successfully completes and working, but after setting proxy in its network settings ie silently ignore these settings and always go direct. I suppose that something is wrong in my Linux installations.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #18 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-11-21 02:21:47 CST --- (In reply to comment #15)
With native .NET I see only a call to WinHttpDetectAutoProxyConfigUrl. Does it work on a Windows machine in your home network?
I would expect it to fall back to importing proxy settings from IE. Did you try installing native IE yet? That will also give you a dialog to configure the proxy...
Regarding your changes to WinHttpDetectAutoProxyConfigUrl I'd like to propose simple solution for custom auto-configuration script URLs. Choose any (probably wine specific) registry location for storing wpad auto-configuration script URL and in WinHttpDetectAutoProxyConfigUrl firstly check if this registry entry is present and return it otherwise use current behavior.
I think it will be useful, because it gave user more freedom of placing wpad script. Moreover custom URL is for example used in our company network.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #19 from Hans Leidekker hans@meelstraat.net 2011-11-21 02:44:27 CST --- (In reply to comment #18)
Regarding your changes to WinHttpDetectAutoProxyConfigUrl I'd like to propose simple solution for custom auto-configuration script URLs. Choose any (probably wine specific) registry location for storing wpad auto-configuration script URL and in WinHttpDetectAutoProxyConfigUrl firstly check if this registry entry is present and return it otherwise use current behavior.
I think it will be useful, because it gave user more freedom of placing wpad script. Moreover custom URL is for example used in our company network.
What exactly is the problem you're trying to solve? If you want to make your test app work in your home network, all you need to do is publish a wpad script for your local domain.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #20 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-11-21 04:32:10 CST --- (In reply to comment #19)
What exactly is the problem you're trying to solve? If you want to make your test app work in your home network, all you need to do is publish a wpad script for your local domain.
You are right, but I think that my proposal will make thing easier (in windows you can use wpad script from custom URL). In our company we are in dnsdomain X, but we use wpad script from different location (domain Y).
In my home I am using ubuntu in virtual machines, and I don't have web server configured. So it will be easier just set registry somewhere to web.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #21 from Hans Leidekker hans@meelstraat.net 2011-11-21 04:55:43 CST --- (In reply to comment #20)
(In reply to comment #19)
What exactly is the problem you're trying to solve? If you want to make your test app work in your home network, all you need to do is publish a wpad script for your local domain.
You are right, but I think that my proposal will make thing easier (in windows you can use wpad script from custom URL). In our company we are in dnsdomain X, but we use wpad script from different location (domain Y).
In this case Windows clients must be configured manually (which defeats the purpose of wpad), and you should do the same on Wine.
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #22 from Jiri Humpolicek jiri.humpolicek@seznam.cz 2011-11-21 12:27:46 CST --- (In reply to comment #21)
In this case Windows clients must be configured manually (which defeats the purpose of wpad), and you should do the same on Wine.
That is not true. I have already tried that. In windows go to the "Control panel/Internet options" and on "connections" tab click on the "LAN settings" and there you can check "use automatic configuration script" and enter URL for wpad script. And these settings are for whole system (I expect that winhttp or similar library take these settings in account).
http://bugs.winehq.org/show_bug.cgi?id=28552
--- Comment #23 from Hans Leidekker hans@meelstraat.net 2011-11-21 14:07:43 CST --- (In reply to comment #22)
(In reply to comment #21)
In this case Windows clients must be configured manually (which defeats the purpose of wpad), and you should do the same on Wine.
That is not true. I have already tried that. In windows go to the "Control panel/Internet options" and on "connections" tab click on the "LAN settings" and there you can check "use automatic configuration script" and enter URL for wpad script. And these settings are for whole system (I expect that winhttp or similar library take these settings in account).
That's the same dialog you can reach via IE's tools menu. It's per-user because it modifies this registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
winhttp supports this but not automatically; it's up to the application to call WinHttpGetIEProxyConfigForCurrentUser.
If native IE doesn't work for you on Wine, try exporting that key from Windows and importing it in Wine.