On 12/14/2009 03:58 PM, Michael McMahon wrote:
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
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
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 appr
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)
Presumably, with HostMatcher, you would have
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 wa
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
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 with
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 inc
