Atmosera

Silverlight 3’s New Client Networking Stack

One of the most useful yet little-known new features of Silverlight 3 is one that has nothing to do with UIs: a brand new networking stack called the client HTTP stack, the client networking stack, or simply the client stack.

Silverlight 2 introduced rich networking to Silverlight. With classes such as WebClient and HttpWebRequest, you could call Web services, perform duplex networking, consume RSS, perform asynchronous downloads of images, assemblies, and other assets, and more. In Silverlight 2, all networking was performed using the browser’s HTTP stack—in other words, Silverlight used the networking APIs exposed by the browser. This insulated Silverlight from the underlying operating system, but it also placed some annoying limits on what Silverlight could do. In Silverlight 2, for example, SOAP faults couldn’t be propagated back to the client because the browser converted the HTTP 500 error codes accompanying those faults into HTTP 404 (“Page Not Found”) errors. And in Silverlight 2, you were limited to the HTTP commands GET and POST because some browsers impose similar limits in their networking APIS.

In Silverlight 3, networking is still performed using the browser’s HTTP stack by default. But the new client stack allows you to bypass the browser and do your networking through the operating system. The table below lists important differences between the browser stack and the client stack. With the client stack, for example, SOAP faults can be handled properly since the operating system doesn’t alter HTTP response codes. And with the client stack, you can use additional HTTP commands such as PUT and DELETE because while browsers may not expose that capability, operating systems do.

Using the client stack is simple because it doesn’t require you to learn a new API. The following statement tells Silverlight that all subsequent calls to addresses that begin with “http://” should use the client stack rather than the browser stack:

HttpWebRequest.RegisterPrefix(“http://”, WebRequestCreator.ClientHttp);

If you want to use the client stack to make calls to https:// addresses, too, you can add this line of code:

HttpWebRequest.RegisterPrefix(“https://”, WebRequestCreator.ClientHttp);

You can also be more specific about the addresses. The following statement, for example, tells Silverlight to use the client stack for calls to http://www.contoso.com:

HttpWebRequest.RegisterPrefix(“http://www.contoso.com”, WebRequestCreator.ClientHttp);

You can call RegisterPrefix as many times as you like to designate which calls should use the client stack. After that, all calls to addresses with the designated prefixes, whether placed through HttpWebRequest, WebClient, or Web service proxies, will bypass the browser and go directly to the operating system. Calls to other addresses will still use the browser stack as normal.

It’s also possible to create an HttpWebRequest object that will use the client stack for all calls placed through it, regardless of the address prefixes you have (or have not) registered. Here’s an example:

HttpWebRequest request = (HttpWebRequest)WebRequestCreator.ClientHttp.Create(new Uri(“http://www.contoso.com”, UriKind.Absolute));

And you can find out at run-time whether a given HttpWebRequest object uses the browser stack or the client stack this way:

if (request.CreatorInstance == WebRequestCreator.ClientHttp)

{

// Client stack

}

else if (request.CreatorInstance == WebRequestCreator.BrowserHttp)

{

// Browser stack

}

There are downsides to the client stack, to be sure. For example, if you download an image with a WebClient object that uses the browser stack, the image will be cached just like any another image. If you do the same with the client stack, the image won’t be cached because the browser doesn’t know the image was downloaded. Despite these drawbacks, the client stack is a welcome addition to Silverlight because it removes many of the inherent limitations of the browser stack. And in the future, the client stack can be expanded to support features that today neither Silverlight 2 nor 3 supports.

Jeff Prosise

Next Silverlight Behaviors and Triggers: Making a True Behavior »

Previous « Using .NET 4.0 Tasks with the AsyncEnumerator

View Comments

Anonymous says:

October 15, 2009 at 7:50 am

Hi Jeff - woohoo! Indeed that's fantastic news, I haven't heard of that before. Had some trouble working around the restriction in the past...
Just one question: Is it really correct that the default browser connection limit is 2? I thought with IE7 it was upped to 6 per domain.
Thanks!
Anonymous says:

October 15, 2009 at 8:02 am

Thank you for submitting this cool story - Trackback from DotNetShoutout
jprosise says:

October 15, 2009 at 8:43 am

The default concurrent connection limit is 2 in IE7, but I believe it was upped to 6 in IE8.
Anonymous says:

October 15, 2009 at 2:58 pm

Are there not some restricted headers, still ?
http://msdn.microsoft.com/en-us/library/system.net.webheadercollection(VS.95).aspx
jprosise says:

October 19, 2009 at 8:50 am

It's true that many headers are still restricted for security reasons. However, now that the technical limitation preventing additional headers from being exposed has been removed, the team at least has the option of unrestricting some of those headers in the future.
Anonymous says:

October 27, 2009 at 7:45 am

Jeff, does this mean the we can use the client stack to make calls to web services and take advantage of the asp.net authorization attributes? I'm having an awefull time trying to figure out how to secure the web services from being called by unauthorized connections.
Thanks,
Steve
Anonymous says:

November 27, 2009 at 1:22 am

Hello Jeff,
I'm still not able to get different response code from 200 or 404 in Silverlight 3.
I'm using an statement like
HttpWebRequest.RegisterPrefix("http://www.contoso.com", WebRequestCreator.ClientHttp);
and seen the response in Fiddler I see the nice 500 HTTP Error code but in Silverlight it shows as 404 - Not Found.
Have you seen it working ?
Please refer to this forum.
http://forums.silverlight.net/forums/p/139636/311898.aspx#311898
Thanks.
Anonymous says:

December 17, 2009 at 1:47 pm

Hello Jeff,
Can we get Cookies from Clientstack
IWebRequestCreate creator = WebRequestCreator.ClientHttp;
// Register both http and https.
WebRequest.RegisterPrefix("http://", creator);
WebRequest.RegisterPrefix("https://", creator);
//HttpWebRequest connrequest = (HttpWebRequest) WebRequestCreator.ClientHttp.Create(new Uri(strURL));
connrequest.Headers["SqlAuthorization"] = "Basic " + Convert.ToBase64String(Encoding.UTF8.GetBytes(UserName + ":" + Password));
connrequest.CookieContainer = new CookieContainer();
connrequest.BeginGetResponse(ResponseCallback, connrequest);
async call
{
HttpWebRequest request = (HttpWebRequest)ar.AsyncState;
HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(ar);
}
from above "response", i could not able to see Cookies , and always Cookies count shows as ZERO.
Is ClientHttp support Cookies?
Anonymous says:

January 13, 2010 at 8:01 pm

I specified the
bool registerResult = WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
but still get following error
Message: Unhandled Error in Silverlight Application Unable to set the CookieContainer. Please make sure the binding contains an HttpCookieContainerBindingElement. at CompanySilverlightApplication.AuthenticationService.AuthenticationServiceClient.set_CookieContainer(CookieContainer value)
at CompanySilverlightApplication.News.News_Loaded(Object sender, RoutedEventArgs e)
at System.Windows.CoreInvokeHandler.InvokeEventHandler(Int32 typeIndex, Delegate handlerDelegate, Object sender, Object args)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
Line: 1
Char: 1
Code: 0
Anonymous says:

February 11, 2010 at 4:32 pm

HttpCookieContainerBindingElement. at CompanySilverlightApplication.AuthenticationService.AuthenticationServiceClient.set_CookieContainer(CookieContainer value)
at CompanySilverlightApplication.News.News_Loaded(Object sender, RoutedEventArgs e)
at System.Windows.CoreInvokeHandler.InvokeEventHandler(Int32 typeIndex, Delegate handlerDelegate, Object sender, Object args)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, String eventName)