Are there any concerns with using TestServer in a production environment?

Jan 18, 2016 at 12:57 AM
I'm working on a self-hosted solution in which I'd like to expose isolated WebAPI applications from a single port. I would like something similar to the way IIS allows you to create multiple web applications under a single site.

I've implemented a proof of concept in which I create a single Owin Host. When a request is received, I can determine which of the child applications it targets. Each child application is loaded in a new App Domain, and creates an instance of TestServer. Each request is passed to the appropriate App Domain and processed by the TestServer instance. This allows me to harness all aspects of the Owin implementation while keeping each application isolated and "sharing" a single port across all applications.

This implementation seems promising, but I'm not sure if the TestServer implementation is as robust as the standard Owin Host. Does the Owin Host add more than just an HTTP listener to the core Owin functionality? Are there any concerns with using TestServer as a production tool?

Jan 18, 2016 at 5:40 AM

A) You shouldn't need the full TestServer in production, you should be able to use the Hosting API directly. E.g. you should peal off the TestServer layer and just call the APIs it does. Especailly don't use it's HttpClient APIs, as that would result in a lot of redundant copying of data structures.
B) HttpListener/Http.Sys has built in cross process port sharing based on the host and base path of the registered url. If your routing logic is just domain and path based then HttpListener can do that for you. You would launch each app in its own OwinHost process with a different registration url. Processes are also a much better unit of isolation and management.
Marked as answer by drumboog on 1/18/2016 at 6:22 AM
Jan 18, 2016 at 1:22 PM
Awesome... I didn't realize HttpListener had that functionality built in... much easier. Thanks!!!