Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

find the http proxy on windows more reliably #453

Closed
bos opened this Issue · 8 comments

2 participants

@bos
Owner

(Imported from Trac #460, reported by @dcoutts on 2009-01-17)

Some network setups (particularly corporate ones) do not use a static proxy set in the windows registry but use AutoProxy. This is a rather complex protocol involving DHCP, dns and requires a JavaScript interpreter.

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:

It seems that there are some performance issues with AutoProxy but any caching has to be fairly careful since the proxy information can change.

@bos
Owner

(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:

  • direct connection (no proxy)
  • specific proxy (and proxy bypass list)
  • auto config url (url of a .pac file)
  • auto detect (WPAD / AutoProxy)
In the third case we can use WinHttpGetProxyForUrl() to get the .pac file, cache it and interpret it for us each time we look up a url. We can use the WinHttpGetProxyForUrl() function in such a way that it never tries the WPAD / AutoProxy protocol.

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.

@bos
Owner

(Imported comment by @dcoutts on 2009-01-17)

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.

@bos
Owner

(Imported comment by @dcoutts on 2009-01-17)

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.

@bos
Owner

(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.

@bos
Owner

(Imported comment by guest on 2009-03-24)

The previous comment was by me -- Neil

@bos
Owner

(Imported comment by ganesh on 2009-03-24)

The env var is in now and in the latest release, btw.

@bos
Owner

(Imported comment by guest on 2009-03-24)

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

@gregorycollins

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.