WebHttpBinding swallows details of FaultExceptions with 400 Bad Request?
If I expose an endpoint using the WebHttpBinding when I throw a FaultException the details of that exception are completely lost in the response. Instead all I get is 400 Bad Request with a generic "see server log for details" HTML message. I would expect that at least the reason text should be returned somewhere in that message. In fact I'd actually expect a lot more if I threw a FaultException<T> that included custom fault detail. I would expect that fault detail class to be serialized and returned in the response body instead of the canned HTML.
Please note, this is with includExceptionDetailsInFaults="false" because obviously you wouldn't want that turned on in a production environment. Also please note the effect is the same whether the endpoint is POX or JSON. In fact only endpoints with ASP.NET AJAX compatibility (i.e. the EnableWebScriptBehavior applied) returns the reason to the client in the error's message property (which, btw, is awesome because 1.0 of the System.Web.Extensions didn't return this unless customErrors="Off").
Thanks,
Drew
Answers
Hi, Drew
After more investigation, it turns out to be by design. This happens because webhttpbehavior add its own error handler which changes the fault message. So the recommended way of return fault is derive from webhttpbehavior and override AddServerErrorHandlers, where you hook up your own error handler and it can return your faultexception be doing something like below
MessageFault messageFault = MessageFault.CreateFault(FaultCode.CreateReceiverFaultCod
e(blahExceptionName, blahExceptionNamespace),new FaultReason(new FaultReasonText[] { enUsText, enCaText, enGbText }));
fault = Message.CreateMessage(MessageVersion.None, messageFault, blahExceptionAction);
All Replies
On a similar note, wouldn't it make sense for FaultExceptions to cause a 400 (as they do), but non-FaultExceptions to cause a 500 so that one can differentiate between something being logically wrong with the details of the request vs. something unexpected went wrong when processing the request?
Food for thought...
-Drew
Hi, Drew,
Thanks for the feedback. After compare with with V1 behavior, I think this is a bug, I'll confirm it with the feature owner and update you.
About the statuscode, current expectation is leave it to each developer to decide by adding their own IErrorHandler and change it through the weboperatoncontext. Default error handler will set status to 404 if there is endpointnotfound exception and 405 if method signature mismatch.
thanks
Joe
Hi, Drew
After more investigation, it turns out to be by design. This happens because webhttpbehavior add its own error handler which changes the fault message. So the recommended way of return fault is derive from webhttpbehavior and override AddServerErrorHandlers, where you hook up your own error handler and it can return your faultexception be doing something like below
MessageFault messageFault = MessageFault.CreateFault(FaultCode.CreateReceiverFaultCod
e(blahExceptionName, blahExceptionNamespace),new FaultReason(new FaultReasonText[] { enUsText, enCaText, enGbText }));
fault = Message.CreateMessage(MessageVersion.None, messageFault, blahExceptionAction);
Hi Joe,
When using WebHttpBinding with web script enabled WebScriptEnableBehavior is used. WebScriptEnableBehavior is a sealed class. Maybe you can help to explain what the motivation was for such a design decision? It is reasonable to expect that the basic fault information be returned without having to enable IncludeExceptionDetailsInFaults. Is there any other workaround?
- I think this is exactly what you and many of us want.
http://www.zamd.net/2008/07/08/ErrorHandlingWithWebHttpBindingForAjaxJSON.aspx

