New features in Silverlight 3: Networking and Communication

In new version of Silverlight there are some changes in communication. I’ll write about them.

Browser or Client HTTP Handling

You can specify whether the browser or the client provides HTTP handling for your Silverlight-based applications. By default, HTTP handling is performed by the browser. In addition, you can specify the scope for the handling: all messages, a scheme (HTTP or HTTPS), a particular domain, or a single request object.

Typical scenarios with client HTTP handling:

• Using HTTP methods other than GET and POST.

• Using response status codes headers, response bodies in your application or for debugging purposes.

• Sending XML HTTP requests such as REST and SOAP messages.

• Manually managing cookies.

SOAP Faults

There are two ways to enable SOAP fault consumption:

• You can modify your service to return SOAP faults with an HTTP status code of 200. This will make the service non-compliant with the SOAP protocol, since SOAP requires a response code in the 400 or 500 range for faults. If the service is a WCF service, you can create an endpoint behavior that plugs in a message inspector that changes the status code to 200. Then, you can create an endpoint specifically for Silverlight consumption, and apply the behavior there. Your other endpoints will still remain SOAP-compliant.
• You can register client HTTP stack using the RegisterPrefix method. Client HTTP Handling allows you to process SOAP-compliant fault messages. However, a potential problem of switching to the alternative HTTP stack is that information stored by the browser (such as authentication cookies) will no longer be available to Silverlight, and thus certain scenarios involving secure services might stop working, or require additional code to work.

Message Credentials Authentication

A small subset of the WS-Security protocol is supported, namely, the ability to send username and password tokens in messages. When message credentials authentication is used in Silverlight, every request message will contain a SOAP header that conforms to the WS-Security protocol. The header will contain an unencrypted token with a user name and a password. You must provide them in your Silverlight code. Because the user name and password credentials are sent in plaintext (that is, unencrypted) form, you must use a secure transport (such as HTTPS) to prevent attackers from stealing the credentials while they are in transit. If you attempt to use this feature with a non-secure transport (such as HTTP), an exception will be thrown.

Other changes

• Binary XML (binary encoding,  default encoding in Silverlight-enabled WCF Service VS template)
• SLsvcutil.exe
• Proxy in PollingDuplexHttpBinding

More information you can find here

• http://msdn.microsoft.com/en-us/library/dd920295(VS.95).aspx
• http://msdn.microsoft.com/en-us/library/dd470117(VS.95).aspx
• http://msdn.microsoft.com/en-us/library/dd470118(VS.95).aspx
• http://msdn.microsoft.com/en-us/library/dd470096(VS.95).aspx
• http://msdn.microsoft.com/en-us/library/dd470105(VS.95).aspx
• http://msdn.microsoft.com/en-us/library/dd833059(VS.95).aspx

I have build two samples for SOAP Faults and username authentication. I have made two versions each of them:  with  endpoint behavior and with client HTTP handling. BTW, I have little problem with reading error messages when I throw authentication or fault exceptions in username validator. Have you any idea how it should be done ?