Stateless HTTP and sessions

A connection is not a user session.

UnderstandStudy an examplePractise

Understand the concept

Stateless HTTP means request semantics do not rely on an implicit conversation history. Applications can still maintain sessions. An opaque cookie identifier can reference server-side user context. Reusing a TCP connection does not identify a user.

Authorise each request after login. Logout requires invalidating the relevant session or renewal mechanism, not merely hiding UI. Distributed systems need deliberate storage, expiry, revocation and device management.

JWTs do not eliminate all state requirements: revocation, key rotation and permission changes remain concerns. Controls such as rotating session identifiers at login help prevent fixation. Never equate a transmitted identity with permission to perform an operation.

WHEN TO USE IT

For login design and load-balancing decisions.

COMMON PITFALL

Assuming stateless HTTP prevents application sessions.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

GET /account HTTP/1.1
Host: example.test
Cookie: session=opaque-example

Each request carries identity context.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

Can one connection carry requests associated with different users?

Show the solution and explanation

Worked solution

Connection identity ≠ application identity

Yes; never infer user permissions from connection reuse.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.