0

I'm posting some strings in my Session with the call

request.getSession().setAttribute(key, value);

And making the redirect with

response.sendRedirect(urlRedirect);

In almost all cases the values is there after the redirect.

But sometimes I can only read this value in the next page view, not in the redirect. There is no common behavior.

Someone has faced the same problem?

Brad Mace
  • 26,280
  • 15
  • 94
  • 141
Victor
  • 7,620
  • 14
  • 74
  • 121

4 Answers4

3

Sessions are backed by a HTTP cookie. On first-time session creation, a cookie will be set in the response header. By default, cookies are bound to a specific context only.

So, if you redirect while the cookie hasn't been set yet, the session will get lost. To go around this, you need to encode the redirect URL.

response.sendRedirect(response.encodeRedirectURL(url));

This appends the jsessionid identifier to the URL which allows the servletcontainer to locate the right session without help of a cookie.

If you don't like the jsessionid thing, then consider implementing a filter like this which ensures that the client is aware of the session cookie before the request enters your controller wherein you fire the redirect.

Also, if you redirect to a different context, it won't be able to access the same session. To go around this, you need to configure the servletcontainer to share the session among the contexts. In for example Tomcat, check the emptySessionPath attribute of the <Connector> element in /conf/server.xml.

Community
  • 1
  • 1
BalusC
  • 992,635
  • 352
  • 3,478
  • 3,452
  • The workarround response.sendRedirect(response.encodeRedirectURL(url)); doesn't work :( – Victor Dec 16 '10 at 19:52
  • Can you verify if it is the **same** session before and after? Debug by printing/logging `session.getId()` or `${pageContext.session.id}`. – BalusC Dec 16 '10 at 19:58
  • @BalusC The session is the same, I check with session.getId() – Victor Dec 16 '10 at 20:03
  • @Victor Try changing container & / | browser just to make sure – jmj Dec 16 '10 at 20:07
  • This error has never occurs on Firefox, only on IE7. And I cannot change the container... – Victor Dec 16 '10 at 20:17
  • IE is too lenient in caching. Ensure that you've an expires header which is set to 0. See the link I posted in axtavt's answer. – BalusC Dec 16 '10 at 21:53
1

Such a behaviour can be caused by caching.

If the page you are redirecting to is retrieved from the browser cache, you obviously can't see the result of setAttribute() on it. So make sure it's actually requested by the browser.

axtavt
  • 228,184
  • 37
  • 489
  • 472
  • No, I have disabled cache for this page. :) – Victor Dec 16 '10 at 19:42
  • 1
    He has however got a point. You could in Firefox verify with Firebug *Net* panel if it is really not been requested from cache. For the right cache headers, check [this answer](http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers). – BalusC Dec 16 '10 at 19:59
0

Are you sure you need to do redirect through browser (response.sendRedirect()) and not on the server side (RequestDispatcher.forward())? Latter is faster as there are no network round trip.

maximdim
  • 7,449
  • 3
  • 30
  • 43
0

The problem was solve by changing the way of submit.

The page was submitting the data only changing the value of location.href to the Servlet Action.

We only call the submit function from the page form, and the session attributes works fine!

Victor
  • 7,620
  • 14
  • 74
  • 121