Beim Download von JSON via HTTPS wird die Verbindung von Remotehost geschlossen
Hallo Leute,
ich versuche derzeit eine JSON-Datei mithilfe eines WebClients herunterzuladen. Folgenden Code benutze ich derzeit.
public static string downloadJSONData(string url)
{
try
{
WebClient client = new WebClient();
string result = client.DownloadString(url);
return result;
}
catch (Exception ex)
{
return ex.Message;
}
}
Leider bekomme ich dabei ständig folgende Exception:
Fehlermeldung:
[System.Net.WebException] = {"The underlying connection was closed: An unexpected error occurred on a send."}InnerException = {"Unable to read data from the transport connection: Eine vorhandene Verbindung wurde vom Remotehost geschlossen."}
Rufe ich die übergebene URL allerdings im Browser auf funktioniert es einwandfrei.
Kann mir jemand sagen an was das liegt bzw. wie ich es behebe?
LG
xFL0
Gib den User-Agent an, da es 99,9999% aller Webserver verlangen.
Ansonsten kontrollier zB mit Fiddler, was der Browser anders macht als Dein Webclient.
Wenn der Server ne aktive Kompression hat, dann musste sowieso den HttpWebRequest mit AutomaticDecompression verwenden.
Hinweis:
- Exception Handling macht man nicht mit einem
return - vermeide statische Methoden (sie sind nicht ordentlich testbar)
- in .NET schreibt man Methoden groß
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@TE
Würde hier auch vom fehlenden User Agent ausgehen.
Hier scheint der Webserver dir die Verbindung zu schließen, da du keinen User Agent hast.
Machen dir meisten Webserver so.
@Abt
Warum sollten statische Methoden nicht ordentlich testbar sein?
Kann ich nicht ganz nachvollziehen.
Wenn ich meine Methoden debugge, spielt es keine Rolle ob static oder nicht.
Oder beziehst du dich auf einen bestimmten Kontext?
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Warum sollten statische Methoden nicht ordentlich testbar sein?
Kann ich nicht ganz nachvollziehen.
Wenn ich meine Methoden debugge, spielt es keine Rolle ob static oder nicht.
Oder beziehst du dich auf einen bestimmten Kontext?
Wenn ich antworten darf:
Lets do a mental exercise. Suppose your application has nothing but static methods. (Yes, code like that is possible to write, it is called procedural programming.) Now imagine the call graph of that application. If you try to execute a leaf method, you will have no issue setting up its state, and asserting all of the corner cases. The reason is that a leaf method makes no further calls. As you move further away from the leaves and closer to the root main() method it will be harder and harder to set up the state in your test and harder to assert things. Many things will become impossible to assert. Your tests will get progressively larger. Once you reach the main() method you no longer have a unit-test (as your unit is the whole application) you now have a scenario test. Imagine that the application you are trying to test is a word processor. There is not much you can assert from the main method.
(http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/)
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
@LaTino
Soweit ich dies aber verstehe, geht es darum wenn man nur static Methoden verwendet.
Sehe ich in diesem Kontext dann zwar auch so, aber generell habe ich es noch nicht hinbekommen meinen gesamten Code nur mit static Methoden abzubilden 😃
Das wäre im Endeffekt auch eine zu statische Code Basis, die dann nicht flexibel wäre.
Dann bräuchte ich auch kein C# als Programmiersprache nutzen und könnte direkt wieder zu C :p
Aber dies ist ein anderes Thema.
Hoffe mal der TE meldet sich mit Feedback 😃
Würde gerne wissen ob das Problem gelöst ist.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Hallo ihr,
ich habe jetzt folgendes gestestet:
WebClient client = new WebClient();
client.Headers.Add("user-agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)");
string result = client.DownloadString(url);
Ergibt bei mir den gleichen Fehler wie vorher. Hab ich den User-Agent korrekt gesetzt?
Auch mit einem HttpWebRequest bekomme ich die gleiche Fehlermeldung
HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(url);
httpWebRequest.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
HttpWebResponse response = (HttpWebResponse)httpWebRequest.GetResponse();
Stream responseStream = response.GetResponseStream();
StreamReader sr = new StreamReader(responseStream);
string result = sr.ReadToEnd();
Vielen Dank für eure Hinweise, dass wusste ich nicht 😉 bin ja auch nur FISI und programmier eher selten. Das ganze ist aktuell noch eine unbedeutende Konsolenanwendung, welche nur zur Funktionsprüfung des Codes dient.
Dennoch frage ich mich warum die Verbindung geschlossen wird?
LG
Flo
Ansonsten kontrollier zB mit Fiddler, was der Browser anders macht als Dein Webclient.
@Abt
Warum sollten statische Methoden nicht ordentlich testbar sein?
Kurzfassung: statische Methoden lassen sich nicht mocken.
Du hast hier eine harte Dependency auf einen Webclient und eine Rückgabe einer Webseite.
Sowas gehört gemockt.
Machst Du das jetzt in einen Unit Test dann bist Du vom externen Resultat (und dessen Geschwindigkeit sowie Verfügbarkeit) abhängig.
Das wäre dann eher eine Sache für Integrationstests.
Ja; in gewissem Kontext können statische Methoden praktisch sein; aber das sind sehr sehr sehr wenige und niemals welche mit externen Abhängigkeiten.
Deine Frage sollte eher sein: "wann sind statische Methoden angebracht" - und nicht umgekehrt.
[Artikel] Unit-Tests: Einführung in das Unit-Testing mit VisualStudio
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@Abt
Was definierst du in diesem Kontext als externe Abhängigkeit?
Meinst du damit eben sowas wie WebClient Aufrufe, wo auf tatsächliche externe Aufrufe gewartet werden muss?
Wüsste nicht welchen Vorteil es dann hätte dies in eine Instanz Methode zu packen.
Wenn ich weiß ich habe X Methoden Aufrufe ohne eine Abhängigkeit zu einer Klasse, dann würde ich einen einfachen Aufruf über X Klassen auch in eine statische Methode packen.
Wenn es aber bestimme Stellen gibt, an denen ich noch zusätzliche Daten brauche, dann kapsele ich dies erst und nutze dann eine Instanz Lösung.
Soll natürlich nicht bedeuten, dass mein Code nur aus static Methoden besteht.
Aber wenn ich eben identischen Code habe, den ich an unterschiedlichen Stellen brauche, dann nehme ich eine Static Methode as Sicht des 3 Schichten Models.
Also Quasi eine Helper/Utility Klasse mit Static Methoden.
@xFL0
Lässt sich die Url über den Browser aufrufen?
Wenn ja, was sagt ggf. die Fehler Konsole/Fiddler?
Dann scheint das Problem doch wo anders zu sitzen, da der User Agent auf den ersten Blick gut aussieht.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Wüsste nicht welchen Vorteil es dann hätte dies in eine Instanz Methode zu packen.
Deswegen hab ich Dir [Artikel] Unit-Tests: Einführung in das Unit-Testing mit VisualStudio gegeben. Das sind Test-Basics.
Nun bitte wieder On-Topic.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Ich habe mir soeben Fiddler installiert.
Auf was genau muss ich da denn achten bzw. was soll ich vergleichen?
Ich kenne das Programm nicht und weiß nicht wo ich nachsehen muss.
Hallo xFL0,
Auf was genau muss ich da denn achten bzw. was soll ich vergleichen?
Ich kenne das Programm nicht und weiß nicht wo ich nachsehen muss.
Zum Beispiel hier Fiddler tutorial – How to use Fiddler 😃
Schau dir einfach den Request an den du mit dem Browser feuerst und dann feuer mit deinem Programm und vergleiche die beiden Request-Resultate.
Gruss
Coffeebean
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
Problem hat sich gelöst:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
Das musste vor den HttpWebRequest / oder auch WebClient gesetzt werden.
Diese Lösung hab ich bereits mehrmals gesehen, aber es funktioniert bei mir nur, wenn alle 4 ProtocolTypes angegeben werden.
Danke für euere Hilfe!