private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
A virtual host is an alternative name, registered in DNS, for an IP address such that multiple domain names will resolve to the same IP of a shared server instance. If the content to be served to the aliases names is different, then a virtual host needs to be configured for each deployed context to indicate which names a context will respond to.
Creating a custom deployer with a binding to configure virtual hosts for all contexts found in the same webapps directory.
Jetty supports the following styles of virtual host name:
A fully qualified host name. It is important to list all variants as a site may receive traffic from both www.hostname.com and just hostname.com
A wildcard qualified host which will match only one level of arbitrary names. *.foo.com will match www.foo.com and m.foo.com, but not www.other.foo.com
An IP address may be given as a virtual host name to indicate that a context should handle requests received on that server port that do not have a host name specified (HTTP/0.9 or HTTP/1.0)
A connector name, which is not strictly a virtual host, but instead will only match requests that are received on connectors that have a matching name set with Connector.setName(String).
Non ascii and IDN
domain names can be set as virtual hosts using Puny Code
equivalents that may be obtained from a Punycode/IDN
converters. For example if the non ascii domain name
www.√integral.com is given to a browser, then it
will make a request that uses the domain name
www.xn--integral-7g7d.com, which is the name that
should be added as the virtual host name.
Virtual hosts can be used with any context that is a subclass of ContextHandler. Lets look at an example where we configure a web application - represented by the WebAppContext class - with virtual hosts. You supply a list of IP addresses and names at which the web application is reachable. Suppose you have a machine with these IP addresses and these DNS resolvable names:
Suppose you have a webapp called
you want all of the above names and addresses to be served at path
/blah". Here's how you would configure the virtual hosts
with a context XML file:
You can configure different contexts to respond on different virtual hosts by supplying a specific list of virtual hosts for each one.
For example, suppose your imaginary machine has these DNS names:
Suppose also you have 2 webapps, one called
blah.war that you would like served from the
*.blah.* names, and one called
that you want served only from the
Using the method of preparing context XML files, one for each webapp yields the following:
These urls now resolve to the blah context (ie
These urls now resolve to the other context (ie other.war):
In the previous section we setup 2 different contexts to be served from different virtual hosts at different context paths. However, there is no requirement that the context paths must be distinct: you may use the same context path for multiple contexts, and use virtual hosts to determine which one is served for a given request.
Consider an example where we have the same set of DNS names as
before, and the same webapps
other.war. We still want
blah.war to be served in response to hostnames of
*.blah.*, and we still want
be served in response to
*.other.* names. However, we would
like all of our clients to use the
context path, no matter which context is being targeted.
In other words, we want all of the following urls to map to
Similarly, we want the following urls to map to
To achieve this, we simply use the same context path of "/" for each of our webapps, whilst still applying our different set of virtual host names.
For foo webapp:
For bar webapp: