When you study web development, you inevitably encounter the phrase "HTTP is a stateless protocol." Yet on real websites, once you log in, you're still recognized as yourself as you move between pages, and the contents of your shopping cart persist.

How is the "logged-in state" achieved using HTTP, which is supposed to hold no state? I've organized how the mechanism works.

Conclusion: State Is Managed Outside of HTTP

Rather than giving the HTTP protocol itself any state, the server keeps the state on its side and only exchanges an identifier (ID) with each request, which produces pseudo-stateful behavior.

The basic flow is as follows.

  1. On successful login: The server stores the information "this person is so-and-so" in memory or a database (a session), and issues a unique ID (session ID) that points to it.
  2. Storing on the client: The server uses response headers to make the client (browser) store that ID (mainly via a Cookie).
  3. Subsequent requests: Every time the client sends a request, it automatically attaches that ID and sends it to the server.
  4. Restoring the state: Using the ID that arrived, the server pulls out the stored session information and concludes, "Ah, this is a logged-in user."

Two Representative Management Methods

Login state management broadly falls into two approaches: the "session approach" and the "token approach."

1. Session + Cookie (Managed on the Server Side)

This is the most traditional and common method.

  • Mechanism: User information is kept on the server side, in a database, Redis, or similar. The Cookie stores only the session ID, which serves as the "key" for retrieving that information.
  • Characteristics:
    • Because the server manages the state, logout (deleting the session on the server) can be done reliably.
    • Requires storage (a DB or Redis) to hold the session information.

2. Token Approach / JWT (Self-Contained on the Client Side)

This is a method often used in modern web APIs and single-page applications (SPAs).

  • Mechanism: The user information itself is embedded in a signed token (JWT: JSON Web Token) and held by the client. The server only verifies that the signature of the arriving token is valid, and does not need to keep any data on hand.
  • Characteristics:
    • Because the server holds no state (fully stateless), it scales easily.
    • There is a challenge in that it's hard to forcibly invalidate a token from the server side once it has been issued.

Why It Works Even Though HTTP Is "Stateless"

HTTP is stateless, but applications can behave statefully.

HTTP being stateless is merely a constraint at the protocol level that says "each request does not need to remember the previous one." However, by including an identifier in the request headers, the application layer (the server-side program) is free to reconstruct past context.

If you think of it as "presenting a self-introduction card (a Cookie or token) with every request," it should make sense why the exchange works even though HTTP itself has amnesia.

Summary

Maintaining login state is not achieved by extending the HTTP protocol, but rather through an application-side technique of "external storage plus passing an identifier."

Understanding the principle that "HTTP is stateless," and knowing how its limits are compensated for, is the first step toward designing secure and scalable websites.