Re: Embedded HTTP server

[Michael McMahon]

David M. Lloyd wrote:

On 06/19/2008 05:11 AM, Michael McMahon wrote:

David,

It was originally intended that the httpserver API would be part of the
 platform (actually in the package suggested above) but some members of
the umbrella JSR for jdk 6 didn't agree with including a http server API
in Java SE. So, it was dropped from the platform. And that is why we put
it in com.sun.


Makes sense I guess.

Personally, I wouldn't have any problem with putting it back in the 
platform, though presumably this question of whether it blurs the line

between Java SE and EE would have to be addressed.


For those who care about such things, sure.  I don't see any technical 
reason why that should be an obstacle, since there is no such API in 
Java EE either. :-)



True. However, the servlet API provides a lot of the same thing ...
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?


- Michael.

Re: 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