Perhaps I should raise a separate issue, but it is related, because the current code "requires" that we define an handler class with `setup()`, `handle()` and `finish()` in its API. If you look at the actual code, there is no such requirement. We only have to pass a factory method that receives three arguments, creates a new handler instance and starts it. The handler does not have to offer any API - you don't even have to subclass the RequestHandlerBase class. I still say that it "requires" it, because it is part of the documentation and, if you don't, you could be in trouble in future versions. However, this requirement is clearly annoying, because if you have an handler for another server, you need to re-factorize the code to provide this API, which is not even used. I am sure there is no such requirement, but it's not clear at first. 

This is clearly not just a documentation issue. The intent in the code is the concern of the designers of the code. David and I assume that the intent is that we can provide any arbitrary factory method that receives the three arguments, creates and starts the handler, but we can be mistaken. In fact, to me this looks as a hack, especially given the parameter name, which says that we must pass the handler class. An handler class is indeed a factory method, but it is a very specific one, not the one that we want to pass if we must include extra parameters.