Take the 2-minute tour ×

I've been looking all over the site and on stack overflow and I just can solve my issue.

Network Setup

The way my network on my staging world is that I have clients looking at my web app on a 443 port - https, but the underlying structure is listening on 80 port - http. So when my apps talk to each other its on port 80, but when the clients visit the site its port 443. So for example, my svc called from silverlight would be on port 80.

I should also point out that on my staging and test domains: I have a web server acting as a portal to my app server; but this shouldn't really matter since I was able to get this working on test. It's just that staging has the HTTP forwarding to HTTPS.


I have a silverlight xap file that is on the same domain as my hosted web application using IIS 6.

Now since my silverlight xap file and my web application are on the same domain, I have no problems running this on dev and test, but when I try to deploy to staging I'm getting a weird cross domain reference problem:

"System.ServiceModel.CommunicationException: An error occurred while trying to make a request to URI . This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for Soap services."

Digging around, I realize that my app thinks that my xap (or the service I'm calling) and my web app are on a different domain, and looks for the crossdomain.xml and clientaccesspolicy.xml files automatically, I can't really stop it. However, in my application, this is not the case. They both reside on the same domain. I have used fiddler and I didn't see anything about another domain or even a subdomain for that matter.

Browser Issues

Another weird thing that I found out is an issue with chrome vs ie: On chrome it finds the crossdomain.xml and clientaccesspolicy.xml telling me its insecure, then it does another fetch from the https side, signalling a 404 error. However, on IE I'm getting a 302 redirect. On microsoft's doc about clientaccesspolicy.xml you aren't supposed to do any redirects from the xml file; this is mentioned here: http://msdn.microsoft.com/en-us/library/cc838250(v=vs.95).aspx

So my question is, if my app and xap are on the same domain, why are those xmls trying to get fetched? Is it because I'm using a DNS instead of an IP address? I also stumbled upon this site: http://msdn.microsoft.com/en-us/library/ff921170(v=pandp.20).aspx


What does that even mean??


Okay so I changed the services to point to https instead of http. However new error comes out: The provided URI scheme 'https' is invalid; expected http.

The good thing is, it doesn't even check crossdomain.xml or clientaccesspolicy.xml; so it now realizes it's on the same domain. But now it's expecting a service on port 80, but the name has to follow as https:// in order for it to work.

I think the only solution I have now is to break it off as being a virtual directory, make it a root node of its own website, and make the whole thing as 443. Save myself the headache.

share|improve this question
I'm not exactly sure what is your setup but note that "same origin" means all 3 portions of the url must match: schema (http and https are different), domain (exact match required, not case sensitive), and port (exact match). –  Alexei Levenkov Sep 24 '13 at 18:19
If I make it the same origin I get a new error: System.ArgumentException: The provided URI scheme 'https' is invalid; expected 'http' –  sksallaj Sep 24 '13 at 19:13
There should be tens of articles how to configure WCF to work on HTTPS endpoint... –  Alexei Levenkov Sep 24 '13 at 19:53
Not if you have a mixed environment, I have my endpoints on port 80, but they are seen as port 443. But your direction did help me figure something out. –  sksallaj Sep 24 '13 at 20:36
add comment

1 Answer

up vote 1 down vote accepted

It sounds like you're working in an environment where there is a load balancer offloading the SSL traffic. In this situation, your client(Silverlight) needs to be configured for HTTPS and your server must be configured for HTTP. This is because a device between the two parties is decrypting the SSL data.

In situations like this, aside from the normal client and server side configurations, your server side code needs to be a bit more forgiving about the address of the request.

You likely also need to add an attribute to your service implementation to allow your client to call over HTTPS, but have your service listening on HTTP.

Add this to your service:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

This allows your client to call https://my.domain.com/service.svc and have your server live at http://my.domain.com/service.svc.

Here are some links that might help as well:




share|improve this answer
Thanks Nate!! :) :) –  sksallaj Sep 27 '13 at 18:28
add comment

Your Answer


