Welcome to the Ranch, Chitra!
You probably should have started a new
thread for your question, since the original question/answers are 17 years old. And actually, they deal with something different, though it might not be apparent to you.
HTTP(S) is a stateless protocol. That is, unlike old-time time-sharing computer services, a web client doesn't simply "dial in" to a web site, do stuff and then "hang up". Instead each HTTP request comes in as a separate self-contained connection which only lasts until the response to that request has been generated and sent back to the client. The next request has to connect all over again. And so forth.
Because of this, the web application cannot tell which of several concurrent web application clients is which by looking at connection IDs, since there
are no ongoing connection IDs. Nor can the application use the source IP address. Every web client on my network appears to be located at 96.90.14.153 to a remote server, because I use Network Address Translation (NAT) to avoid having to rent multiple IP addresses from my ISP (besides, the world ran out of spare IP addresses years ago).
The solution to that problem is to pass a token back and forth between client and server that identifies that particular client to the server. If you are using HttpSessions (session-scope objects and/or container logins), then the token is a randomly-generated value known as "
jsessionid". The jsessonid value is simply a key to a lock and has no inherent meaning itself. All of the HttpSessions active for a web application are stored in a Map internal to the webapp server, and the jsessionid is nothing more than a key into that Map. So when a request with a jsessionid attached comes in, the server knows to retrieve that jsessionid's HttpSession object and make it available to the webapp application code.
Now here is where Vishwath got into trouble 17 years ago. The
jsessionid value is not constant! It is, as I said, a key. That key only has to match the map for the
current request. And the server can change the value of that key at any time!
Why would it do this? One reason would be if you switched from HTTP to HTTPS transport. For example, if you'd logged in instead of just being a visitor. If a network snooper had grabbed the jsessionid value, they could pretend to be that logged-in user. But since the jsessionid has been changed by the server when you logged in, the old jsessionid can no longer find the HttpSession. For this reason, neither client not webabb should ever attempt to cache or otherwise use a jsessionid.
OK, so now you know what a jsessionid is. Here's the part that's specific to you. The jsessionid is transmitted as a key/value pair, where the key name is always "jsessionid". If you're using cookies, that means that you can have a cookie whose name (key) is jsessionid and that's it. In fact, if the client is using a smart HTTPClient library, the cookie is received and re-sent automatically and your client doesn't have to code anything.
But if cookies are disabled…!!!
Well, that means we don't have a place to put the
jsessionid. Or do we?
In practice, there's a process called "URL Rewriting" that can be done when a web application sends back a URL as a hyperlink or form submit URL (action) to carry the jsessionid. It simply appends the
string "
;jsessionid=xxxxxxx" to the link that you rewrite. Armed with that. the webapp server can maintain a session without using cookies.
The URL with appended sessionid ID more fragile than using cookies. But sometimes you simply can't use cookies. So this give the same general effect.
