Embedded HTTP server

[David M. Lloyd]

On 06/20/2008 06:30 AM, Michael McMahon wrote:
>> From a technical perspective, I'd really only make one change.  Right 
>> now, server contexts are registered on the HttpServer directly.   It 
>> would be nice if, instead of registering contexts, you just register a 
>> HttpHandler directly on the HttpServer, which always handles all HTTP 
>> requests to that server.
>>
>> Then to provide the context-discrimination function, a 
>> ContextHttpHandler could be implemented which implements HttpHandler, 
>> and which in turn allows you to register per-context HttpHandlers.  
>> This would make it a lot easier to implement, say, virtual hosts.
>>
> You mean a kind of two level handler setup - one for the server, and 
> then others for the contexts? Can you elaborate
> a bit on the benefits of that. Also, would you use the same HttpHandler 
> type at both levels?

Sure.  To use virtual hosts for an example, in order to support virtual 
hosts and have separate contexts for each host, the user must register a / 
context to catch everything.  Then they have to choose a delegate handler 
based on both the request context *and* the host.

By changing the context lookup mechanism to a handler itself, the user can 
register a handler that sorts based on request host, and then delegates to 
an instance of the provided context handler.  This way the user can reuse 
the context lookup functionality more easily.

Also, this approach would remove a level of indirection in the simple case 
where there's one handler for all requests to an HttpServer, though this 
benefit seems less important.

So the API change would amount to replacing HttpServer.createContext(*) 
with HttpServer.setHandler(HttpHandler handler), and introducing a new 
class, say HttpContextHandler implements HttpHandler which would in turn 
contain the createContext(*) methods removed from HttpServer.

- DML