This is going to be a three parter. 🙂 Today, we’ll dig into the core networking capabilities of the HTTP stack for site of origin communication. In the next two parts, we’ll go deep into understanding our HTTP cross domain support.
Note: this tutorial has been updated for Silverlight 2 RTW.
So, You Want To Phone Home…
In Silverlight 2, by default, you are only able to talk back to your site of origin server. This is in line with the general browser sandbox, and is designed to prevent cross site forgery.
To determine if a HTTP request is going back to site of origin, we look at the deployment URI of the XAP and the request URI. Comparing these two URIs, 3 things must match:
- Same domain. http://foo.com is different than http://bar.foo.com or http://www.foo.com
- Same protocol. http://foo.com is different than https://foo.com
- Same port. http://foo.com is different than http://foo.com:8080
If all three things match, the request will be allowed to go out into the world. If they don’t, by default, we’ll disallow the request and throw an exception. (Cross domain policies will be covered in part 2 of this post series.)
What Can You Say to Your Site of Origin Server?
You can talk to your site of origin server with the below capabilities:
- Verb support: GET & POST
- Request header support: Most standard & custom headers
- Status codes: 200 (OK) or 404 (NotFound) only
Also, all the requests you send will have the “right thing happen” to them from a cookies and authentication standpoint. This is a result of us leveraging the hosting browser to make the HTTP request.
HTTP requests themselves are:
- Asynchronous only
Why Those Capabilities?
The above capabilities are the result of:
- Requirements for basic web services
- Restrictions in the underlying browser plug-in networking APIs
To implement our Silverlight HTTP stack, we use the browser plug-in’s networking APIs. The HTTP capabilities we expose are therefore bound by the common set of capabilities exposed by the browsers that Silverlight supports.
Note: There are other ways we could have implemented the networking stack. For instance, we could have proxied all calls through the browser’s XmlHttpRequest object. However, this would have imposed a site of origin restriction on the requests, and we wanted to enable cross domain communication to existing web services. Similarly, we could have gone directly to the operating system’s networking APIs, but then we would have lost the cookies and authentication integration with the browser. In the future, exploring multiple of these stacks to expose more capabilities is definitely a possibility, and is something we would like feedback on.
What APIs Should I Use?
There are two APIs in Silverlight for HTTP communication. The first is WebClient and the second is HttpWebRequest.
WebClient is a great API with a simple, events-based paradigm. You can use it to easily download or upload a strings and Streams.
For a download, WebClient does a GET request and then gives you back the result in the form you wanted. For an upload, WebClient does a POST and sends the data you passed it. It also automatically resolves relative URIs against the deployment URI of the XAP.
Sample: Downloading a string using WebClient
HttpWebRequest & HttpWebResponse
Sample: Sending POST request using HttpWebRequest
Feedback – We Love It
Do the capabilities of our HTTP stack satisfy your needs? What do you think of the API set? We’d love to hear your thoughts.
Stay Tuned for Cross Domain Support in Part 2….