Virtual Host support on the embedded HTTP server

[David M. Lloyd]

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