If you want to. I also have another variation where there's a
HttpVirtualHost subclass of HttpHost, which includes a "close()" method
which removes the virtual host. That might make things a little more clear.
Just specifying the host name is OK for some cases, but not for cases where
you want to respond to "*.foo.com" with one "host", and "*.bar.com" with
another, for example (which I think may be common even in simple
installations - think pastebins, etc.). Also it doesn't help with IP-based
virtual hosts, with which you'd have to run multiple instances, including
one bound to 0.0.0.0 to catch the "default" case.
Either way I don't see it affecting HttpsServer in any way, since virtual
hosts have long been known not to work with HTTPS. I suppose the exception
would be supporting IP-based virtual hosts.
Well, either way I'd be happy taking your simple host-based idea and
expanding it to support some kind of patterns - that would meet my use cases.
- DML
On 12/14/2009 07:28 AM, Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi David,
I looked at the proposal and it looks pretty good, I just have a few
concerns.
HttpHost can be a virtual or real host, and HttpServer is an instance of
a HTTP server running a virtual host. I think this concept is used in
webservers like apache and Sun webserver. I always found it a little
confusing, and I'm a little concerned that it will just confuse users of
this simple http server API. Considering I wouldn't expect may users to
use this advanced feature.
I wonder if we could rework a simpler approach, maybe just simple name
based virtual server? Possibly:
HttpContext createContext(String host, String path, HttpHandler handler)
Also, we need to think of the implications on HttpsServer.
Michael (cc'ed) is the author of this API. Maybe he has an opinion.
-Chris.
On 07/12/2009 11:23, Christopher Hegarty - Sun Microsystems Ireland wrote:
This is certainly interesting. Let me take a look and I'll get back to
you later.
-Chris.
On 04/12/2009 20:17, David M. Lloyd wrote:
I've crafted a simple patch which extends the API of the embedded
HTTP server to support virtual hosts. The patch is designed to add
the new functionality without breaking existing implementations which
do not support virtual hosts, or code which uses the HttpServer API
today. It does not include an implementation; however, the default
implementation should be easy to extend, from a brief look over the
code.
The patch is attached. Please let me know what you think.
- DML
