Handling SOAP Faults In Silverlight

December 8, 2009

one comment

In the past, when we tried to connect from Silverlight 2 to WCF Services that threw exceptions (every now and then), we got the famous “Not found” Communication Exception.

The reason we didn’t get a SOAP Fault is that WCF returns SOAP Fault responses with a HTTP code of 500 – this is according to SOAP protocol, but the browser doesn’t allow 500 responses to be returned to Silverlight – it replaces them with a CommunicationException and thus hides the real fault that returned.

When we moved to Silverlight 3, Microsoft published the following article, describing how to workaround the browser’s block, using a Message Inspector in the WCF-side to replace HTTP 500 fault responses with a HTTP 200 fault responses, thus allowing Silvelright to get these messages.

But… this fix will make your WCF service not compatible with the SOAP protocol, not mentioning you’ll have a whole new inspector to manage (test, debug, maintain…), and you’re debug skill will need to improve (try using fiddler to find these errors when the return code is 200 and not 500 – no red lines !!).

There is another solution that isn’t discussed much, and doesn’t require making any changes in WCF – changing the HTTP Stack Silvelright uses for the services.

In Silverlight 3 a new HTTP Stack was released – the Client HTTP Stack. The Client Stack uses the OS directly to create network operations, instead of using the browser. The new stack can be used instead of the Browser’s HTTP Stack for http and https. There are some differences between the stacks, one of them being the Client’s stack ability to handle all types of responses, including HTTP 500 responses.

To use the Client Stack for a specific service, just add the following code at the beginning of your Silverlight application (just change the url):

HttpWebRequest.RegisterPrefix(http://localhost/services/serviceX,
WebRequestCreator.ClientHttp);

 
The above line of code will tell Silverlight to use the Client stack whenever a call is made to a URL with that prefix – all other calls will use the Browser stack. If you want all calls to go through the Client stack, use a prefix of “http://”

You can read more about the ClientHttp class here, or just come to the SDP (registration required), where I will talk about the Client stack and other changes made in Silverlight 3 & Silverlight 4 that improves Silverlight’s ability to use network resources.

There are going to be many cool stuff in the SDP lectures, straight from the PDC, I myself still haven’t decided which lectures to go to (WCF 4? ASP.NET 4? WF? many to choose from).

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

one comment

  1. haberman michaelDecember 8, 2009 ב 1:46 pm

    wow!!
    thank you ido,
    now i can see my exceptions!!

    Reply