Wildcard would lead to easier syntax than regex;

".mydomain.com" versus "(.)
.mydomain.com" for (I believe) the most common case.

I think it would be good to follow it the way that DNS does, so wildcard only applies leftmost, and only for subdomains, but not subdomains of subdomains. So ".mydomain.com" would match "foo.mydomain.com" but not "foo.bar.mydomain.com". If you want to match that, you'll need ".bar.mydomain.com".

What use case do you have in mind for a wildcard at the end?

Wow, let me try that again:

Wildcard would lead to easier syntax than regex;

"*.mydomain.com" versus "(.*)\\.mydomain.com" 

for (I believe) the most common case.

I think it would be good to follow it the way that DNS does, so wildcard only applies leftmost, and only for subdomains, but not subdomains of subdomains. So "*.mydomain.com" would match "foo.mydomain.com" but not "foo.bar.mydomain.com". If you want to match that, you'll need "*.bar.mydomain.com". And "mydomain.*.com" wouldn't work either.

What use case do you have in mind for a wildcard at the end?

I think leftmost wildcard could meet 90% of needs. Pls disregard the rightmost one

If the virtual list is checked dynamically without any URL cache(e.g. a matched or non-matched URL will not be checked again before the cache is expired), then many ppl may not want to use regex that will add more overhead to every request

Patch for review. If this is accepted, I'll convert VirtualHostRuleContainer to use this wildcard handling as well.

Notes:

• *.example.com will match "x.example.com" and ".example.com", but not "example.com", "y.x.example.com", or "a.badexample.com"
• *.x.example.com will match "y.x.example.com" and ".x.example.com", but not "x.example.com" or "z.y.x.example.com"
• only .example.com is valid as a wildcard. *example.com (note the lack of the "." after the "") is not, nor is "example.*", etc

Athena, this looks good and I'll apply to jetty 7.
But don't forget to update javadoc and VERSION.txt in your patches.

Can you prepare a jetty-6 patch

thanks

Ported the changes to ContextHandler to Jetty6, plus patch for VirtualHostRuleContainer, which should take care of enabling wildcard for any virtual hosts handling we do.

I noticed an inconsistency, though: when you have a null virtual host, the ContextHandler considers it a non-match it while the VirtualHostRuleContainer considers it a match. (See second test for both ContextHandler and VirtualHostRuleContainer in this patch). This inconsistency was present in the original (non-wildcard) code, and I carried it over.

VirtualHostRuleContainer javadoc indicates this is deliberate behavior, but ContextHandler has been doing it its way for much longer.

good work athena!

Hi!

I've tried this feature and it seems to me that it is not working. After debugging I think there should be fix in org.mortbay.jetty.handler.ContextHandlerCollection class. If, for example, your've configured foo.bar and *.foo.bar context and request is for http://baz.foo.bar then in method
public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch) (line 164) on line (184)

list=hosts.get(request.getServerName());

request.getServerName() will be "baz.foo.bar" but the right entry for handling this request is keeped in hosts map with key "*.foo.bar", so the list variable will be null after assignment and request is not handled.

Thanks,
Michael.

Michael,

Thanks for pointing that out! I noticed one other issue while working on ContextHandlerCollection, so I opened another bug to separate out the concerns and attached a patch there:

http://jira.codehaus.org/browse/JETTY-760