This is the sixth post in the WCF 4.5 series. In the previous post, we’ve discussed new authentication features for services hosted in IIS, and this post is continuing the new IIS hosting features list - automatic HTTPS endpoints in IIS.

Previous Posts

So what is the automatic HTTPS endpoint feature? WCF 4 introduced the default endpoint feature which enables the service host to automatically create default endpoints if no endpoint has been specified for the service. The default endpoints are created for each of the service host’s base addresses, according to a mapping between a base address scheme (HTTP, TCP…) and a matching binding. For example, if you have an HTTP base address, you will get an endpoint that uses the BasicHttp binding.

So what’s new in WCF 4.5? We now get another scheme mapping for HTTPS, so if your IIS has SSL enabled, and you don’t have any specific endpoints specified for the service, you will get both HTTP and HTTPS endpoints. The default binding for the HTTPS scheme is the same as for the HTTP scheme – BasicHttp binding.

How can you enable this feature?

Set up SSL in your IIS; there’s an excellent tutorial for this in the IIS.NET website.
Create the WCF service and host it in a web application.
Set the web application to be hosted in IIS.
Verify that the service doesn’t have any endpoint configuration set for it, so it will use default endpoints.

That’s it!

If you now browse to your service’s WSDL file, you will notice that you get two default endpoints – HTTP and HTTPS:

See anything strange? You are right! For some reason, the two endpoints use different machine names in the address.

Since WCF 4, services hosted in IIS automatically use the useRequestHeadersForMetadataAddress behavior which constructs the endpoint host name according to the host name used in the WSDL GET request. This behavior is required especially for web farms where clients see a special host name and not the machine name itself, but as you can see, the automatic HTTPS endpoint does use the machine name for some reason, which can be a bit problematic when the IIS server is a part of a web farm.

If you have SSL set in IIS, but you’re not interested in having an HTTPS endpoint, you can remove it by removing the HTTPS scheme mapping as shown in the following XML configuration:

<system.serviceModel>
    <protocolMapping>
        <remove scheme="https"/>
    </protocolMapping>    
    . . .        
</system.serviceModel>

This new feature is very useful if you need HTTPS endpoints, since before this feature if we needed HTTPS endpoints, we couldn’t use the default endpoints and had to declare all endpoints manually, both HTTP and HTTPS. This is another step for making configuration files smaller.

Unfortunately, there is currently the bug of the host name, I hope it will be resolved by the time the new framework is released.

Stay tuned for more posts about the new features of WCF 4.5. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.

The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Redmond (October 17-21).

Also, if you are an MCT and reside in the US, come hear my session about WCF 4 at the MCT 2011 North-America Summit that will be held in San-Francisco (October 19-21).

CodeProject

What’s New in WCF 4.5? Automatic HTTPS endpoint for IIS