My web service call sometimes results in CommunicationExceptions due to the fact, that the called service returns an invalid SOAP response. The exception message is:
Server returned an invalid SOAP Fault. Please see InnerException for more details.
The inner exception has the following message:
No characters can appear before the XML declaration. Line 10, position 21.
But how to obtain the response so I can log it and see myself what kind of malformed XML has been returned?
Enable message logging: https://msdn.microsoft.com/en-us/library/ms730064(v=vs.110).aspx
You might be interested in `logMalformedMessages' attribute.
If you don't see anything useful on the client side you can try enabling the same on the server side to see what messages are leaving the server.
Related
I am writing a new API and documenting it using Swagger/OpenAPI. It seems to be a good standard to document error responses, that the developer can expect to encounter.
But I cannot find any guide lines or best practices about Internal Server Error. Every path could in theory throw an unhandled exception. I do not expect it to happen, but it might. Should all paths have a response with status code 500 "Internal Server Error" or should I only document responses the developer can do anything about, i.e. 2xx, 3xx and 4xx?
The offical documentation shows an example for specifying all 5xx status codes in the responses section, but it does not go into details about the specific status code, or the message returned. It also mentions that the API specification should only contain known errors:
Note that an API specification does not necessarily need to cover all possible HTTP response codes, since they may not be known in advance. However, it is expected to cover successful responses and any known errors. By “known errors” we mean, for example, a 404 Not Found response for an operation that returns a resource by ID, or a 400 Bad Request response in case of invalid operation parameters.
You could follow the same approach and specify it like in the example. I think it's not important or even recommended to try to describe it more specifically, since you might not be able to cover all cases anyway and the client is not expected to act on the message returned for internal server errors (possibly other than retrying later). So for example, I would not recommend specifying a message format for it.
Omitting any responses with 5xx HTTP error codes makes sense as well.
I have a Back-to-Back call from caller to our ucma server to client/operator. When doing a transfer on the leg from caller to ucma, there are a few different results which can happen; the transfer target answers, doesn't answer or ignores the call (ignore/busy button).
I want to differentiate between the later two; busy and no answer. In the ucma application I only get a FailureRequestException with text "The transfer operation failed. For more information, refer to the message data in the exception."
I cannot figure out anywhere in the exception or otherwise how to know the difference between busy and no answer. Both generates the same exception with no obvious parameter saying whichever it is.
Is there any way I can know the reason the transfer failed in this scenario?
I'm not sure if this will help, but if you can get the final non-provisional status code for the invite, a "ignore" end will be a 603. A no answer will be a "480" - altho a 480 (Temporarily Unavailable) can be returned for lots of other reasons.
Also the situation can be confused if the user has more than one endpoint (e.g. Desktop Lync Client and Mobile Lync Client). So you end up with forked requests / responses with only one overall response back to you. Then you may not always be able to tell exactly why the call was terminated.
I actually find it funny you are saying you get a FailureRequestException.
I would be expecting a FailureResponseException. With a FailureResponseException exception you can pull out the status code.
From the UCMA 4.0 exception model msdn page:
FailureResponseException
Thrown when a 4xx, 5xx, or 6xx response was received for a request. This exception contains the ResponseData property, which
contains the complete response including response code, reason text,
headers, and message body. In some rare cases, this may also be thrown
when an error other than a 4xx, 5xx, or 6xx response occurred. In such
cases the ResponseData property is null.
Let's say that a request is sent to server via xhrPost and server finds that request needs more information to be processed (for example a variable is missing), so, a response is sent back to client informing that request may have not been completely processed and this message is shown in a dialog box.
I was doing it sending from server an HTTP 202 status code, which I believe is not correct, and treating it on load function, where this message was displayed on a dialog box. But if I respond with some HTTP error code (ex: 400) the error is displayed in console (Note: in this case the message is treated in error function), as well as in my dialog box.
What is the best and correct way to do it?
Note that it is called a load handler, not a success handler.
The load hander is for valid, well formatted responses. These can contain a verity of status codes generated by your server side app that indicates success, failure, or something in between.
The error is just that, the server blew up while trying to process the request and whatever you get back is probably not something your widget was written to expect. For this reason, I recommend using the same error handler across your whole app.
The dojo documentation states:
Sometimes xhrGet calls will fail. Often these are 404 errors or server errors such as 500. The error parameter is another callback function that is only invoked when an error occurs. This allows you to control what happens when an error occurs without having to put a lot of logic into your load function to check for error conditions. The first parameter passed to the error function is a JavaScript Error object indicating what the failure was. Dojo doc
We all are know some time we will get 500 error while trying to hit wcf url. for example if pass string value to integer parameter it will throw 500 error as request error. my question is how to log, this kind error in some file? because this will not reach our actual end point class coding right? so how to log this error in some file?
Any Help?
Assuming you want to log these on the server size, you should configure WCF tracing and use SvcTraceViewer to analyze the logs. More details on MSDN: http://msdn.microsoft.com/en-us/library/ms732023.aspx.
I may very well be wrong here - but if the client is supplying the wrong parameters to a web method, that would be a 404 as no method matches the incoming request?
I would say it's the clients job to send the right data to the right function, and to handle failures appropriately (an EndPointNotFoundException perhaps)
In my RESTful services layer, any exceptions that bubble up to me are caught as Fault Exceptions. Within that FaultException, there's a custom XML message that contains <errorNumber>, <errorCode> and a <message>. I re-package the exception as a WebFaultException so I can set the HttpStatusCode for the response header to 400, 401, 404, etc.
However, I don't want to use WebFaultException<string>(string message, HttpStatusCode code). I want the message to also be an XML message.
Anyone seen how to set the HttpStatusCode of the response message AND set an XML message? I'm using Fiddler to examine my response headers and any messages that come up from the service.
What I did to get around this was create a new class MyException with simple properties and used WebFaultException<MyException> and it works nicely. I found the solution at the following link: http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx