6

I have a Silverlight application that connects to a WCF service. Under the basic configuration I am used to, there's no problem connecting this application to its corresponding WCF service.

However, recently, one of my clients started using an Apache reverse proxy. This proxy is the public server and it's only used to encrypt HTTP traffic via SSL (HTTPS) going between the client and it. This proxy passes all traffic from it to the actual web server that hosts my application. The traffic between the public proxy and the IIS server is just plain HTTP.

So the traffic flows like this: End-User Browser ---HTTPS----> Public Reverse Proxy -----HTTP----> IIS server that hosts the WCF service.

The reverse proxy and IIS are on two separate servers.

I cannot get the Silverlight application to function properly. I am not sure how to configure the endpoints? I get problems whenever I use the public proxy's address as my endpoint address.

The Silverlight application usually has this configuration: 

<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IPOTemplateEditorSrv" maxBufferSize="2147483647"
                    maxReceivedMessageSize="2147483647">
                    <security mode="TransportWithMessageCredential" />
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="https://public-reverse-proxy-url/POTemplateEditorSrv.svc"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IPOTemplateEditorSrv"
                contract="POEditorSrvRef.IPOTemplateEditorSrv" name="BasicHttpBinding_IPOTemplateEditorSrv" />
        </client>
    </system.serviceModel>
</configuration>

Note that I am using and I have my endpoint address pointing to the public HTTPS address of the reverse proxy.

Am I missing anything? Is there any additional information to configure the proxy perhaps? Any workarounds that would get my Silverlight client connect to the service?

Zaki Saadeh
  • 642
  • 4
  • 11
  • Can you access the service directly when you type the URL (https://public-reverse-proxy-url/POTemplateEditorSrv.svc) into the browser? – boris Aug 31 '12 at 18:59
  • Yes, I can. I actually tried that and had no problem seeing the page generated by WCF when you access that page. When I do that, I get the page that tells me that "You have created a service. To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe...(I am truncating the rest of the message I get)" – Zaki Saadeh Aug 31 '12 at 19:38
  • What kind of problems are you seeing when trying to connect from Silverlight? My next step would be to fire up Developer Tools in IE9 (F12) or Fiddler and take a look at the request that the Silverlight client generates (if any) and the response it's getting (if any). – boris Aug 31 '12 at 19:46
  • The thing is, when the Silverlight app is downloaded from the server by the browser, then loaded and run, it doesn't proceed to request the svc resources like it's supposed to and like it does for any app I have that doesn't have the public proxy going on for it. – Zaki Saadeh Aug 31 '12 at 20:01
  • Do you see any exceptions in Silverlight? Are clientaccesspolicy/crossdomain files setup correctly and downloaded from the server? – boris Aug 31 '12 at 20:11
  • Thanks Boris. I just used IE's error console and found out that I get: Unhandled Error in Silverlight Application The remote server returned an error: NotFound. at System.Runtime.CompilerServices.AsyncVoidMethodBuilder.b__0(Object state).... I also looked at the WSDL associated with the required service and and found out that 's . There are also other imports for local xsd schemas referencing the private address. Do you know why it would bind these resources to the local private server instead of the public one? – Zaki Saadeh Aug 31 '12 at 21:08
  • 1
    The fact that you're saying that the app doesn't request the svc resources at all and the fact that you're getting "remote server returned an error..." exception don't add up. A request is either going out and gets a response from the remote server or it doesn't. It's hard to diagnose these things remotely, but I can tell you that we're using a very similar configuration (with load balancer/SSL accelerator) and it works just fine. The only difference I see is that we're using just "Transport" security mode. – boris Sep 04 '12 at 01:56

1 Answers1

5

Perhaps this answer is a little too obvious, but it simply sounds like the WSDL is advertising an internal host-name as the WCF address - when that address is not the actual public one. Because IIS is generating the WSDL, it will simply use it's host name in the endpoint addresses - which is not what you want, you want the proxy's address.

Try creating a static copy of your WSDL file, and publish that on your web server. Make sure you replace ALL REFERENCES to the internal host name, with the public proxy host name. Then modify your WCF client config to point to the static WSDL. You can find a short explanation here: Supply a different endpoint address in the WSDL of a WCF web service

If that doesnt work - try using a sniffer (wireshark) to capture what is being sent back and forth - disabling HTTPS might be a piece you need to remove from the equation. Your web service request appears to be SENT to the proxy, but the proxy is not able to handle the request properly - the perfect scenario to try our your sniffing tools.

When you make a direct request to your SVC using a web browser, the request will look something like this

GET /POTemplateEditorSrv.svc HTTP/1.1
Host: public-reverse-proxy-url

But when sent via Silverlight, it may look like this

GET /POTemplateEditorSrv.svc HTTP/1.1
Host: private-server-address

This could be a subtle enough difference to upset the proxy.

Community
  • 1
  • 1
Adam
  • 4,159
  • 4
  • 32
  • 53
  • +1 Great answer. Specifically (as per the included link), change the `` value in the ``. You don't need to host the file on the webserver; you can simply 'discover' it from your desktop. – Kirk Broadhurst Sep 04 '12 at 23:20
  • OK thanks Adam. I'll try this and get back to you in a day or two! – Zaki Saadeh Sep 05 '12 at 23:07
  • I haven't tried this at the client's server yet, but this solution makes sense to me and I will accept it. – Zaki Saadeh Sep 07 '12 at 18:27