2016-06-02 10 views
2

Ich habe einen sehr einfachen Dienst, der eine URL aufruft und einen Status erfasst, der von diesem Dienst ausgegeben wird.Die zugrunde liegende Verbindung wurde geschlossen: Ein unerwarteter Fehler ist aufgetreten

// Service call used to determine availability 
System.Net.WebClient client = new System.Net.WebClient(); 

// I need this one (sorry, cannot disclose the actual URL) 
Console.WriteLine(client.DownloadString(myServiceURL + ";ping")); 

// I added this for test purposes 
Console.WriteLine(client.DownloadString("https://www.google.com")); 

Die „DownloadString“ für myServiceURL Linie führt den Fehler „Die zugrunde liegende Verbindung wurde geschlossen: Ein unerwarteter Fehler ist aufgetreten“ und es gibt nichts in Fiddler für diese Linie zeigt, während die „DownloadString“ für google.com arbeitet und Ich sehe die Konsolenausgabe dafür.

Nach anderen Vorschlägen für den Fehler, habe ich Kombinationen der Einstellung UseDefaultCredentials, Encoding-Optionen, Hinzufügen von geeigneten Headern auf die Anfrage, von denen keiner einen Unterschied machen.

client.UseDefaultCredentials = true; 
client.Encoding = Encoding.UTF8; 

Als ich zum myServiceURL in einem Browser navigieren, es funktioniert und zeigt "OK", wie erwartet.

Ein weiteres Verfahren aus dem gleichen Dienst codiert worden ist, wie folgt:

// Request 
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(myServiceURL + ";login"); 

// Set the request configuration options 
req.Method = "POST"; 
req.ContentType = "text/xml"; 
req.ContentLength = bytes.Length; 
req.Timeout = -1; 

// Call for the request stream 
using (Stream os = req.GetRequestStream()) 
{ 
    os.Write(bytes, 0, bytes.Length); 
} 

// ....snip 

// This line fails with the same error as before 
WebResponse resp = req.GetResponse() 

Dies alles wird auf einem Windows 7 (64-Bit) ausgeführt wird unter Verwendung von PC NET Framework 4.0; Der Dienst bei myServiceURL ist ein Dienst von Drittanbietern, auf den ich keinen Einfluss habe.

+0

haben Sie versucht req.Proxy = WebProxy.GetDefaultProxy(); –

+0

Haben Sie gerade versucht GetDefaultProxy (was ist veraltet?) Und es machte keinen Unterschied. – Sean

+0

ooh Entschuldigung, rate eher als contentype du kannst diese req als HttpWebRequest.Accept = "text/xml"; –

Antwort

0
 //assuming this is set 
     byte[] Data; 
     string url = string.Format("{0};{1}" ,myServiceURL, "login"); 
     // Request 
     HttpWebRequest wreq = (HttpWebRequest)WebRequest.Create(url); 

     wreq.Method = "POST"; 
     wreq.Proxy = WebProxy.GetDefaultProxy(); 

     (wreq as HttpWebRequest).Accept = "text/xml"; 


     if (Data != null && Data.Length > 0) 
     { 
      wreq.ContentType = "application/x-www-form-urlencoded"; 
      System.IO.Stream request = wreq.GetRequestStream(); 
      request.Write(Data, 0, Data.Length); 
      request.Close(); 
     } 
     WebResponse wrsp = wreq.GetResponse(); 
+0

Ich bin mir nicht ganz sicher, was mit diesem Code im Vergleich zu dem Code, den ich verwendet habe, signifikant anders ist; aber ich habe versucht, dies ... den gleichen Fehler und ich vermute wirklich, dass etwas passiert, das neben dem Code ist, da die gleichen Anfragen an google.com und eine einfache Textdatei (auf meinen eigenen Server hochgeladen) beide so funktionierten, wie ich es getan hätte erwartet. Ermittlungen fortsetzen – Sean

+0

Ich verstehe, nur einen Versuch. Die Änderung ist in contentType "" application/x-www-form-urlencoded "" einen Blick auf diesen Beitrag http://stackoverflow.com/questions/4007969/application-x-www-form-urlencoded-or-multipart- Formulardaten –

5

Habe endlich auf den Grund davon und während die Antwort nicht für alle mit dem gleichen Problem gelten kann; Ich würde vorschlagen, dass der Schlüssel in der Tatsache lag, dass wir Informationen von einer HTTPS-Site abrufen konnten, aber nicht alle und Ereignisse über eine Kombination aus Fiddler, WireShark und unserer Firewall verfolgten.

Öffnen der Websites in Google Chrome und Klicken auf das Vorhängeschloss für "https" in der URL-Adresse für die Website, um die "Sicherheitsübersicht" zu sehen, dass wir für die meisten Websites versucht haben, Einträge für " Gültiges Zertifikat 'und für' Sichere Ressourcen ', aber diese eine Site hatte auch einen Eintrag für' Sichere TLS-Verbindung 'und WireShark bestätigte, dass der Handshake (von Chrome) TLS V1.2 verwendet wurde wird nur mit .NET Framework 4.5 (oder höher) unterstützt, das daher Visual Studio 2012 (oder höher) benötigt

Wir führen derzeit .NET Framework 4.0 mit Visual Studio 2010

Heruntergeladene Visual Studio 2015 Community Edition zum Testen des "gleichen" Codes in einem Projekt mit .NET Framework 4.5.2 und es funktionierte sofort.