Question

I’m running into a weird issue with a crossdomain webservice call in Silverlight 4.

Immediately after starting, the application calls a webservice on the same host from where it has been downloaded but on a different port (for ex. the application resides at http://www.mydomain.com:80 and the webservice is at http://www.mydomain.com:81). No SSL involved.
The host provides a proper clientaccesspolicy.xml file and everything works correctly most of the time (like 99.9%).

In some cases however, the browser does not request clientaccesspolicy.xml and as a result the webservice call is blocked and fails with a cross-domain error.

In the typical case this is the sequence of requests you see with Fiddler or Chrome developer tools:

• index.html (the page hosting the silverlight app)
• silverlight.js
• application.xap
• clientaccesspolicy.xml (requested and downloaded correctly)
• webservice call

In some instances however you only see

• index.html (the page hosting the silverlight app)
• silverlight.js
• application.xap
• -> cross domain error (no clientaccesspolicy requested, no web service call).

This only happens on a minority of machines (all running Windows 7) if all these conditions are true:

• application running within Chrome, Firefox or out-of-the browser (IE always works)
• it’s the first time you load the page (i.e. if you hit the browser’s reload button the problem goes away. Close/restart browser and the first time you still have the problem)
• no Fiddler running (if you run traffic through Fiddler the problem goes away). Chrome developer tools have no effect though.
• the machine is inside the same domain as the application server. If you access the page from an external network (with the same machine), the problem is not there.

On those machines, under those circumstances, the problem is 100% reproducible.

What could be causing this? What steps can I perform to track the issue?

Answer 1

This problem is obviously quite rare, but with some help from Microsoft I’ve found the solution. I’m posting it for future reference so that hopefully this won’t happen again.

As a security measure, Silverlight blocks any cross-domain call between the Internet zone and the Local Intranet zone. In that case it does not even request clientaccesspolicy.xml. So if the application is hosted on http://www.myhost.com (Internet zone), Silverlight prevents him from calling a webservice on http://www.another.com (Local Intranet zone).

This blog post explains it in detail.

So if you have one or several of the following symptoms (despite having discarded the obvious crossdomain errors like a malformed or misplaced clientaccesspolicy.xml):

• crossdomain error from some apparently random machines (several different locations/domains), but working from other machines
• clientaccesspolicy.xml not requested at all
• works with some browsers, does not with others. Apparently random, sometimes not working with any browser.
• sometimes no problem when Fiddler is open, but error without Fiddler running
• everything works correctly on localhost

It may be worth to attempt the following, in order to put the application host and the web service in the same security zone:

• go to IE security settings (these settings are also used by any application that access the network, i.e. any other browser as well)
• add the address that hosts the application AND the address that hosts the webservice to the Local Intranet sites
  OR
• uncheck the “Automatically detect intranet network” flag (so that they both end up in the Internet zone)