[Network]1.Cookies in HTTP
Overview
HTTP protocol is stateless, and a HTTP cookies is what enables HTTP to remember some states of a user, like to tell whether two requests come from the same browser, to keep the user logged in.
Three main usages of a HTTP cookie:
- Session management: Logins, shopping carts, game scores, or anything else the server should remember
- Personalization: User preferences, themes, and other settings
- Tracking: Recording and analyzing user behavior
Cookies are sent with every request, which results in bad performance. More modern ways to save states will make use of localStorage
, sessionStorage
, and IndexedDB
.
Using Cookies:
A server will use Set-Cookie
headers with response to store some cookies in client's browser, and the cookies will be sent with each request to the same server.
Basic Usage
The most primitive usage of Set-Cookie
is : Set-Cookie: <cookie-name>=<cookie-value>
. In the header, it will look like:
HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry
[page content]
And in the next request it will be:
GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Specify Lifetime
Use Max-Age
or Expires
fields to specify a lifetime of a cookie:
- Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
: The maximum lifetime of the cookie as an HTTP-date timestamp. If unspecified, the cookie becomes a session cookie. A session finishes when the client shuts down, and session cookies will be removed.
- Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
: Number of seconds until the cookie expires. A zero or negative number will expire the cookie immediately.
Specify Access Range
We can use Domain
, Path
and SameSite
fields to specify the access range of a cookie:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
- If omitted, only the host of the current document URL will be allowed, no subdomains are included.
- If specified, all the subdomains are allowed. E.g.: if domain is
example.com
,study.example.com
is also included. Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
- A path must exist in the requested URL, or the browser will not send the Cookie.
- All the subdirectories are included. E.g.: for
Path=/docs
,/docs/
,/docs/web
,/docs/web/http
are all included, Set-Cookie: <cookie-name>=<cookie-value>; SameSite=<samesite-value>
.- This controls whether cookie can be sent with cross-origin requests. There are three possible values of
samesite-value
:- Secure: The browser sends the cookie only for same-site requests.
- Lax: The cookie is not sent on cross-site requests, such as calls to load images or frames, but is sent when a user is navigating to the origin site from an external site.
- None: The browser sends the cookie with both cross-site and same-site requests.
Specify Security
We can use Secure
or HttpOnly
to specify the security level of the cookie. These two fields don't have any values.
Set-Cookie: <cookie-name>=<cookie-value>; Secure
- Cookie is only sent to the server when a request is made with the
https:
scheme. Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
- Forbids JavaScript from accessing the cookie, for example, through the
Document.cookie
property.
Send Cookie Crossing-Origin
- We can't send cookies from one site from another. But if the current visiting site is
a.com
and it can send cookies when requestingb.com
server. - On the web clients side, we need to set
withCredentials
attribtue totrue
. - On the server side, we can't set
Access-Control-Allow-Origin
to*
, otherwise we will haveThe value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*'
error.