Virtual Host support on the embedded HTTP server

[Michael McMahon]

David M. Lloyd wrote:
> 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.
>
Right, and I think that model would be nice, if HttpExchange were a 
simple immutable
class. But, it is actually full of complicated state, since it is 
responsible for the response
as well as the request. We would have to put various caveats into its 
spec. saying what
you can and can't do with it, inside a HostMatcher.
>> 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).
>
I think this might be simpler.
>> 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.
>
Yes, that is true. Thinking about that, it's surprising that TLS doesn't 
do that already. It just needs to
provide some mechanism for the desired host name to go from client to 
server, before the server
chooses the certificate to send back.

- Michael