Introduction

Virtual hosting is the well established practice of mapping multiple domain names to a single host platform. NetKernel provides separate encapsulated URI address spaces in each module which means that creating virtual hosts is quite straightforward.

Transport Requests

For virtual hosting to work the transport must provide the target host name in the request URI. The URI specification states that a server host name is the first item after the URI scheme declaration, as follows:

scheme://host:port/path/resource

The Jetty HTTP transport always provides the host in the root request it injects into the fulcrum module. For example, a request to Jetty from a web-browser on the same host as the NetKernel installation might be

jetty://localhost:1060/a/path/to/a/resource

A Module is a Virtual Host

Since a NetKernel module supports a separate URI address space, virtual hosting in NetKernel can be realized by directing requests to modules based on the host information. To implement a virtual host:

1. The HTTP transport and HTTPBridge will issue requests into their hosting module including the full hostname. However, by default the Front-End fulcrum removes the hostname and maps requests to the ffcpl:/ space. Comment out the rewrite rule (shown below) if you want the hostname to reach your application module.
2. Import any number of virtual host modules into the Fulcrum. Each virtual host module should export a public URI address space that matches each supported host (such as localhost).
3. Do no processing in the fulcrum module. Allow NetKernel route the requests to the mathcing virtual host modules.

Depending on how you implement your virtual host module you may wish to use a URI rewrite rule to map the external request down to the root of the module's internal address space. Here's a rule which does that