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
