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
