407 Proxy authentication required
I am working on a website where I am pulling XML data from an external url using the following code
WebRequest req = WebRequest.Create("External server url");
req.Proxy = new System.Net.WebProxy("proxyUrl:8080", true);
req.Proxy.Credentials = CredentialCache.DefaultCredentials;
WebResponse resp = req.GetResponse();
StreamReader textReader = new StreamReader(resp.GetResponseStream());
XmlTextReader xmlReader = new XmlTextReader(textReader);
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.Load(xmlReader);
This code works fine on my development PC (Windows XP with .Net 3.5)
But when I deploy this code in IIS (both Windows XP and Windows Server 2003) it gives me the following error
"The remote server responded with an error: (407) Proxy authentication required."
Sometimes it gives me
"The remote server returned an error: (502) Bad Gateway."
Following code from my web.config
<system.net>
<defaultProxy>
<proxy usesystemdefault="False" proxyaddress ="http://172.16.12.12:8080" bypassonlocal ="True" />
</defaultProxy>
</system.net>
Please help me?
[edit] Even when I run the PC development website, but through IIS it gives me the error "Remote server responded with error: (407) Proxy authentication required".
But when I run the website from Microsoft Devlopment server it works fine
source to share
@Mohit Agarwal
Thanks a lot for the suggestion to add 'useDefaultCredentials = "true", you are a star!
I've been trying to get the .NET library for the Google Data API example EXE running for several weeks with no success. By adding your suggestion I fixed my problem and now I am getting connection instead of 407 Proxy Authentication Required.
Contentspeadsheet.exe.config should be:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy usesystemdefault="true"/>
</defaultProxy>
</system.net>
</configuration>
In my case NOT as Google suggests:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy>
<proxy usesystemdefault="true"/>
</defaultProxy>
</system.net>
</configuration>
source to share
It might be helpful for someone to find this through Google so that you can use it in .NET applications that may not have their own AppName.exe.config file yet (or you can change it if so). We use NextGen EPM (medical planning / billing) and their credit card processing system is constantly stuck on our proxy because it won't pass credentials. In this case, I created an EXEName.config file (NextGenEPM.exe.config) containing the snippet above:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy usesystemdefault="true"/>
</defaultProxy>
</system.net>
</configuration>
Success! This allowed me to fix the problem without letting it pass on our proxy, which is configured to require authentication, and we wouldn't compromise.
source to share
Try this if you want to specify proxy details
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy proxyaddress="http://<ProxyServer>:<port>"
usesystemdefault="False"
bypassonlocal="True"
autoDetect="False" />
</defaultProxy>
</system.net>
</configuration>
Hooray!
source to share
This is likely due to the fact that IIS is running without proper permissions to go through the authentication proxy.
When you run it on your development machine, you run it as your login, which I assume has proxy permissions. When running inside IIS, it doesn't work like you do, and it probably can't go through the proxy.
You can either grant IIS user permissions to proxy access (which is unlikely to work in a domain environment, since the IIS user will be the local user of the machine), or you can configure the application to run as a network user with proxy permissions.
This can be done either by starting IIS as a domain user (I would not recommend this approach) or by configuring the application to run as a domain user using web.config (see this article for more information on how to do this ).
source to share
We've been struggling with this issue for a long time and have updated our app.config to use the default credentials as stated in the answers above. However, it still didn't work! After a lot of pain, we found that our app.config was not automatically included with our click after application. A simple mistake caused an extreme loss of the crash !!!
source to share