I have stumbled across an insane behavior of WebClient where it throws WebException on 404 code.
This behavior is wrong because the 404 code can be returned with content data like in the case of Facebook: https://graph.facebook.com/sadfsa.dsadsasadsa
So this code throws an exception
var json = webClient.DownloadString("https://graph.facebook.com/sadfsa.dsadsasadsa");
How do I read the json returned by 404 Facebook?
I don't think that WebClient has insane behavior. Try to catch WebException and read webException.Response.GetResponseStream
See a similar question: C# WebException how to get whole response with a body?
Related
I am creating a C# windows form that is designed to access websites and display their HTML. However, the methodology that I am using seems to only be working with sites that don't include www. (or at least I think that's what's happening.) I'm not very good at this sort of thing, so I apologize if I missed something obvious. Many thanks in advance, here's the code:
string urlAddress = "https://www.pintrest.com"; //using Pinterest for testing
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(urlAddress);
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
The error I keep getting is:
An unhandled exception of type 'System.UriFormatException' occurred in System.dll
Additional information: Invalid URI: The format of the URI could not be determined.
I don't understand what is wrong with that URL. What's going on?
What would be the correct way of handling errors in communication between a C# client app and Node.js server? My solution was to send status code 400 or 500 and error message in the response body, but WebRequest seems to not receive the body message when status code implies an error. I need to read this error message to show for the user the correct info about the error.
I guess typically server would throw WebRequestException which could pass the error message, however I have no idea how to throw such error from the Node.js app.
I cannot change the status code to 200 and read error from the body because previous versions of the app would not handle it correctly.
Well, I figured it out. In the client, in the catch block, when WebRequestException is thrown because of the error status code, you can still begin receiving the response (the response is in this exception).
My bad. :)
One of our clients is causing this error when we call their web service. I'm trying to figure out how to help them. I'm not sure if they are sending the MIME-type wrong specifically, or if the error is being caused because the response begins with the "HTTP/1.1 200 OK" instead of beginning immediately with <?xml>. I don't know too much about this client/service binding.
Exception captured is:
"Client found response content type of 'application/octet-stream', but expected 'text/xml'. The request failed with the error message: -- HTTP/1.1 200 OK Content-Type:text/xml; charset=utf-8 Content-Length:1056"
The rest of the exception lists the entire xml, soap:envelope, soap:body and actual object tags that looks perfectly fine.
Our call is made by .NET 1.1.
I have an application which sometimes must do some requests to the server to see that those requests are properly blocked. In other words, the expected server answer is 403 Forbidden.
With a piece of code like this:
HttpWebRequest httpRequest = (HttpWebRequest)WebRequest.Create(protectedPage);
httpRequest.Method = WebRequestMethods.Http.Head;
WebResponse response = HttpRequest.GetResponse();
a WebException is thrown on the last line.
When profiling code, this exception in a try/catch block has a performance impact which I want to avoid.
Is there a way to check for server response, expecting a 403, without having to catch an exception (but avoiding using sockets directly)?
Unfortunately, this is a vexing exception in the framework, and there's no way to avoid it (while still using the HttpWebRequest class). But, as High pointed out, this exception handling will take nanoseconds, while the web request itself will take milliseconds (at best), so don't worry about it.
The WebException object has a Response property that contains the response; when you handle the exception, it's important to dispose that WebResponse object (to avoid leaking connections).
What's taking time in the profiling is probably not the exception catching part but the actual response from the web site.
The WebException.Status property will give you the status code for the HTTP response and you can do further processing based on that.
I have a routine that submits a SOAP request using HttpWebRequest and WebResponse. If the SOAP Request fails the server sends back HTTP/1.1 500 Internal Server Error. When I trap the error I have yet to find a way to view the body of the reply which contains the fault code.
Is there a way to retrieve the message body when the server returns a 500 internal Server Error?
In body of the reply which I am not able to retrieve.
faultstring xml:lang="en-US" Specified argument was out of the range of valid values.
I haven't time to test this, but a WebException will be thrown in this situation.
You can get access to the error response via the WebException.Response property.
You will then be able to access information from the respons, e.g. you could try calling WebException.Response.GetResponseStream() to get the body of the response.