New networking stack in Silverlight 3

In previous versions of Silverlight, the browser handled all the HTTP communication for the Silverlight plug-in. The browser HTTP stack works well but has some limitations including the HTTP methods you can use and the response codes that are accepted. In Silverlight 3, you can opt-in to have the Silverlight client perform the HTTP handling. By opt-in, I mean, if you don't specifically choose the client to perform HTTP processing, it will be done by the browser, just like it always has been. However, if you decide you need to call REST services, you can easily do this with Silverlight3 by opting in to the client HTTP stack.

Here’s a table that summarizes some of the basic HTTP capabilities of Silverlight 3 and whether browser or client HTTP handling supports the capability.

Specifying the HTTP stack is easy. You simply call the WebRequest.RegisterPrefix method, passing the ClientHttp object to specify client HTTP handling or a BrowserHttp object to specify browser HTTP handling. You do this before you make any web requests. One important thing to remember is that once you have specified the client or browser HTTP stack for a particular domain or scheme, you can’t change it.

The following code shows how to specify client handling all HTTP and HTTPS requests and responses.

bool httpResult = WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);

bool httpsResult = WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);

You can also use the WebRequest.RegisterPrefix method to register a specific domain. The following code shows and example of how to do this.

HttpWebRequest request = (HttpWebRequest)WebRequestCreator.ClientHttp.Create(new Uri( https://api.search.live.net/qson.aspx?query=Silverlight));

 

For more details (and VB code) on specifying Client or browser HTTP handling, see How to: Specify Client or Browser HTTP Handling.

For more details on general HTTP capabilities and how to make HTTP requests with Silverlight, plus some security considerations if you are hosting Web services for Silverlight clients, see HTTP Communication and Security with Silverlight.

Comments

• Anonymous
  August 16, 2009
  Would this fix the broken (missing) Referer issue that Silverlight has? You can't set the referer header yourself, the doc says that the browser will do that for you, but I still to this day haven't seen a single request from Silverlight that contains the referer in any browser. This both for WebRequest and types of requests like for instance Image Source that links to image files directly.

• Anonymous
  August 17, 2009
  Hi I have authentication with ntlm or kerberos in my silverlight application. If i now Register the http protocol, i get an 404 not found as replay for every wcf call.                //NTLM binding                BasicHttpBinding basicNTLMBinding = new BasicHttpBinding();                basicNTLMBinding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;                basicNTLMBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Ntlm;                ServiceEndpoint ntlmEndpoint = serviceHost.AddServiceEndpoint(typeof(IService1), basicNTLMBinding, "http://notebook17:666/PureWCFService2/ServiceNTLM");                ntlmEndpoint.Behaviors.Add(new MyFaultBehavior()); Is it still possible to use ntlm/kerberos authentication when using this WebRequest.RegisterPrefix? cheers manuel

• Anonymous
  August 19, 2009
  Hello, I tried this. Silverlight now has some information about the fault. But the only info I have is type of the exception (in the SomethingCompletedEventArgs.Error.Message; SoapException in this case). But I can't find any text from the exception... e.Error.InnerException is null. Where should I look? (I am consuming the Sharepont services...). Thanks for advice. Petr

• Anonymous
  August 19, 2009
  In response to the comments... SharpGIS, What doc says the browser will send the Referer header? Petr, Have you looked at the body of the returned message for more details on the error that occurred? The best way to get answers to these kinds of questions is to post them to the forums on Silvrlight.net. For web service questions, check out: http://silverlight.net/forums/46.aspx

• Anonymous
  August 25, 2009
  cherylws: This doc in the first table: http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest(VS.95).aspx It's causing us a lot of issues with token-based authentication where the token authenticates a domain for using a service.

• Anonymous
  August 25, 2009
  ...I also noticed that when switching to ClientHttp, you loose the gzip encoding (the client doesn't tell the server that it supports it using the Accept header). So I think it's worth noting that there is a potential performance hit here.

• Anonymous
  August 31, 2009
  SharpGIS, The page you pointed me to is for the .NET Framework. The Silverlight-specific page does say the Referer header is set by the Web server. It is confusing because the API names are the same, but there are implementation differences between the .NET Framework and Silverlight. To make sure you are on the correct page, use the hints in this blog post: http://blogs.msdn.com/silverlight_sdk/archive/2009/02/11/what-doc-set-am-i-in.aspx Regards, Cheryl

• Anonymous
  November 06, 2009
  Cheryl: That's because your blog is broken. It didn't create a link correctly, so the (VS.95) didn't get included. Copy paste the link instead, and it will link to the SL doc. And even so, did you even check the SL doc? It says pretty clear that Referer is set by browser: "Referer : Set by the web browser that hosts the Silverlight application."

• Anonymous
  December 02, 2009
  SharpGIS-Sorry yes, you are correct. The doc says the Referer header is set by the web server and it's not set. This feature was added for Silverlight 4. I'll let the author of the doc know he's got an error. Cheryl