Popular posts

The server does not need to store anything, and the client needs to send the cookies on every request

But the session information were stored in the server only. Only the session id was passed to the client. Sorry, still its confusing me

Sivabalan You are confusing the protocol (HTTP) with business logic (your application using sessions) here. The protocol itself does not store any information on the server. Your application is the thing which implements cookie handling and how session information based on cookies is stored. As such, your application might be stateful in the respect that it stores some information about your client, however HTTP itself is not. All state information in the scope of HTTP have to be passed by cookies, which are not stored on the server, but have to be passed back and forth on every request.

Think of it like this: a simple HTTP server cannot differentiate between the first and the n-th request by a client and will always handle them the same way (for example pass the request to your business logic, return a file, etc.).

Sorry for asking two many questions.

1) When we set the cookie using the Set-Cookie header in the response, next time when we call the api, by default session ID was attached to the request header. Is this part of browser functionality?

2) As per my understanding, Request and response headers is part of HTTP. In this case, Set-Cookie designed to my maintain state for the protocol?

Sivabalan

1. yes, cookie management on the client side is done by the browser.
2. exactly. HTTP itself is stateless, so in order to maintain state, cookies are required. The IETF RFC from 2011 describes them as:

   [The HTTP Cookie and Set-Cookie] header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.

Thank you so much for your valuable comments and time