tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Strange behaviour after upgrade to 5.5.20
Date Fri, 05 Jan 2007 14:37:51 GMT
Hash: SHA1


Varley, Roger wrote:
> I've finally sussed it. Because we're still in development, we've 
> been fairly cavalier about how we've been calling the initial servlet
> (as localhost/servlet, hostname/servlet and by IP address/servlet)
> and some of the links within the application have been using a
> mixture of IP addresses and hostname).

That in itself shouldn't be a big problem.

> It appears that Tomcat is
> creating a seperate session based on the "host" portion of the URL
> that its being passed.

Nope. Tomcat creates sessions when you need one. If you are swithing
server names, then your browser is not submitting the cookie that is
likely to be used for session tracking. If you were using URL rewriting
instead of cookies, my guess is that you never would have known that
there was a problem.

> So when we called the servlet initially using,
> for example, and loaded the session
> data, a subsequent call to http://hostname/servlet created a new
> session - hence the appearance of sessions going out of sync.

Yup. Your browser stopped sending the cookie (because of the hostname
change) and so you "lost" your session. On the bright side, you got
yourself a new one!

> Now we've standardised and everything is working as expected.

That's always best. I hope you mean that the application itself has been
standardized, instead of the method of access.

> Is this a known behaviour or is there something we can do through
> config to get around this problem?

Tomcat doesn't mess with your URLs. If you emit a URL to your client
browser with the address, then that's what the client is
going to get.

On the other hand, if you let your content delivery tools (JSP taglibs
or something similar) do the work of emitting URLs for you, you should
never have to worry about this kind of thing. Those tools are written so
that they either emit relative URLs (which have no hostname information
in them, so there's no confusion), or they emit fully-qualified URLs
containing the hostname that is currently being used to access the
webapp, which should therefore never change.

I wouldn't recommend hard-coding the hostname anywhere in your webapp.
You never know when you are going to have to re-deploy the app into a
separate environment. If you have hard-coded the hostname, then you'll
have to go back into the code and recompile in order to re-deploy.

I hope that clears things up,
- -chris
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message