Jan 05

Windows 8 adventures: getting external data from a local server might not be as easy as you expect…

Posted in Windows8      Comments Off on Windows 8 adventures: getting external data from a local server might not be as easy as you expect…

After a couple of days playing with the Windows 8 controls (more about them in future post), I’ve decided that it was time to see how to get remote data through the WinJS.xhr helper. To make things really simple, I’ve decided to create an HTML page on the server which would be obtained through WinJS.xhr helper. I’ve ended up with the following code on my WinRT page’s DOMContentLoaded event:

 function (e) {
  WinJS.xhr({ url: http://localhost/samplepage.html })
 .then(handleResponse, handleError); },

The WinJS.xhr method expects an anonymous object which you can use to set several of the parameters associated with remote call (notice that his call ends up being performed by the XMLHttpRequest object). In our simple example, we’re only setting the URLfor the call (according to the docs, you can also set several other parameters)

The WinJS.xhr method returns, once again, a Promise objet. In this case, the handleReponse method will be called when everything runs without any glitches. If there are any problems, the WinRT runtime ends up calling our handleError method. In this case, both methods end up receiving an instance of the XMLHttpRequest object used for performing the call.

The first time I’ve ran my demo app, it took a while until… my error handler got called. Initially, I thought that the URL was wrong, so I’ve copied it and pasted it into the URL address of Chrome. Nop, there was nothing wrong with the HTML. So, I’ve went ahead and I’ve searched the forums and started emailing some guys. After some time, I got lucky and I’ve found this post. Tiago also gave me a hand by explaining that there was a difference between the local vs. Web context difference. It was only a matter of time until finding the checknetisolation tool.

According to the docs, localhost access is forbidden for security reasons and that means you’re into trouble when you’re developing apps which access local services. And that’s where this tool comes in: you can use it to create a rule which relaxes the WinRT localhost loopback restriction. To create a new rule, you must run the following command:

checknetisolation loopbackexempt –a –n=your_app_name

Alternatively, you can pass your app’s SID (in that case, you –p instead of –n), but I think that using your app’s name is easier. This brings us to the next question: what’s the name of my app? It turns out that the easiest way to get your app’s name is to open the manifest and copy the value of the Package Family Name entry in the Packaging tab:


Now, running the following instruction is all that you need to get that loopback restriction removed for our win8tests app:

checknetisolation loopbackexempt –a –n=win8tests_t2ggmrgk4m9fg

Before going on, we should always use the –s option to see if everything went well:


As you can see, our rule is in place and everything should work out just fine…say again? are you sure? Unfortunately, it wasn’t working out fine…I was still getting the timeout and the error function that I’ve passed to the Promise object was still being called.

In despair, I’ve went back to the initial post and asked if there was anything I was missing. And the answer was yes, there was: I hadn’t opened port 80 on my firewall. It seems like WinRT xhr calls are always “served” as remote calls and they were being blocked by the firewall. After opening the HTTP 80 port (inbound rules), everything started running smoothly!


Btw, one extra note: if you’re trying to get a resource from an intranet machine, then you’ll probably need to require Home/work Networking capability in your manifest.

And that’s it for now. Stay tuned for more.