Autoproxy configuration script parsing in .Net/C#

2.4k Views Asked by At

In order for my application (.Net 1.1) to use the system configured proxy server (trough a proxy.pac script) I was using an interop calls to WinHTTP function WinHttpGetProxyForUrl, passing the proxy.pac url I got from the registry.

Unfortunately, I hit a deployment scenario, where this does not work, as the proxy.pac file is deployed locally on the user's hard drive, and the url is "file://C://xxxx"

As clearly stated in the WinHttpGetProxyForUrl docs, it works only with http and https schemes, so it fails with file://

I'm considering 2 "ugly" solutions to the problem (the pac file is javascript):

  1. Creating a separate JScript.NET project, with a single class with single static method Eval(string), and use it to eval in runtime the function read from the pac file

  2. Building at runtime a JScript.NET assembly and load it.

As these solutions are really ugly :), does anybody know a better approach? Is there a Windows function which I can use trough interop?

If not, what are you guys thinking about the above 2 solutions - which one would you prefer?

4

There are 4 best solutions below

2
On BEST ANSWER

Just a thought: Why not create a micro web server that can serve the local PAC file over a localhost socket. You should use a random URI for the content so that it is difficult to browse this in unexpected ways.

You could then pass a URL like http://localhost:1234/gfdjklskjgfsdjgklsdfklgfsjkl to the WinHttpGetProxyForUrl function and allow it to pull the PAC file from your micro server.

(hack... hack... hack...)

2
On
1
On

Can't answer your problem unfortunately (though a few years ago I played with jscript.net and it would only be a few lines to build and run that way)

I hit a similar proxy.pac hiccup with a personal work-around-the-office-proxy file a while back - in the end I went with the easiest option and dropped it into its own IIS site, and its been rock solid and works flawlessly with everything on my pc.

Sometimes its best to give in and work with what is provided :)

0
On

I can't answer you question directly, but working from the mozilla implementation there was a definite debate about supporting file URLs. It was a network control vs. local user convenience debate.