Stateless HTTP and application state

Objectives

By the end of the lesson, you can explain why the server does not remember the previous request, where the state of an application can live (URL, client, server), and why an identifier is needed to tie several requests to one user.

Why is it a problem that HTTP is stateless?

An HTTP request is a self-contained message (2.2): the protocol does not automatically keep track of who sent the previous request and what they did. In MDN's wording, there is no link between two requests carried out one after the other on the same connection. The advantage of this is that the server is simple and scales well. The drawback is that a web application still needs continuity: in the enrolment interface the same student must see their choices across several pages, and the system must know who they are. The application attaches this state to the separate requests.

Several requests from one student

The student opens the course list, selects a subject, then moves to the enrolment page. The server sees three separate HTTP requests, each arriving with its own method, URL, headers, and possible body. HTTP alone does not tie them to a single person.

sequenceDiagram
    participant B as Browser
    participant S as Service
    B->>S: 1. Request the course list
    S-->>B: Response
    B->>S: 2. Request the details of a course
    S-->>B: Response
    B->>S: 3. Request enrolment
    S-->>B: Result

The diagram shows a temporal order, not a common, automatic HTTP memory. A separate mechanism is needed to connect the three requests. Tried on the trial server: if the request carries no identifier, the server does not know who is asking for the student's enrolments:

$ curl -i http://localhost:8085/jelentkezesek/anna
HTTP/1.1 401 Unauthorized
{"hiba":"nincs bejelentkezve"}

(The error text "nincs bejelentkezve" means "not logged in".)

What does statelessness mean?

The statelessness of the protocol means that interpreting each request does not involve conversation state automatically inherited from earlier requests. This does not mean that the server cannot store a database, or that you cannot log in on the web. MDN also draws the distinction: HTTP is stateless but not "sessionless": cookies make a stateful session possible. The service creates continuity through the identifiers carried in the messages and its own data storage.

Lesson 5.3 also discussed the statelessness of REST: the request carries the context needed to interpret it. The question examined here is the user state of the application. The two are related, but neither claims that "there is no state anywhere".

Where can state live?

State	Natural place	Why?
Filter of the course list, selected course	URL	Shareable, retrievable (6.5)
An open panel, text typed but not yet sent	Memory of the client	Short-lived view state
An unfinished local draft	Browser storage (3.6), if justified	Continuing later
Accepted enrolment, access right	Server	Official data affecting several users

Not all state has to go to the same place. The rule is that whatever is official or of security significance belongs on the server, because the client's code can be modified (1.4).

Continuity and identifier

A service finds the state stored on the server side by the identifier that appears in the successive requests. The identifier can be of several kinds: a session identifier sent in a cookie (7.2) or an access token sent in the Authorization header (7.3). The identifier by itself is not the user's name, and it is not advisable to write personal data into it.

flowchart LR
    K1[1st request + identifier] --> S[Server: finds the state by the identifier]
    K2[2nd request + identifier] --> S
    K3[3rd request + identifier] --> S
    S --> A[(Server-side state)]

The state shown by the interface and the official state of the server can differ. If two students try to take the last place at the same time, the server must decide, when processing the enrolment, who succeeds (2.4: 409). The number of places the browser saw earlier is only momentary information.

Worked example: the enrolment flow of Kurzuspont

The student enrols in three steps: selects a course, confirms, submits.

Step	What carries the state?
Selected course	The URL (/jelentkezes/webprog): shareable and still there after a refresh.
The "I confirm" checkbox	The memory of the client: lost on refresh, which is acceptable.
Who is enrolling?	The session identifier in the request: from this the server knows who the student is.
The actual enrolment	The database of the server.

If the student disappears and returns later, the server recognizes them by the session identifier (if it is still valid), otherwise they must log in again.

Common misconceptions

Statement	Clarification
"With stateless HTTP you cannot log in."	A cookie, a token, and a server-side session can connect the requests.
"The server stores no data if HTTP is stateless."	The message of the protocol and the application's data storage are separate concepts.
"The number of places seen by the client is the final truth."	The server decides on the current state at the moment of the operation.
"The identifier is the user's name."	It is a random marker that the server traces back to the user.

In brief

• HTTP is stateless: there is no automatic connection between requests.
• The application creates continuity with an identifier and server-side storage.
• State can live in the URL, the client, or the server; official and security state belongs to the server.
• The state seen by the client is a momentary copy.

Review questions

1. What does it mean that HTTP is "stateless but not sessionless"?
2. Which state would you put in the URL, in the memory of the client, and on the server in an enrolment flow?
3. Why is it not enough to store in the client that the enrolment succeeded?
4. What is the session identifier for?

Learning resources

• Overview of HTTP (MDN) — the section "HTTP is stateless, but not sessionless".