Responses inline.
On 12/14/2009 12:20 PM, Michael McMahon wrote:
Hi David,
Apologies for missing this when it was suggested originally.
Is there a particular use case you have in mind that requires the
generality provided by the HostMatcher interface? (as opposed to the
simpler name based approach as Chris said)
It's the simplest possible way I could think of to solve the problem,
that's all.
Presumably, with HostMatcher,
you would have to specify some way of deciding what to do if multiple
hosts try to claim the same request etc. Also, there would be a concern
whether it would scale performance wise.
First one wins. Evaluate them in order of registration. Performance-wise,
unless you have thousands of virtual hosts I wouldn't expect a measurable
impact.
The alternative is to select something O(1)-ish but this can drastically
limit what is possible. Though like I said, for my purposes if you would
allow for host name ("foo.bar.com") and a simple pattern mechanism
("*.bar.com" but not, say, "foo.*.com"), that'd be OK and it would still
let you have an O(1)-ish implementation (e.g. split by ".", evalulate
segments right-to-left, depth first, exact match first, wildcard match
second so longest match wins, not too unlike how contexts are matched I guess).
Unfortunately, the fact that HttpsServer is a sub-class of HttpServer
means we'd have to deal with the non-support of virtual hosts in Https,
at runtime, rather than at compile time. But that is likely to be the
case, whatever way this is done.
Well, you can (and should) still support them. They just have to meet the
requirements of the certificate presented (e.g. you can support
"foo.bar.com" and "baz.bar.com" if the cert is for "*.bar.com"). You don't
want to disable support for it in this case because they're still useful;
you just have to be aware of the rules. And who knows, maybe a future TLS
extension will make it generally viable, so you wouldn't want to rule it
out for this reason as well.
- DML
- Michael.
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
