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.
Thank You
Your request was successful
Download data sheets, case studies and other resources Access Resources
Stay connected with Atmosera Manage Email Preferences