I have a set of WCF services which I have been using with an ASP.NET MVC application so far. These service operations return a FaultException when the server has identified problem with what the client has submitted. For example:
if(string.IsNullOrEmpty(request.Name))
throw new FaultException<ValidationDictionary>(new ValidationDictionary());
This works great in my ASP.NET Application
catch(FaultException<ValidationDictionary> fault)
{
// Happy error handling.
}
However with Silverlight this all fails. The server returns a 500 status code with the faultexception (as expected) but to Silverlight this just looks like a duff response.
The following MS article indicates a (ugly) work around for this: http://msdn.microsoft.com/en-us/library/ee844556%28v=vs.95%29.aspx
This workaround makes the service transmit 200 status codes, even if there is a FaultException, so that the Silverlight client can get them. But this will mess up ‘normal’ clients of my service (my ASP.NET application, other users in the wild).
However, the point of services is to have seperation from your clients. I still want my services to return 500 status codes so that my ASP.NET application can detect the FaultExceptions and handle them. But I also want Silverlight to be able to handle them too.
Has anyone come up against this before?
We’re using the ugly 500 to 200 converter endpoint behavior (one of the options in the link you provided), it does work for pretty nicely in Silverlight. A quick windows form client appears to also understand that while the response codes are 200 (ok) I’m still seeing e.Error populated correctly.
Is there really any technical issues with 200 vs. 500 with the clients you’re using (ASP.NET)? If not, what’s the problem?
I’ve also used the alternate HTTP stack in Silverlight (the other options in that MSDN article) until recently. Using that fixed a lot of things (including the error returning if I recall correctly). We were using it since it provided consistent NTLM/Negotiate authentication regardless of the browser. I had to stop using it since it was decided that the lack of HTTP compression was a deal breaker. This would keep the service unchanged (500s on errors).