GET does not include JSESSIONID

[Harry Jones]

I deployed a small web application and have run into a problem with both Firefox and IE8. When I go to my site, the first time I click on a link, the GET does not include JSESSIONID. After the first time, the link works fine. I confirmed that this is happening with Firefox and Live HTTP headers.

The problem does not occur all the time. It seems to be only the first time I click on a link, and it occurs inconsistently.

Can you advise me on why this is happening? What would cause a browser to fail to include a session id with a GET? Thank you for your help.

[William Brogden]

Why would you expect the first request to include JSESSIONID?

That cookie is only set by the response to the first request to a given web application.

Bill

[Harry Jones]

When I access the application and logon, it creates a new session id and includes it with the response, which is a successful logon page. When I click on a link on the successful logon page, the browser does not include the session id with the GET. Then my application doesn‘t know how to handle the request.

[Stefan Evans]

The Session id is normally sent via a cookie rather than as a parameter on the request, and so will not be directly visible on the URL. You can use a tool like Fiddler or Firebug to watch the HTTP requests being sent, and verify that a cookie is being sent/received.

For debugging purposes you could display the <%= session.getId() %> on your page to see if you are retaining the same id between requests.
<%= session.isNew() %> might also provide a useful indicator.

To support clients that disable/ignore cookies, you need to use the response.encodeURL or response.encodeRedirectURL as appropriate on any urls that you render onto your page.

The link from your login page is to the same web app on the same server right? (just checking...)

[Harry Jones]

Thanks for your post.

Yes, everything is on the same virtual server at GoDaddy. My application tests session.isNew() in the first servlet to make sure browsers have cookies enabled.

I used Live HTTP headers and Firefox to try to figure out what was going on. I am basing my description of the problem on that, although I may have misinterpreted what I think I am seeing. Here is the list where Firefox omits the valid sessionid with the GET. The first request/response is for the logon. Part of the login process is that I invalidate the initial session id and create a new one. The second request/response is for the link. I tried to set this off as a list but this was the best I could do.

http://www.vorev.net/com/logon

POST /com/logon HTTP/1.1
Host: www.vorev.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0C)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.vorev.net/
Cookie: JSESSIONID=98CC50CD25926BF1C233D47635B834A6
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
action=Logon
HTTP/1.1 200 OK
Date: Wed, 16 Mar 2011 23:02:03 GMT
Server: Apache/2.2.3 (CentOS)
Set-Cookie: JSESSIONID=19BDF3093701B14DF75DDC743646F080; Path=/
Cache-Control: private
Etag: 84130826
Last-Modified: Wed, 16 Mar 2011 23:02:03 GMT
Content-Length: 572
Connection: close
Content-Type: text/html;charset=UTF-8
----------------------------------------------------------
http://vorev.net/add.jsp

GET /add.jsp HTTP/1.1
Host: vorev.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0C)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.vorev.net/com/logon

HTTP/1.1 200 OK
Date: Wed, 16 Mar 2011 23:02:05 GMT
Server: Apache/2.2.3 (CentOS)
Set-Cookie: JSESSIONID=550213F486022648C9702E40A8E0DFE0; Path=/
Content-Length: 436
Connection: close
Content-Type: text/html;charset=UTF-8

[Harry Jones]

I did research with the suggestions of Stephan Evans and found out more. I created a small sample application to demonstrate.

I type the URL mysite.net and click on the button for Page 2. The session id is the same on the second page. I click on the link on the second page. Again on the third page I see the same session id.

After clearing the cache. I type the URL www.mysite.net and repeat the same steps as above. Now the session id on the third page is different.

So the only difference is in the first case I used mysite.net, and in the second case I used www.mysite.net. I am thinking this may be a security issue. Is this a situation where the browser won't retain a session id if it thinks it is going to another site via a link (i.e., www.mysite.net vs. http://mysite.net/mypage.jsp)? Is everything fine when you use the URL mysite.net because the link is the same, http://mysite.net/mypage.jsp?

IE and Firefox have the same behavior. These browsers must realize vorev.net and www.vorev.net are the same site. I must be missing something here. I can deploy the application if anyone wants to try it.

Thanks for your help.

[Stefan Evans]

>So the only difference is in the first case I used mysite.net, and in the second case I used www.mysite.net

That is difference enough as far as cookies are concerned.
The session cookie is issued for a specific domain. It sees this as two separate domains, and thus treats it as two separate sessions.

[Harry Jones]

Thanks for the explanation. I have really been struggling to understand what was happening.

How do people deal with this situation? Is there some way to convert a www.mysite.com request to mysite.com? Or is there some other way to handle it so as not to trigger a new session?

[Bear Bibeault]

I have my hosting service route all requests to xyz.com to www.xyz.com. That way, there's only one that needs to be dealt with.

[Pete Nelson]

Harry Jones wrote:How do people deal with this situation? Is there some way to convert a www.mysite.com request to mysite.com? Or is there some other way to handle it so as not to trigger a new session?

There are a number of ways to deal with this.

Perhaps the easiest way to solve your issue would be to use the cookie.setDomain(".mysite.com"). Then that cookie would be used for any request in your domain (within the limits of the cookie's path).

If you're asking how I do URL rewriting, in practice, I run Tomcat behind an Apache Web Server, and take advantage of RedirectMatch in Apache. If you really wanted to implement URL rewriting via Tomcat, it could probably be done rather easily using an implementation of javax.servlet.Filter.

[Harry Jones]

Based on the guidance provided, here is my solution. After a successful logon, I invalidate the existing session and create a new one, followed by this code:

                    Cookie cookie = new Cookie("JSESSIONID", request.getSession().getId());
                    cookie.setDomain(".mysite.com");
                    cookie.setPath("/");
                    response.addCookie(cookie);

As a greenhorn, this was a major problem for me. I really appreciate the help and want to thank everyone who replied.