Reputation: 1299

Stateless with cookie vs stateful

I found sth like this:

"stateful – keep track of the previously stored information which is used for current transaction.

stateless – every transaction is performed as if it were being done for the very first time. There is no previously stored information used for the current transaction.

In a purely stateless environment you wouldn’t need this session id. Each request would contain all the information the server would need to process. But many applications need to maintain state to keep track of whether or not a session is authenticated to view certain content or to keep track of what a user is doing. You wouldn’t want to send user credentials over the wire for each request."

I'm quite confuse. So if stateless session with cookie maintain the state so it's mean that: stateless session with cookie= session stateful?

Another think. I found information that session stateless is client side session and stateful is server side session. How we can discuss about client side session if stateless session does not maintain session?

Upvotes: 16

Answers (2)

Abhilash PS

Reputation: 804

By definition, HTTP is a stateless protocol. Since it is a stateless protocol, an HTTP request from a client to a server is independent and carries no knowledge of previous requests or their context. The server treats each request as a separate and isolated transaction, and it doesn't inherently maintain information about the state of the client between requests.

Meaning of stateless

The key principle behind something that is stateful is that it has perfect memory or knowledge of previous calls or requests, while something that is stateless has no memory or knowledge of previous calls or requests.

By stateless, it does not mean that state information is not stored. It simply means that state information is stored outside the server. Therefore, the state of being stateless only applies to the server.

State is either maintained on the servers (stateful architecture) or in a separate database outside the servers (stateless architecture). The HTTP protocol itself does not maintain state.

How does the sessions work?

A session refers to a way of maintaining state information about a user’s interactions with a website or web application.

Sessions can contain various information about the user's activity, data, status, etc. Sessions can make HTTP stateful by allowing the server to keep track and manage the user's interaction with a web application across multiple requests and responses.

How does the cookies work?

A cookie is a small piece of data a server sends to a user's web browser. Cookies enable web applications to store limited amounts of data and remember state information, outside the web server.

Cookies can be associated with stateless sessions as well as stateful sessions.

Stateless session with Cookies

Cookies can be used to support stateless sessions. This is possible by storing all the required session state information in a Cookie. And this Cookie can be used in the further requests.

Using JWT in the cookies is an example.

Here, the session data is stored in the JWT itself, which is held by the client. The server only needs to get the session data from the JWT.

Stateful session with Cookies

A Cookie can also be used to maintain a stateful session.

Here, the server will maintain session information between the requests. The Cookie will contain the session ID for the user for that session. When the server need the session information to process the requests from the user, it will fetch the data using the Session ID from the Cookie.

The following sequence diagram illustrates how cookies and sessions work together to make HTTP stateful:

Client ⇒ Server: Request (without cookie)
 
Server ⇒ Server: Create session (with session ID)

Server ⇒ Client: Response (with cookie containing session ID)

Client ⇒ Server: Request (with cookie containing session ID)

Server ⇒ Server: Retrieve session (using session ID)

Server ⇒ Client: Response (with cookie containing session ID)

Here the server is responsible for storing and handling the session data and the client only holds the session ID.

References

Upvotes: 0

smk

Reputation: 5912

In a purely stateless environment you really don't need sessions or cookies.

Both sessions and cookies are used to maintain state. The only question is where. Cookies maintain the state on the client while sessions maintain state on the server.

From Wikipedia: Representational state transfer

The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication.

So typically in a stateless design, yes there is no state between client requests. Every client request will have sufficient info to perform the requested action. However, you still need authentication and/or authorization so who the client is identified from request headers (typically).

Upvotes: 5