Glossary Term
HTTP Session
Learn what HTTP sessions are and how they maintain state across stateless HTTP requests. Understand session cookies, tokens, and server-side storage.
On this page
TL;DR: A web session associates independent HTTP requests with application state, often through an opaque ID in a cookie. Cookie lifetime and server-side session lifetime are separate; closing a browser is not reliable logout.
Why Sessions Exist
HTTP does not automatically associate two requests with the same logged-in account. An application adds that association. A server-side session can hold a user ID or cart while the browser carries only an identifier. HTTP connection reuse is not a login session.
For a multi-step form, the record can hold a draft ID while each page submits the same cookie. Verify ownership again when saving the draft; knowing its ID or finding it in a session does not replace the application’s access checks.
How Sessions Usually Work
After authenticating, the server creates a session record and sets a cookie. Illustrative header, where opaque-session-id stands for a randomly generated value:
Set-Cookie: __Host-session=opaque-session-id; Path=/; Secure; HttpOnly; SameSite=LaxA later eligible request carries:
Cookie: __Host-session=opaque-session-idThe browser does not echo Secure, Path, or SameSite in Cookie. The server uses the ID to find state and checks whether that session is still valid.
The Important Distinction
“Session cookie” means a cookie without Expires or Max-Age, not necessarily a cookie containing a session ID. An authentication cookie can be persistent; a session cookie can hold a preference instead. Browser session restoration can restore session cookies after a restart.
Sessions can also keep state in a signed cookie or token. Server-side storage is a common implementation, not the definition of every session. The Set-Cookie reference explains cookie lifetime and prefix rules.
Why Session Bugs Feel Weird
If login disappears on the next request, first check whether the response set a cookie and whether the next request sent it. Then check domain, path, Secure, SameSite, and the server-side record. Cross-origin Fetch needs credentials: 'include' for cookies, plus appropriate CORS permission. Cross-origin and cross-site are different tests.
A load-balanced application can send a valid ID to a server that cannot find the record if its session store is process-local.
Security Matters Here
Secure restricts transport to secure connections; HttpOnly prevents direct JavaScript access to the cookie. It does not stop injected scripts from making authenticated requests. Rotate the session ID after authentication and enforce expiration and logout in the server-side store.
RFC 6265bis remains work in progress in the RFC Editor queue as of this review; do not present its draft number as a published RFC.
Related
Frequently asked questions
What is an HTTP session?
A session associates application state with otherwise independent HTTP requests. A common implementation stores an opaque ID in a cookie and state on the server.
How do sessions work?
In a server-side session, the server gives the client an identifier and uses it on later eligible requests to retrieve and validate stored state. Other implementations carry state in signed cookies or tokens.
What is a session cookie?
A session cookie has no Expires or Max-Age attribute, regardless of what it contains. Browser session restoration can restore it after restart, so closing a browser is not reliable logout.
How do I secure sessions?
Use HTTPS and Secure, HttpOnly cookies for browser session IDs. Rotate the ID after authentication, enforce server-side expiry and revocation, and protect cookie-authenticated mutations against CSRF.
Sources
Related
Content Negotiation
Content negotiation lets one URL serve different formats, languages or encodings based on Accept headers. See q-values, Vary, 406 and the caching traps.
HTTP Header
Learn what HTTP headers are and how they provide metadata about requests and responses. Understand common headers like Content-Type and Authorization.
Idempotent
Learn what idempotent means in HTTP. Understand why GET, PUT, and DELETE are idempotent, why POST is not, and how idempotency affects API design.
HTTP Method
Learn what HTTP methods are and how they define actions on resources. Understand GET, POST, PUT, DELETE, PATCH, and other methods with examples.