HTTP is not a session connection protocol. That is, you don't make a "permanent" network connection to the server and keep using it.
Instead, it operates more in a hit-and-run mode. Every HTTP(S) request you make connects to the server, pushes the request payload up and receives a response back. Then it disconnects. Repeat over and over again.
Technically. In actual fact, there's generally a "keep-alive" mechanism that reduces some of the work for repeated connections, but as far as the app code is concerned, every request is a fresh connection.
Because of that. you cannot know the requester's identify merely because of the connection the way you would if you logged in as a time-sharing user on a traditional computer system. So instead
the each request has to be self-identifying.
The preferred way to do that is to include an identify cookie in the request (jsessionid). The nice thing about this is that the built-in java.net http classes manage cookies for you automatically. As, of course, do all major web client apps (browsers
etc.)
But sometimes that's not possible. There may be legal or physical constraints on using cookies. Or you may be working in a shop where the resident "genius" fatuously declares "Cookies are BAD because 'X' and are expressly forbidden in all our apps". Where "X" is generally some ignorant statement.
Anyway, where cookies cannot go, there's a technique known as "URL rewriting". Well-designed webapps use this as a fallback mechanism because instead of carrying the session ID in a cookie, it's appended to the URL itself. For example, "https://coderanch.com/forums/posts/reply/1234;jsessionid=99e3ad7c". This is done by feeding the bare URL to the url rewriting method which is on HttpServletResponse (I think). You then post the rewritten links to the response (web page) that you send out so that clicking on them will ensure an identification for the next request.
Regardless of whether the session ID comes in from a cookie or from a URL, however, the session ID determines which user made the request. The session ID itself carries no data, It's just a "random" hash key into the server-side sessions dictionary, which allows the sessionID to resolve to something resembling or containing an HttpSession object, thus allowing the server APIs to find things when they're needed, such as the remoteUser login ID from the
JEE security manager or session-scope application objects.
You should never attempt to cache the session ID on the client side. It's only a hash key and it's only guaranteed valid until the next Http(s) request is made to the server. In particular, it is a documented security feature in
Tomcat that when an application user switches to https, a new session ID is generated and replaces the one that had been used previously. That keeps "man-in-the-middle" attackers from accessing secured resources by using an unsecured session ID.
Or in other words, the cookie doesn't go out to the client and stay there. Every HttpServletResponse updates the jsessionid cookie.
