Http session persistence on tcp disconnect - http

Question

Concerning an HTTP session: It is either implemented via cookies or URL rewriting.
Since the HTTP 1.1 uses persistent connections, I assume that a session is invalidated when a TCP connection disconnects. Or not?
I am confused on this since otherwise the behavior using cookies vs URL-rewriting would not be the same,right?I mean the browser does not store the values part of the URL-rewriting to disk, correct?
Additionally if it is not, how could we programmatically invalidate it on the server when a tcp connection resets?Is there such e.g. listener in Tomcat?

Answer 1

Since the HTTP 1.1 uses persistent connections, I assume that a session is invalidated when a TCP connection disconnects. Or not?
This is wrong.
In Java the session is implemented via cookie, usually (tomcat, jetty,etc). A cookie called JSESSIONID=1234567 (the number is randomly generated and identifies the session) is set from the server on the first response, then it gets stored in the browser and is sent back to the server for every subsequent connection.
This cookie usually has default lifetime of 30 minutes, and survives when the tcp connection is interrupted. This allows the server to recognize the user across different connections.
URL rewriting means that every URL contains the JSESSIONID as part of the URL, on the server side nothing changes, except that the JSESSIONID value is read from the URL instead than from the cookie.
If the cookie was lost after the tcp connection was closed, it was completely useless. Imagine a chat system based on a persistent tcp connection: do you need a cookie if you can simply identify the connection from an identifier binded to the socket? No... The cookie is useful exactly because you need to track the user across several connections.
Since the HTTP 1.1 uses persistent connections,
They are persistent, in the meaning that after a first request (the html page), the same connection can be reused to send also other resources (images, css, javascript, etc). And the browser keeps the connection open for sometime after, to avoid recreating a new connection in case the user clicks to another link. It's just an optimization, it doesn't mean that when you open a URL in your browser, the connection keeps alive for all the time you lay on the same website.
Additionally if it is not, how could we programmatically invalidate it on the server when a tcp connection resets?Is there such e.g. listener in Tomcat?
On the server, you can always invalidate the session calling session.invalidate().
If you want to invalidate the session every time a request is made, then you simply don't need a session.
Cookie can also be invalidated on the client side via javascript.
I am confused on this since otherwise the behavior using cookies vs URL-rewriting would not be the same,right?I mean the browser does not store the values part of the URL-rewriting to disk, correct?
URL rewriting works where cookies are disabled. Basically, every time you click on a link, the JSESSIONID= is appended to the url, so the server will identify the user, and all the subsequent links will continue to be generated on the server having the same JSESSIONID. In this way, every POST or GET request will contain the identification of the user (the session).
The cookie works in the same way, only that instead of being hardcoded on the URL, it gets embedded in the HTTP request as header information, and this is done by automatically by the browser (unless it has been disabled).
It doesn't mean that it gets saved in the disk (for what purpose?), it just keeps it in memory, for session cookies (that expire when you close the browser or after 30 minutes).
You can set a longer life time for a cookie; in that case, the browser stores the cookie for a longer time. But usually those are not "session cookie", but are cookie used to identify a specific user (like a UUID). From the UUID cookie then you can create a new session cookie when the same user reconnects.
The session, is used to keep track of a CONVERSATION. The user closes the browser, the conversation ends. If there is a persistent cookie like a UUID, then you can use that cookie to create a new conversation and bind the new session to the same user you met before.