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:
In some instances however you only see
This only happens on a minority of machines (all running Windows 7) if all these conditions are true:
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:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With