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?
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 www.myhost.com (Internet zone), Silverlight prevents him from calling a webservice on 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):
It may be worth to attempt the following, in order to put the application host and the web service in the same security zone: