Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Homepage:http://www.eclipse.org/jetty
Downloads: http://download.eclipse.org/jetty/
Documentation:http://www.eclipse.org/jetty/documentation/current/
About:http://www.eclipse.org/jetty/about.php
Jetty Powered:http://www.eclipse.org/jetty/powered/
Contact the core Jetty developers at www.webtide.com
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
Skip to end of metadata
Go to start of metadata

Using Virtual Hosts

A virtual host is an alternative name, registered in DNS, for an IP address. A single IP address may have many such alternative names.

Multi-homed hosts, that is machines with more than one network interface, may have a different name for each IP address. This is also refered to as "virtual hosting".

Essentially, "virtual hosting" concerns the resolution of a DNS registered name to an IP address - many names may resolve to the same IP address, and 1 or more IP addresses may reside on the same physical machine.

Jetty users often want to configure their web applications taking into account these different virtual hosts. Frequently, a machine with a single IP address will have different DNS resolvable names associated with it, and a webapp deployed on it must be reachable from all of the alternative names.

Other possibilities are to serve different web applications from different virtual hosts.

Let's examine these possibilities.

Configuration of virtual hosts

When configuring a web application, you can supply a list of IP addresses and names at which the web application will be reachable. Suppose we have a machine with these IP addresses and DNS resolvable names:

  • 333.444.555.666
  • 127.0.0.1
  • www.blah.com
  • www.blah.net
  • www.blah.org

Suppose we have a webapp, xxx.war that we want to be served from all of the above names and addresses. Then we would configure the webapp like so:

Assuming we'd configured a connector listening on port 8080, then webapp xxx.war would be available at all of the following addresses:

Configuring different webapps for different virtual hosts

This is accomplished simply by supplying a different list of virtual hosts for each webapp. For example, suppose our imaginary machine has these DNS names and IP addresses:

  • 333.444.555.666
  • 127.0.0.1
  • www.blah.com
  • www.blah.net
  • www.blah.org
  • 777.888.888.111
  • www.other.com
  • www.other.net
  • www.other.org

Suppose also we have another webapp, zzz.war. We want xxx.war to be deployed as above, and zzz.war to be deployed only from 777.888.888.111, www.other.com, www.other.net and www.other.org:

Webapp xxx.war is still available at:

But now webapp zzz.war is available at:

Configuring different webapps for different virtual hosts, but at the same context path

In our example above, we have made webapp zzz.war avilable not only at a certain set of virtual hosts, but also at the context path /zzz, whilst our other webapp is available at both a different set of virtual hosts, and at a different context path. What happens if we want them at the same context path, but still at different sets of virtual hosts?

Very simply, we just supply the same context path for each webapp, leaving the disjoint set of virtual host definitions as before:

Now, webapp xxx.war is available at:

and webapp zzz.war is available at:

Configuring virtual hosts with non-ascii characters

International domain names are names containing non-ascii characters. For example "http://www.bücher.com". The DNS internally remains based on ascii, so these kinds of names are translated via an encoding called punycode into an ascii representation. Modern browsers will detect these non-ascii characters in URLs and automatically apply the punycode encoding. For example, typing this url into a browser:

http://www.åäö.com:8080/test/

is translated to the following url:

http://www.xn--4cab6c.com:8080/test/

For using internationalized domain names with jetty virtual hosts, you need to supply the punycoded form of the name in your context xml file (and of course you will need to supply it to your DNS setup).

Here's an example. Say I'm running a webapp on port 8080 at context /test, and I want to configure a virtual host for "www.åäö.com". I configure its ascii equivalent in the context xml file for the context:

After starting jetty, I will be able to enter the url "http://www.åäö.com:8080/test/" in my browser and reach my webapp.

Note that if I don't have any webapps deployed at /, hitting the url "http://www.åäö.com:8080" will hit jetty's default handler, which serves back a 404 page listing the available contexts:

Error 404 - Not Found

No context on this server matched or handled this request.

Contexts known to this server are:

  • /test @ www.xn--4cab6c.com:8080 ---> WebAppContext@82d210@82d210/test,file:/tmp/Jetty_0_0_0_0_8080_test.war__test_www.xn..4cab6c.com_1jadjg/webapp/,/home/janb/src/jetty-eclipse/jetty/trunk/jetty-distribution/target/distribution/webapps/test.war

You'll notice that the link already has the punycode transformed domain name in it.

  • No labels

1 Comment

  1. Hi,

    i'm configuring jetty with some helper-methods. One problem is, that i have to restart jetty to overtake the changes i've done with context.setVirtualHosts. Is there a mistake by me or doesn't it work else?

    Thanks in advance 

    Greetz

    PS.: Here the code:

Contact the core Jetty developers at www.webtide.com
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