What is the purpose of a JSESSIONID suffix?

2.8k views Asked by At

After using a browser to authenticate into my service, I find a cookie set with the following key\value pair:

JSESSIONID=40d4b01c47ddb858718291d319a1a817d3037fdc6f2c341c195a94dc6ee8e8a1.e38Lb3qTb3aKai0RbxeMahqNbN90; path=/MyService; secure

Note the suffix (i.e. after the '.' : e34Mc3uLa3yPbO0La3aNa3eTc38Ke0)

When I use Java servetl's API to get the session id (javax.servlet.http.HttpSession.getId()), I get the following value

40d4b01c47ddb858718291d319a1a817d3037fdc6f2c341c195a94dc6ee8e8a1

Which is the same as the first portion of the cookie variable value I just mentioned !

I once tried to maintain a session between multiple HTTP requests on ColdFusion (CF) (Its ok if you don't know what CF is, its simply a platform to develop applications) and I couldn't maintain the session if I set the cookie variable JSESSIONID to the whole value I mentioned in the beginning in this question. To maintain the session correctly I had to send the first portion of the session id (i.e. before the '.')

So my question is, why does the servlet API return a part of the JSESSIONID, while the cookie value returned from the server has a suffix ? Where does this suffix com from and what is it's purpose ?

1

There are 1 answers

0
noamik On

The suffix could for example be the hostname of the server. Or it could be a random value. It's generation, configuration and meaning depends on the application server used, since it's not part of the servlet specification.

It's useful in non-clustered setups to make sure a session actually belongs to a server. Imagine a load-balancing setup with sticky sessions and a server failure. Requests are now directed to another server. In theory this server could also have a session with the same session id. The user would then get into a session that doesn't belong to him. Appending a server unique suffix enables the application server to not restore sessions that weren't created in the same server.

You can get an idea of this here: https://developer.jboss.org/message/879684 where differences in this very behavior between jboss 7 and wildfly 8.1 are discussed.