(Imported from Trac #460, reported by @dcoutts on 2009-01-17)
However the WinHTTP library comes with Windows as of Win2k SP3, WinXP SP1, Win2k3 and Vista.
It's got a bunch of functions for dealing with this AutoProxy? stuff, including sample code. In particular the main function we want is WinHttpGetProxyForUrl
So we could try either statically linking to this, or perhaps doing some dynamic GetProcAddress funky stuff.
Reading more closely, it seems that this only works if the setup is using an AutoProxy setup. This documentation may be more relevant:
(Imported comment by @dcoutts on 2009-01-17)
It seems that the Web Proxy Auto-Discovery (WPAD) protocol is more than a bit dodgy.
The right thing to do seems to be to check either the default settings with WinHttpGetDefaultProxyConfiguration() though this is apparently more appropriate for system service.
Alternatively we check the IE settings with WinHttpGetIEProxyConfigForCurrentUser(). It may specify a number of possibilities:
In the last case we either bite the bullet and try this nasty insecure protocol or we fail, or perhaps we just try a direct connection anyway and then fail.
The fact that the .pac file can specify a different proxy for each URL is a bit irksome. It means we'd have to keep a WinHTTP HINTERNET session about for the whole time we're making a sequence of HTTP requests.
Ugg, using the WinHTTP library requires using side-by-side assemblies and a manifest file. Currently ghc and Cabal have no support for using manifests to specify dependencies on assemblies.
This looks to be too hard. The workaround of setting an HTTP env var is apparently acceptable. A proper solution is not impossible but would need quite a bit of time to implement.
(Imported comment by guest on 2009-03-03)
Bad news: while an HTTP env var would be nice to have in the short-term, long-term we would very much appreciate full proxy support. If you are working for a global system which has different users behind different proxies figuring out the appropriate one is going to be quite hard.
(Imported comment by guest on 2009-03-24)
The previous comment was by me -- Neil
(Imported comment by ganesh on 2009-03-24)
The env var is in now and in the latest release, btw.
Good news: I figured out how to work around all these issues (we no longer use cabal-install at all), so I have no immediate interest in this bug. -- Neil
I closed a similar bug to this one earlier today: realistically nobody is going to spend the time to a) figure out exactly how to make this automagic work or b) do the immense amount of work necessary to implement it once it's been figured out. Closing as won't fix.