Home/ Questions/Q 186943
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T15:44:10+00:00

We have a WCF service hosted on ServerA which is a server with no-direct

  • 0

We have a WCF service hosted on ServerA which is a server with no-direct Internet access and has a non-Internet routable IP address.

The service is fronted by BIGIP which handles SSL encryption and decryption and forwards the unencrypted request to ServerA (at the moment it does NOT actually do any load balancing, but that is likely to be added in the future) on a specific port.

What that means is that our clients would be calling the service through https://www.OurDomain.com/ServiceUrl and would get to our service on http://SeverA:85/ServiceUrl through the BIGIP device;

When we browse to the WSDL published on https://www.OurDomain.com/ServiceUrl all the addresses contained in the WSDL are based on the http://SeverA:85/ServiceUrl base address

We figured out that we could use the host headers setting to set the domain, but our problem is that while this would sort out the domain, we would still be using the wrong scheme – it would use http://www.OurDomain.com/ServiceUrl while we need it to be Https.

Also – as we have other services (asmx based) hosted on that server we had some issues setting the host headers, and so we thought we could get away with creating another site on the server (using, say, port 82) and set the host header on that; now, on top of the http/https problem we have an issue as the WSDL contains the port number in all the urls, where BigIP works on port 443 (for the SSL)

Is there a more flexible solution than implementing Host Headers? Ideally we need to retain flexibility and ease of supportability.

Thanks for any help…

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. This is essentially a multi-part problem that involves a number of discrete solutions to provide the full answer. Essentially there are 3 problems with sitting behind the F5.

    1. The advertised service endpoint hostname.
    2. Hostname of links to xsd:import’ed schemas that describe the data contract
    3. the http/https problem you describe.

    Changing the host headers, as you have found solves 1 and 2 (you can approach this in ways other than host headers, but no need to go into that here). Number 3 is a bit more tricky and requires more code (too much to dump out here).

    The short answer is that you need to write a ContractBehavior that implements both IContractBehavior and IWsdlExportExtension.

    The important bit you need to implement is the IWsdlExportExtension.ExportEndpoint. Within this method you need to iterate over all the WsdlPort Extensions, and when you find an extension that is of type SoapAddressBinding you need to replace the SoapAddressBinding.Location property with a new Uri that contains the https protocol specifier. You also need to do similar bits for the xsd import addresses and schema links.

    If your service is also using WS-Addressing You then need to do something similar to handle the additional addresses it writes out to the wsdl.

    I based the code I ended up writing on the WsdlExtras project available on CodePlex (http://wcfextras.codeplex.com/). The method used in the WsdlExtras provides a great base for any extra bits you may need to add to it (From memory I don’t think it dealt with the WS-Addressing bits). The bit you want to look at is the ‘Override SOAP Address Location URL’.

    • 0