1

I have a legacy Java 1.6 running localhost with Tomcat 7 application using JSP pages, a frameset with frames, javascript, but no framework like Struts. I pass an object to display in the page from the servlet using the request or session and that works fine.

However, I made some changes recently and now I can't retrieve that same object back from the session or request. It had been working fine previously, so I'm not sure what is broken, but I can't even send a string value back from the JSP's back to the servlet.

I created a new stripped down JSP and I can't get anything back from that either using the request or session. It does the same thing when I push the code our Tomcat 6 web server. Using the debugger, I see the objects populated in the session, but then lost later when a new session is created each time as in using this simple code to get the sessionid:

System.out.println("The session id is: " + session.getId());

The session id is: EB431C19B41957B2BB2EFC3DBAF32241

The session id is: C9CBD30E84D5C93DF6114C1412AE5523 I then see this in firebug under the Header, response headers:

Set-Cookie JSESSIONID=C9CBD30E84D5C93DF6114C1412AE5523; Path=/Name omitted here/; HttpOnly,

so I know cookies are set. I also removed jquery and I"m stripping down the jsp code as much as possible, but that doesn't seem to be the issue.

I'm using: HttpSession session = request.getSession(true); but using false didn't matter.

session.setAttribute("ObjNameList", objNameList);

The context.xml has cookies set to true and we do use response.sendRedirect, but only if an error is thrown as in: response.sendRedirect("Error.jsp"); There is no place in the code with session invalidate either.

All I'm doing from the jsp is sending a form back using something like:

document.formName.submit(); which works fine. Using this code to try and set a simple string in the session doesn't work either:

session.setAttribute("somevalue","someValue");

Gives me null in the servlet here:

String val = (String) session.getAttribute("somevalue");

Any ideas as to what could be causing this?

Resultion:

It turned out to be an issue with the url, a typo actually, as BalusC mentioned, so the path for the session cookies didn't match between the jsp and the servlet.

James Drinkard
  • 15,342
  • 16
  • 114
  • 137
  • Session cookies are tied to specific domain+path. Just open up the HTTP traffic monitor in webbrowser's developer toolset and track cookie traffic. – BalusC Jul 07 '15 at 14:48
  • I had firebug and live http headers. I just added httpfox to use for monitoring. Is this what you were thinking of? – James Drinkard Jul 07 '15 at 15:22
  • Yes, check there if cookies behave as per expectations. – BalusC Jul 07 '15 at 15:23
  • You observed that the server has set the cookies. But did the client return them in the subsequent request too? Check the `Cookie` header. If this is absent, then apparently the cookie domain+path which were set in `Set-Cookie` header didn't match that of the request on which the `Cookie` header needed to be set. Have you modified the session cookie path in Tomcat or web.xml configuration or so? "Name omitted here" looks strange as it usually just represents the context path. – BalusC Jul 07 '15 at 18:27
  • No, the session is null when the request comes back from the jsp in the servlet. I'll check the cookie header. I don't have anything set for session cookies, except in the context.xml to cookies="true". Name omitted here means I don't want to put the actual context path. No, I haven't modified the web.xml – James Drinkard Jul 07 '15 at 18:40
  • Sorry for all the comments. I verified that the same sessionid that the jsp received from the servlet is coming back from the jsp to the servlet under Set-Cookie JSESSIONID=68C671EE30EFF67A77EE3A993413B6DC; However, the session is null when the servlet receives it and then it generates a new sessionid again. – James Drinkard Jul 07 '15 at 18:57
  • In other words, the browser didn't send the session cookie back. Well, as said, that will happen if the cookie domain+path does not match the request's one. – BalusC Jul 07 '15 at 19:00
  • Yes, but I thought tomcat 6 set the default cookie to the domain. So do I need another setting for this in the context.xml file? – James Drinkard Jul 07 '15 at 19:07
  • No, the next step is to verify if the cookie domain+path matches with request's one. I have given this hint several times, but you have nowhere (dis)confirmed that. – BalusC Jul 07 '15 at 19:08
  • BalusC- If you put your comments in an answer I'll mark it. You did all the work. – James Drinkard Jul 07 '15 at 21:10

1 Answers1

2

Doublecheck if the request URL to that servlet matches the session cookie domain and path. If it doesn't match, then the browser simply won't send the session cookie back along with the request and the server will think that there's no means of an established session and will therefore simply create a new one.

You can check cookies in the HTTP traffic monitor of browser's web developer toolset (press F12 in Chrome/Firefox23+/IE9+ and open "Network" tab). When a new session starts, the server must have returned a response with Set-Cookie header with therein the cookie value and path (and implicitly domain). When the browser sends a subsequent request on the same domain and path, then it must have passed that cookie back via Cookie request header.

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555