This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Wicket behind a front-end proxy
Skip to end of metadata
Go to start of metadata

Table of contents

Running Wicket Behind A Front End Proxy

Many organisations choose to hide their web apps behind some kind of front-end proxy server. There are various ways to set this up. For example, you can set up mod_proxy in an Apache server host configuration like so:

ProxyPass /<contextPath><contextPath>
ProxyPassReverse /<contextPath><contextPath>
ProxyPassReverseCookiePath /<contextPath> /

Where <contextPath> is replaced by the context path you've deployed your wicket application under.

The ProxyPass directive causes request URLs to be proxied to the specified host.

The ProxyPassReverse directive causes 302 redirects from your app server to be rewritten to point to the front-end proxy instead, so they continue to work properly.

The ProxyPassReverseCookiePath directive (Apache 2.2+ only) rewrites cookie paths for you, so sessions work properly.

Why this doesn't always work

Many people like to run their applications on CNAMEd virtual hosts for their different services (for example, Google™ run,, etc.) This can cause problems, because many things that run on the servlet framework, Wicket included, construct URLs using absolute paths based on the context path that the app is deployed in.

In the mod_proxy example above, this works fine, because the path on the proxy is the same as the path on the app server. This also works fine if your app server only runs one application in the root context, because you'll have something that looks like this and everything will just work:

ProxyPass /
ProxyPassReverse /

However, where you run into trouble is if you have a set-up that looks like this:

  ProxyPass /
  ProxyPassReverse /
  # Apache 2.2+ only
  ProxyPassReverseCookiePath /ordering /

  ProxyPass /
  ProxyPassReverse /
  # Apache 2.2+ only
  ProxyPassReverseCookiePath /billing /

The problem with this is that although requests get proxied across just fine, by default Wicket will construct absolute paths to links, resources, etc. using the context path that the wicket servlet is deployed under (e.g. /billing). For example, if your wicket servlet is mapped to accept requests to "/wicket", this means anchor href links might look like this: "/billing/wicket?foo".

This works fine for development, but when you stick it behind your proxy, suddenly everything stops working, because you're trying to link to a non-existent /billing directory. So your page will show up fine, but any resource links won't work, and nothing will work if you click on it (you'll get 404s).

How to fix Wicket-generated links

Wicket 1.2 allows you to override the context path it uses to generate absolute paths for links, resources, etc. You can either do this in your web.xml file:


...or in the init() method of your Application subclass like so:


Wicket 1.3 uses relative URLs, which neatly avoids this problem in the first place. Don't use setContextPath with Wicket 1.3, unless you're running a PortletApplication.

Using UTF-8 encoded URIs with mod_jk

In it's default configuration, mod_jk uses

JkOptions +ForwardURICompat

which may probably cause problems (especially with Wicket's UrlCodingStrategies) when used with UTF-8 encoded URIs that contains special characters, like So if you experience problems with UTF-8 encoded URIs or just want to have a fully UTF-8 compliant cycle, remove this option from the mod_jk configuration or use some other forwarding options documented here.

  • No labels