An HTTP cookie is a small piece of data that a server sends to a client. The server sends the cookie using the Set-Cookie header in the response. It looks like that:
Set-Cookie: trackingCookie=user1357272
User-agent saves a cookie from the response and sends it back in the Cookie request header like that:
Cookie: trackingCookie=user1357272
Cookies are used for the following purposes:
1. Session management
HTTP is a stateless protocol meaning that two requests cannot be correlated to the same source or to each other even if they are sent from the same IP address and contain the same user-agent. In other words, without some additional information, the server is not able to understand that two requests were sent consequently by the same user.
To keep the flow of all the user’s requests, session identifiers are used. Usually, a session identifier resides in a cookie and is sent with every request in the Cookie header. Thus the server can track all actions the user makes, display him the right interface, and send responses with correct data
2. Personalization
Sometimes cookies are used to store user preferences and non-sensitive application data.
3. Tracking
Nowadays many companies try to understand their users’ behavior and track all the actions users make. Cookies can be used for this purpose as they can persist in the browser, until cleared, and can be tied to the user behavior, even if the user is not authenticated.

GET /courses HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,ru;q=0.8
Cache-Control: max-age=0 
Upgrade-Insecure-Requests: 1
Cookie: sessionid=b3cd288f3e3d499ca8e45fbae696f7b5 
Connection: close


Each cookie has a set of attributes.


This is the cookie that will be set and then used with every subsequent communication of the user-agent with this server.

Scope (Domain and Path)
Domain attribute defines names of domains where the cookie can be used. If the Domain is not specified, then the current domain (excluding subdomains) is used by default.
If Domain is specified, then all subdomains are included, for example, Set-Cookie: whoLikesCodebashing=me
The browser will send this cookie to and to all its subdomains like
If Domain is not specified for the cookie, e.g. Set-Cookie: whoLikesCodebashing=me then the browser will send it only to
The browser checks the Domain attribute and doesn’t send a cookie if attribute’s value doesn’t match the specified domain or its subdomains.

Scope (Domain and Path)
Path attribute contains the URL path. If the Path is defined, then the browser sends the cookie only if the specified path or its subdirectories are present in the request.
For example, the following cookie Set-Cookie: whoIsAnEvilHacker=Bob;; Path=/secret/bobs/folder; is sent only in requests to and subfolders.

Expiry date
If Expires or Max-Age attributes are not set for the cookie, it is stored on the client side as long as the browser keeps it.
If Expires or Max-Age attributes are set, then the browser invalidates the cookie as soon as its lifetime ends.
Note that the cookie invalidation on the client side is not enough; cookies must be invalidated on the server whenever they expire.

Secure flag
This flag indicates to the browser that the cookie must not be sent via an unencrypted connection. You can check out our lesson about the secure cookie flag for more details.

HttpOnly flag
This flag instructs the browser to restrict access to the cookie from javascript. For example, Document.cookie does not return cookies with the HttpOnly flag. Only the browser has access to the cookie, and it will still attach them to HTTP requests to servers allowed by the same-origin policy. You can check out our HttpOnly cookie lesson.

Comments are closed.