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("http://", 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(;


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 (9)

  1. SharpGIS says:

    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.

  2. suntsu says:


    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?



  3. jumbo_peterk says:

    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.


  4. In response to the comments…


    What doc says the browser will send the Referer header?


    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 For web service questions, check out:

  5. SharpGIS says:

    cherylws: This doc in the first table:

    It’s causing us a lot of issues with token-based authentication where the token authenticates a domain for using a service.

  6. SharpGIS says:

    …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.

  7. 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:



  8. SharpGIS says:

    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."

  9. 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.