When my WebAPI client calling the host from the same computer and there is an Exception thrown, the client is able to retrieve the error message through the response.
If my WebAPI Client calling the host within a local lan (but different computer). I only able to receive "internal server error" without the message.
May I know what is the best way to tell WebAPI NOT to filter the exception messages?
I have tried Owin IExceptionHandler but without success (I can only process / log the error). I can't figure out a way to forward the exception message to my client.
Thanks in advance
The client will be able retrieve the exception message if customErrors mode is set to Off in Web.config
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
This technique can be used only in development environment, not in production or some other secure environment.
Click here and here for WebAPI exception handling details.
Related
I have a proxy service which does service callout to business service to PUT data to a Rest endpoint.
When i tested the business service the PUT was successful and got 201 response.
When i tested the proxy service ,PUT failed with 400 bad request fault.I'm using same request payload and outbound for both cases
How come the same payload gives success response from business service and fault when tested via proxy service.
Is it possible that the proxy service alters the payload when passing it to business service internally? Please help.
The issue was fixed by disabling the "use chunked streaming mode" option in transport configurations page of business service.
Suppose, UI is making calls to rest service and the server stops.
Does UI come to know about the server's state?
Does UI get any response back from the server?
What difference does it make if the rest call was POST or PUT?
When REST Api is stopped,the UI/Browser/Client will show "Could not get any response
There was an error connecting to " error, irrespective of request type: PUT /POST.
To answer your questions :
Does UI come to know about the server's state?
If Server stops, you will get an error like : error connecting server. Which can be traced to multiple rootcauses. One of them can be : Server has stopped.
In case of error, Server's state can be sent to client using various error codes like:
500 Internal Server Error The 500 status code, or Internal Server Error, means that server cannot process the request for an unknown reason. Here is list of status codes for REST APis: https://www.w3.org/Protocols/HTTP/HTRESP.html
Does UI get any response back from the server?
If server is stopped, UI/Client will receive no response.
What difference does it make if the rest call was POST or PUT?
If the server has stopped, it doesn't make any difference.
You can run this scenario using a browser and running any app/REST service in your local machine.
(For this test you need not have any REST application running in your local, as you only want to test when it is stopped)
For instance, if your REST application server is up and available at port 8080, you can send request to this server by sending request form your browser : http://localhost:8080
For testing with POST/PUT collections, you can use any API Development tools like : Postman.
Let's assue your REST Api , exposes following urls :
/myPostRequest POST
/myPutRequest PUT
When you hit these urls from POSTMAN you get the same response :
POST http://localhost:8080/myPostRequest :
Could not get any response
There was an error connecting to http://localhost:8080/transition-order.
PUT http://localhost:8080/myPutRequest :
Could not get any response
There was an error connecting to http://localhost:8080/transition-order.
Client(could be UI) and Server are two dumb applications. They do and say what they are told to.
So whenever a client tries to call a server on a socket and there is no server listening to it, there is no response returned to the client. The client can interpret it in whatever way it wants. Most of the browsers show <host> refused to connect.
But if a server is listening to a socket, it responds to the client whichever way it was programmed to do. The server sends an appropriate status code and expects that the client knows how to interpret it. A server can send any random number it wants... the catch is, the client must know how to interpret it. otherwise, it's just one-way communication.
In order to provide smooth client-server communication, section 10 of RFC 2616 defines various codes with specific meaning as shown here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
These status codes are the same for all the types of Http methods.
Usually on the WCF server side I would inherit BehaviorExtensionElement and add IServiceBehavior, which in turn would add IErrorHandler to all ChannelDispatchers to log all unhandled exceptions.
It works just fine for all the exceptions but this: SecurityNegotiationException which happens when client tries to connect with credentials which server doesn't know about (e.g. server is in one windows domain and client is in another windows domain, thus server can't authenticate client and client receives SecurityNegotiationException with error message "The server has rejected the client credentials").
The question is: how can I catch such exceptions (SecurityNegotiationException) on the server side?
I am new to Mule ESB and today I have some experiences with pattern configuration. And I still don't know what is the difference between pattern:web-service-proxy and pattern :http-proxy. Because,I only see that both of these pattern could redirect inbound-address to outbound-address. And one more problem, this config could run well, I could jump to soap web service
<pattern:http-proxy name="http-proxy-sample-2">
<http:inbound-endpoint address="http://localhost:9001/pattern/httpproxy2" />
<http:outbound-endpoint address="http://localhost:9000/services/soap" />
</pattern:http-proxy>
However, I'm unable to run this:
<pattern:http-proxy name="http-proxy-sample-2">
<http:inbound-endpoint address="http://localhost:9001/pattern/httpproxy2" />
<http:outbound-endpoint address="http://google.com" />
</pattern:http-proxy>
Maybe I have misunderstood here, someone please give me some advises.
Though they both serve a similar purpose at core (proxy HTTP requests) these two patterns are very different:
pattern:web-service-proxy is focused on proxying SOAP-style HTTP requests and as such supports auto-rewriting remote WSDLs so their service address uses the proxy address. It is mainly designed to support GET for WSDL requests (detected if the inbound path ends with ?wsdl) and POST for SOAP requests.
http-proxy is focused on generic HTTP requests proxying. It doesn't recognize WSDL requests but it is able to forward inbound headers and paths to the remote address. For example if the proxy listens on /proxy calling it with /proxy/users/1 will append /users/1 to the configured outbound path.
Now why does your second http-proxy fails? No idea: you need to provide more information about the issue you are experiencing with it.
Many WCF services hosted in one windows.
When windows service is just running, the wcf service endpoints are working well. After a long-time running, the wcf service is down. Though, this time the load is not heavy but instead, the services down.
After down, when I visit the endpoint through Internet browser or client app, they both throw the following exception.
System.ServiceModel.EndpointNotFoundException:
There was no endpoint listening at http://serviceip/servicename that could accept
the message. This is often caused by an incorrect address or SOAP action. See InnerException,
if present, for more details. ---> System.Net.WebException: The remote server returned
an error: (404) Not Found.
I have no idea about this problem. Do anyone know anything about this, pls help.
thanks in advance.
This usually means that your parameters are out of sync or the hosting service may have been modified. Check and make sure your parameters case (if the host is case sensitive) and then ensure you are passing the correct values.
Can you try to turn on tracing on WCF services http://msdn.microsoft.com/en-us/library/ms733025(v=vs.110).aspx?