When opening a website, your browser and the web server communicate via the Internet using HTTP, a protocol designed to act as a universal language for requesting and delivering web content. HTTP enables web servers and clients (web browsers, mobile apps, etc.) to communicate with each other.
Note: For the scope of this article, I will focus specifically on web browsers, as they are the most common way we interact with sessions and cookies in our daily browsing
When opening a web page, your browser sends an HTTP request to the server, and the server returns with an HTTP response for the browser render a page.
That mechanism is called Server-Side Rendering (SSR), a process where the server determines the content to be displayed and returns it to the client. To provide a continuous experience, SSR-based web applications need to know which user is making each HTTP request.
For example, in an e-commerce website, when you add an item to your cart, an HTTP request is sent to the server. When you later open the cart page, a subsequent HTTP request is sent; because the server knows who you are, it can return a page that already includes your previously added item.
User tracking with HTTP: problem and solution
Although the web server needs to know who you are to provide a seamless experience, HTTP lacks a built-in mechanism to support that. HTTP is “stateless” by design; each request is independent and contains no inherent information about the user's identity or previous actions.
What does that mean? You can think of HTTP as a vast postal service and HTTP requests as standardized envelopes used to carry messages. The system is perfectly efficient at delivering each envelope, but it has no memory; it doesn't track who you are or what you sent five minutes ago.
Because the service won't vouch for your identity, the web application must use a session to recognize you every time a new message arrives.
The idea is simple: whenever an HTTP request is sent to the server, the web browser includes a session ID for the server to know which user is making the request. In the shopping cart scenario, this ensures that when you click 'Add to Cart,' the item goes into your basket and not someone else's. Here is how that flow looks in practice:
Note: the session ID “ABC” is just used for illustration purposes. In fact, the ID is usually a random string with many more characters.
The mechanism behind HTTP sessions
A user doesn’t need to know what their session ID is; the browser and the server work together behind the scenes to manage it. In most cases, they use **cookies **to handle this exchange automatically.
Technically, a cookie is just a key-value pair stored in your web browser. For example, a cookie might look like SessionId=ABC. In this case:
-
The key is
SessionId -
The value is
ABC
However, sessions are managed by the server, and the browser’s responsibility is just to store cookies. Therefore, the server needs to return an HTTP response with a Set-Cookie header to give a cookie with a session ID for the browser:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: SessionId=ABC
When a cookie is stored in the browser’s storage, the browser automatically attaches it to every future HTTP request as long as the cookie is valid (hasn’t expired, belongs to the correct domain, etc).
A simple HTTP request with a cookie attached looks like this:
GET /shopping-cart HTTP/1.1
Host: ping-pong-equipments.example.com
Cookie: SessionId=ABC
Knowing a session ID, the server can retrieve data associated with the session. Most of the web development technologies support session management. For example, for ASP.NET Core, you can get a session’s data like this:
public class CartController : Controller
{
public IActionResult Index()
{
// Get the string value stored in the current session with key = "CartItemIDs"
var rawIds = HttpContext.Session.GetString("CartItemIDs");
var idList = rawIds.Split(';').ToList();
// Subsequent process
return View();
}
}
ASP.NET Core already handles session creation and detection under the hood. Developers only need to access HttpContext.Session from the session’s data.
Usually, sessions’ data is often stored in the server’s memory and lost upon restart. However, it can also be stored in persistent databases or external caches like Redis to ensure it survives a reboot.
Summary
An HTTP session is a way for web servers to remember users across multiple requests in the otherwise stateless HTTP protocol: when a browser connects, the server assigns a unique session ID (usually stored in a cookie), and this ID is sent back with each request so the server can retrieve related data like shopping cart contents or login status
While session data is often kept in server memory, it can also be stored in databases or caches such as Redis to maintain persistence and scalability.
Top comments (2)
Why do we call HTTP protocal is stateless, isn't when it sent request to server it store related to session variable so it should be stateful isn't right?
Great blog btw.
sorry I mean it send with cookie and cookie store variable from previous request so it should be stateful, isn't tight?