HTTP Session Tracking

Question

Since HTTP is a stateless protocol, when a client makes a number of requests to the server, how does the server uniquely identify a particular client's requests over a period of time say t1, t2, t3..

I browsed the web and came across terms like session id, URL rewriting and cookies. But it would be great if someone explains it in a better way. Specifically which part of the HTTP request and response would be used for session tracking?

Answer 1

Session tracking is a server side thing.

A web server issues some session identifier that is returned to the browser. Browser submits this session identifier along with each request.

This is probably done using cookies transparently for the user.

Answer 2

the session handling is in most case handled by sending a cookie to the client. that cookie would be sent back to the server on every request from that particular client.

The session id will be associated with some resources on server side (file,ram space) so the server by reading the session id in the cookie can find this resource and then know which client it was.

Answer 3

Specifically which part of the HTTP request and response would be used for session tracking?

In the HTTP response, the server can set a cookie. It does so with the Set-Cookie header. For example:

Set-Cookie: session=12345; path=/

The client then returns the value of all cookies that match the properties that were set along with the cookie, which can include path (as above) and domain, and that haven't expired yet.

The cookie is sent back to the server as part of the HTTP headers. For example:

Cookie: session=12345

None of the original property information is sent back with the cookie.

A unique cookie allows the server to associate a unique key with a particular browser instance. The server can then use that key as an index into a hash table or a database table that holds unique per-user state information.

Answer 4

Find enough details here

HTTP Sessions are the recommended approach. A session identifies the requests that originate from the same browser during the period of conversation. All the servlets can share the same session. The JSESSIONID is generated by the server and can be passed to client through cookies, URL re-writing (if cookies are turned off) or built-in SSL mechanism. Care should be taken to minimize size of objects stored in session and objects stored in session should be serializable. In a Java servlet the session can be obtained as follows:

HttpSession session = request.getSession(); //returns current session or a new session

Sessions can be timed out (configured in web.xml) or manually invalidated.

Answer 5

Taking ASP.NET as an example, ref Fig. 1 in

http://www.codeproject.com/KB/aspnet/SessionTimeoutOnDNN.aspx

Answer 6

As you mentioned, common ways to implement HTTP session tracking include URL rewriting and cookies. Session tracking basically requires that a session ID is maintained across multiple requests to the server. This means that each time a given client makes a request to the server, it passes the same session ID. The server can use this ID to lookup the session information it maintains.

When using cookies, the server asks the client to store a cookie by setting the Set-Cookie HTTP response header. This cookie contains the unique session ID assigned to that client - in this example the string 'ABAD1D':

    Set-Cookie: JSESSIONID=ABAD1D;path=/

The cookie is then sent back to the server by the client using the Cookie HTTP request header on each request and thus the server is informed on each request the session ID currently assigned to the client.

    Cookie: JSESSIONID=ABAD1D

When using URL rewriting, this same session ID is instead sent somewhere in the URL. Again, the server extracts the session ID from the URL so that it can lookup the session for a particular client:

    http://my.app.com/index.jsp;JSESSIONID=ABAD1D

However, the server must also make sure that any URLs in the web pages sent back to the client are also rewritten to contain that particular clients session ID. As the session ID is encoded in the URLs, this method of session tracking is transparent to the browser. Often a server will resort to URL rewriting if it finds it is unable to set a session cookie on the client - implying that the client does not support/allow cookies.

Note that sessions can expire. This means that if the server does not 'see' a given session ID for a period of time, it may remove the session data to preserve resources.