I'm having some issues with getting cookies to work when using a ProxyPass to redirect traffic on port 80 to a web-application hosted via Tomcat.

My motivation for enabling cookies is to get rid of the "jsessionid=" parameter that is appended to the URLs.

I've enabled cookies in my context.xml in META-INF/ for my web application.
When I access the webapplication via http://url:8080/webapp it works as expected, the jsessionid parameter is not visible in the URL, instead it's stored in a cookie.

When accessing my website via an apache2 virtualhost the cookies doesn't seem to work because now "jsessionid" is being appended to the URLs. How can I solve this issue?

Here's my VHost configuration:

<VirtualHost *:80>
        ServerName somedomain.no
        ServerAlias www.somedomain.no

        <Proxy *>
                Order deny,allow
                Allow from all

        ProxyPreserveHost Off
        ProxyPass / http://localhost:8080/webapp/
        ProxyPassReverse / http://localhost:8080/webapp/

        ErrorLog /var/log/apache2/somedomain.no.error.log
        CustomLog /var/log/apache2/somedomain.no.access.log combined

EDIT: The cookie is actually being set when I visit from http://somedomain.no, but the cookie has its Path set to "/webapp".

2 Answers 2


I figured it out.

Add this to the VHost configuration:

ProxyPassReverseCookiePath /webapp /
  • Thank you. That is something I was meaning to look into and never did. Commented Apr 18, 2010 at 6:41

Remapping URLs is the thing that causes the most issues in applications, because at many places paths are inconsistent. It's a LOT better to avoid doing this and to make the visitor directly access your page. For instance, you could write a redirect rule which states that when a visitor hits "/", he gets redirected to "/webapp/" and that way he uses the real path and not a remapped one.

With your remapping, you'll always encounter issues such as this one. Some times you'll wonder why you get broken images and you'll discover "/webapp/img/..." in application-generated redirections. At other moments you'll find that your application is aware of its path and produces /webapp locations by itself, leading to /webapp/webapp on the visitor's browser, etc... These are the horrors that cause at least half of the admin's work at places where URL remapping is used, so you should really consider alternatives before it is too late to change.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .