• New Feature
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • Sessions
  • teck
  • Reporter: teck
  • August 19, 2010
  • 0
  • Watchers: 2
  • July 27, 2012
  • October 26, 2010

Description

At the moment we lift the virtual host for a given web context from the first request seen by our session manager. Specifically the “Host” HTTP header is read from this first request and that is used to qualify the root name.

This is usually okay, but can cause serious problems if the first request to your web app is not well defined in this regard.

These forum posts concern this topic: http://forums.terracotta.org/forums/posts/list/4047.page http://forums.terracotta.org/forums/posts/list/4380.page

Some options include:

  • reach deeper into the [each] container’s internals to determine the vhost for a given context (instead of using the request header)

  • allow something in user’s control to influence the root name (perhaps a context param in web.xml)

  • allow one to disable the vhost qualification in the root name (that would mean all equal context paths would share sessions even if they are different vhosts)

Comments

Fiona OShea 2010-10-25

From Tim 10/25 in email response to dev-internal regarding another forum post on this issue http://forums.terracotta.org/forums/posts/list/4380.page —

That is a real problem. It’s come up enough times that I think we should do something about it. I put the issue in JIRA a while back:

https://jira.terracotta.org/jira/browse/CDV-1504

I could make a very quick change that would implement the second option in that JIRA.

Tim Eck 2010-10-26

The session manager now maintains a map of session stores keyed by the incoming Host header(s). This means that conversations (ie. sessions) need to use a consistent Host value for all requests, but it also means that there is no more dependence or lock down based solely on the first request