HttpWebRequest exception: "Unable to connect to the remote server" when using .INS config files


Problem 


Taking a System.Net Trace (see My Favorite System.Net Tracing File) you will see that the HttpWebRequest is trying to use a .INS file.


System.Net Verbose: 0 : [0371] WebRequest::Create(http://myserver/ie/update/windows/IEConfig.INS)


It is successfully retrieved but when the request is made you see something similar to this in the .NET log:


System.Net.Sockets Error: 0 : [0371] Exception in the Socket#4094998::Connect – No connection could be made because the target machine actively refused it 192.168.0.202:443


and


System.Net Error: 0 : [0371] Exception in the HttpWebRequest#33574999:: – Unable to connect to the remote server

Resolution


System.Net by design does not process .INS files.  This results in the HTTP Request being made direct and the Proxy is denying this action.


You need choose one of these methods to resolve the issue:


1. Change your environment to use .PAC files.  For example, set this in IE or use the AutoConfigUrl key.


2. Change your .NET code to hard code the proxy information


3. Add proxy configuration information to your <<application>>.exe.config, web.config or machine.config files.



-Jeff

Comments (3)

  1. Greg says:

    Is it the same with Winhttp as with System.Net?

  2. jpsanders says:

    Yes, WinHttp does not support .ins files.  Use netsh or winhttpcfg to configure proxy settings for WinHttp.

  3. jrv says:

    What happens deep down is a bit more exciting, although the result is the same. If you create a test .NET program, uncheck "Enable Just My Code" (tools, options, debugging), and catch all exceptions when thrown, you will catch yourself a parse exception inside a javascript engine. .NET apparently downloads the "ins" file, but assumes it is a pac file and feeds it to the javascript engine for evaluation. As an ins file it naturally fails the javascript parsing. ["Take the Burden Off Users with Automatic Configuration in .NET" Durgaprasad Gorti, http://msdn.microsoft.com/en-us/magazine/cc300743.aspx]

    Thanks, BTW. This is the first even semi-official confirmation of the behavior our client observed.

    JR