Monthly Archives: February 2012

Enabling HTTPS with self-hosted ASP.NET Web API

In a previous post, I showed how to  self-host ASP.NET Web API. This post shows how to change that example in order to enable HTTPS support.

  1. On an elevated console (“Run as administrator”), execute “netsh http add urlacl url=https://+:4443/ user=<your user name>”, to allow the running user to listen on port 4443 using HTTPS (note the use of ‘https’ instead of ‘http’ in the above command).
  2. Also on an elevated console, register the server certificate by running

    netsh http add sslcert ipport=0.0.0.0:port certhash=thumbprint appid={app-guid} where

    • port is the listening port (e.g. 4443); the special IP address 0.0.0.0 matches any IP address for the local machine;
    • thumbprint is the certificate’s SHA-1 hash, represented in hexadecimal;
    • app-guid is any GUID (e.g. {00000000-0000-0000-0000-000000000000}) , used to identity the owning application.
  3. In the previous post’s Main method, replace the HttpSelfHostConfiguration class with the new MyHttpsSelfHostConfiguration class, containing the following code.
  4. class MyHttpsSelfHostConfiguration : HttpSelfHostConfiguration
    {
        public MyHttpsSelfHostConfiguration(string baseAddress) : base(baseAddress){}
        public MyHttpsSelfHostConfiguration(Uri baseAddress) : base(baseAddress){}
        protected override BindingParameterCollection OnConfigureBinding(HttpBinding httpBinding)
        {
            httpBinding.Security.Mode = HttpBindingSecurityMode.Transport;
            return base.OnConfigureBinding(httpBinding);
        }
    }
    
    
  5. Change the base address passed to the MyHttpsSelfHostConfiguration constructor: var config = new MyHttpsSelfHostConfiguration(“https://localhost:4443&#8221;);
  6. Run the program, open a browser and access https://localhost:4443/helloimage

That’s it: you now have a self-hosted ASP.NET Web API server, using the secure HTTPS protocol.

Self-hosting ASP.NET Web API

Just a simple example, showing how to self-host ASP.NET Web API.

    1. On an elevated console (“Run as administrator”), execute “netsh http add urlacl url=http://+:8080/ user=<your user name>”, to allow the running user to listen on port 8080.
    2. On Visual Studio, create a “Console Application” project.
    3. Change the project’s Target Framework property from “.NET Framework 4 Client Profile” to “.NET Framework 4 profile”.
    4. Install the AspNetWebApi.Selfhost NuGet package
    5. Create a public ApiController derived class.
public class HelloController : ApiController
{
  public HttpResponseMessage Get()
  {
    return new HttpResponseMessage
        {
          Content = new StringContent("Hello HTTP")
        };
  }
}
    1. In the program’s Main method,
      1. Create a HttpSelfHostConfiguration, initialized with the base address.
      2. Add the default route: MapHttpRoute(“default”, “{controller}/{id}”, new { id = RouteParameter.Optional });
      3. Create a HttpSelfHostServer, initialized with the above configuration object.
      4. Open the server, bearing in mind that the OpenAsync method is asynchronous.
static void Main(string[] args)
{
  var config = new HttpSelfHostConfiguration("http://localhost:8080");
  config.Routes.MapHttpRoute("default", "{controller}/{id}", new { id = RouteParameter.Optional });
  var server = new HttpSelfHostServer(config);
  server.OpenAsync().Wait();

  Console.WriteLine("Server is opened");
  Console.ReadKey();

  1. Run the program, open a browser and access http://localhost:8080/hello.

image

That’s it. You now have a self-hosted ASP.NET Web API server.

WCF Web API is now ASP.NET Web API

For the past year, I’ve been studying and exploring the preview releases of WCF Web API. The result of these activities is reflected in a series of posts presenting its programing model, processing architecture and extensibility points.

However, WCF Web API was recently renamed as ASP.NET Web API, as the result of its merge with the Microsoft Web platform, namely with ASP.NET MVC.

This renaming is n0t just mere branding issue; it reflects changes in both the programming model and processing architecture. For instance:

  • The programming model is now based on the controller and action concepts, used in ASP.NET MVC, instead of on the service and operation concepts, from the WCF world.
  • Operation handlers were removed and a model-binding mechanism was introduced.

As a consequence, some of my WCF Web API related posts are now software archeology.

However, in the near future, I will be posting more information about this new programming model and processing architecture. Stay tuned.