5.1.5 Session
Session
Web developers sometimes opt to store information on the server side rather than the client side. This decision is motivated by a desire to conceal application logic and to minimize the back-and-forth data transmission, a characteristic behavior of cookies. HTTP sessions provide a straightforward mechanism that enables websites to store variables specific to a given visit on the server side. Each user session is uniquely identified by either a session ID or token, assigned by the server.
Session vs Cookies
Storage Location:
Cookies are stored on the client side.
Session variables are stored on the server side.
Expiration:
Cookies can have a longer lifespan and persist even after the browser is closed.
Session variables expire with the session, usually sooner than cookies.
Session Mechanism
Session Token (or Session ID):
Assigned by the web server to the client.
Presented by the client in subsequent requests to be recognized.
Acts as a primary key to retrieve client state and associated variables on the server.
Session Cookies
Contain a single parameter in a key-value pair format.
Examples:
SESSION=0wvCbOBWDH8w
,PHPSESSID=13An5Z6Uo4pH
,JSESSIONID=W7DPUBgw7kTM
.Session IDs can be stored in text files, databases, or server memory.
Session Cookie Installation:
Servers can install session cookies after specific client activities, like logging in or opening a page.
The browser includes the session cookie in subsequent requests.
Session cookies help maintain variables, reducing bandwidth usage.
Session Cookie Example:
The client uses a login form, and the server responds with a Set-Cookie header containing the session ID.
The browser includes the session cookie in subsequent requests.
Any subsequent request carries the session cookie, allowing the server to recognize the client.
Alternative:
Session IDs can be sent via the GET method appended to the URL.
Example:
http://example.site/resource.php?sessid=k27qds7h1w
.
Last updated