Abstract: This article will introduce the relevant knowledge of browser Cache Control in detail, including cookie, session, localStorage, cache-Control, Expires, ETag, last-Modified and other concepts.

Note: Before reading this article, it is recommended to have a look at how the login registration function is implemented in the web page, to have a general understanding of the data interaction between the front end and the back end.

1. What is a cookie && what can a cookie do

Let’s give cookies a definition

Cookies are called “small text files” or “little Cookies” in Chinese. Data stored (usually encrypted) on a user’s Client Side by some web sites to identify the user. — from Wikipedia.

How to explain it colloquially

  1. Cookie is a piece of data sent by the server to the browser after the browser accesses the server.
  2. The browser needs to save this data and not delete it easily.
  3. Every time a browser visits the server thereafter, it must bring this data.

So you can figure out the characteristics of cookies

  1. The server is set to **Set-CookieResponse header ** to set the cookie
  2. After the browser gets a cookie, the cookie is added to the request header for each same-origin request
  3. The server reads the cookie and knows the login user’s information (such as account name, etc.).
  4. Cookies are actually stored on the local computer’s hard drive
  5. The maximum storage capacity of cookies is usually only 4K

So what are the disadvantages of cookies?

  1. Cookies can easily be tampered with by users (sessions can solve this problem and prevent users from tampering)
  2. The default validity of cookies theoretically expires after the user closes the page, but in practice it expires in about 20 minutes, depending on browser policies. However, the backend can enforce a validity period (see below for how to set this).
  3. Cookies also have a certain amountThe same-origin policy, but slightly different from AJAX’s same-origin policy. Such as:
    • When requesting resources under QQ.com, the browser will bring the Cookie of QQ.com by default, but will not bring the Cookie of Baidu.com
    • When requesting resources under v.qq.com, the browser will not only bring the v.qq.com Cookie, but also the qq.com Cookie
    • In addition, cookies can also be restricted according to the path, please know for yourself, this function is less used.

With cookies, we can do two things:

  1. The first function is to identify the user. For example, if user A visits Demo.com with A browser, the demo.com server will immediately return A piece of data “UID =1” (this is A Cookie). When A visits another page of Demo.com, it will attach the data “uid=1”. So the server knows who A is.

  2. The second function is to record history. For example, if Demo.com is A shopping website, when A adds commodities B1 and B2 to the shopping cart, JS can rewrite the Cookie to “uid=1; cart=B1,B2”, indicating that there are two commodities B1 and B2 in the shopping cart. This way, when the user closes the page and opens the page three days later, B1 and B2 will still be lying in the cart, because the browser will not delete the Cookie for no reason.

(Note that the above example is only conceived to give you an idea of what cookies can do, and that actual web sites would be more cautious about using cookies. Find out below why you should be very careful with cookies.)

So how do we set cookies:

Set set-cookie in the response header. For details, see set-cookie MDN. Specific parameters are as follows:

  • Set-Cookie: <cookie-name>=<cookie-value>

    Normal cookie, all parameters default

  • Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>

    The maximum validity period of the cookie is in the format of a timestamp that complies with the HTTP-date specification.

  • Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>

    The number of seconds that need to pass before the cookie expires. One or more non-zero (1-9) numbers. If both Expires and max-age are present, then max-age takes precedence.

  • Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>

    Specifies the host name to which cookies can be delivered. If not specified, the default is the host part of the current document access address (but not the subdomain). Unlike the previous specification, the dot before the domain name is ignored. If a domain name is specified, then each subdomain name is also included.

  • Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>

    Specifies a URL path that must appear in the path of the requested resource to send the Cookie header.

  • Set-Cookie: <cookie-name>=<cookie-value>; Secure

    A cookie with a security attribute is sent to the server only when the request uses SSL and HTTPS. (Note: Insecure sites (HTTP:) can no longer set secure directives in cookies)

  • Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

    Cookies with the HttpOnly attribute set cannot be accessed using JavaScript via the Document.cookie attribute, XMLHttpRequest, and RequestAPIs to protect against cross-site scripting attacks (XSS).

  • Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict

  • Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax

    The above two allow the server to set a cookie not to be sent along with a cross-domain request, thus providing some protection against cross-site request forgery attacks (CSRF).

How to Delete cookies

You can delete cookies by setting them to expire before the current time

 var delete_cookie = function(name) {
     document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:01 GMT; ';
 };
Copy the code

The HttpOnly attribute of the cookie

To avoid cross-domain scripting (XSS) attacks, cookies with HttpOnly tags cannot be accessed through JavaScript’s Document.cookie API; they should only be sent to the server. If the Cookie that contains the server Session information does not want to be called by the client JavaScript script, then the HttpOnly flag should be set for it.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Copy the code

2. Use session to save information

Let me give you an example of how to use a session, okay

Previously: put data directly into cookie:

response.setHeader('Set-Cookie'.`login_email=${email}`)
Copy the code

Writing in this way will expose the user’s personal information. Secondly, users can directly modify the cookie through the browser, and it is very likely to obtain other people’s user information, which is extremely insecure. Hence the following operations that use sessions:

let sessions = {}
let sessionId = Math.random() * 10000 // Set the sessionId to a random number
sessions[sessionId] = {login_email:email} // Store the email in the sessions object
response.setHeader('Set-Cookie'.`sessionId = ${sessionId}`) 
// Cookie stores the sessionId as a random number
Copy the code

First of all, let’s explain the above code: that is, the value stored in the cookie is set as a random number. When the background obtains the cookie, it can obtain the random number and search the value of the random number in the sessions object to know the user’s email address. As shown, the response header looks like this:

How to define a session:

First we need to understand the nature of a session: it is a hash table stored on the server.

  1. Send the sessionID (random number) to the client by Cookie
  2. When the client accesses the server, the server reads the sessionID
  3. The server has a ** memory (hash table) ** that holds all sessions
  4. The user’s privacy information, such as ID and email, can be obtained through the sessionID background
  5. This memory (hash table) is all the sessions on the server

Does session have no disadvantages over cookies?

Obviously, the answer is no. The biggest drawback of sessions is that they take up memory. If you have a lot of users, the server needs enough capacity to store data.

Whether or not a session can be implemented based on cookies

The answer is yes, you can set the url query parameter + localStorage to achieve the purpose. The specific process is as follows:

  1. After the user logs in, the back end sets his or her sessionID, but instead of putting it in a cookie, passes the information to the front end via the response body JSON.
  2. The front end takes the JSON in the response body and converts it into an object (JSON.parse)
  3. JSON data (such as sessionID) in localStorage (localStorage data is not currently available)
  4. Put the sessionID in the URL query parameter (e.g.window.location.href = '/? sessionId=object.sessionId')
  5. So when you enter the home page, the URL query parameters of the page with your sessionID
  6. When the user visits the home page, the backend obtains query parameters through the URL transmitted to the server, so as to obtain the user’s sessionID, and then finds the information corresponding to the sessionID in the database to know who the user is.

3, what is localStorage & localStorage how to use

LocalStorage is an API provided by HTML5 technology, which is a method under the Window object (window.localstorage).

The essence of localStorage is a hash table stored locally on the computer.

Common API of localStorage

  • localStorage.setItem('myCat', 'Tom')

    By using storage.setitem () as the Storage interface, accepting a key name and value as parameters, the key name will be added to the Storage, if the key name already exists, the corresponding value will be updated.

  • Let cat = localstorage.getitem (‘myCat’) This syntax is used to read localStorage entries

  • Localstorage.removeitem (‘myCat’) This syntax is used to remove the localStorage item

  • Localstorage.clear () This syntax is used to remove all localStorage entries

  • Note that localStorage can only store string, so if you want to store Object, you need to use JSON to store, for example:

Localstorage.setitem (‘jsonObj’, json.stringify ({name:’obj’}))) then use json.parse () if you want to parse the JSON and convert it to an object

How to use localStorage

The first thing we need to know is that variables in JS have this problem: variables are only valid for the current session. As soon as the page is refreshed, previously stored variables are reclaimed. So how do we make previously stored variables exist after refreshing the page, so we have localStorage to solve this need.

A small demo uses localStorage to do persistent storage of variables, because localStorage is actually stored on the local computer and does not cause variables to be recycled because of page refreshes.

let a = localStorage.getItem('a')
if(! a){ a =0
}esle{
 a = parseInt(a,10) + 1 // If not converted, it will become the addition of strings
}
console.log(a)
localStorage.setItem('a',a)
// Each time the page is refreshed, the value of a increases by 1
Copy the code

Common usage scenario: when the user enters the page for the first time, the user will be prompted with some information. After entering the page for the second time, the user will not be prompted. Example code is as follows:

let already = localStorage.getItem('isPrompt')
if(! already){ alert('Our page has changed.')
  localStorage.setItem('isPrompt'.true)
}esle{
   // Do nothing when already prompted
}
Copy the code

The characteristics of localStorage

  1. LocalStorage is independent of HTTP
  2. HTTP does not carry a value for localStorage
  3. Only pages with the same domain name can read localStorage from each other (following the same origin policy)
  4. The maximum storage capacity of each domain name localStorage is about 5Mb (different for each browser)
  5. Common scenarios: Record whether the user is prompted (record some insensitive information)
  6. LocalStorage is theoretically permanent and cannot be set to expire unless the user clears the cache

SessionStorage localStorage sessionStorage localStorage

  • Feature 1 to 4 of the localStorage of the previous record.
  • SessionStorage expires after the user closes the page (i.e. after the session ends or the session ends), and there is no way to control it. LocalStorage is theoretically permanent.
  • SessionStorage has exactly the same API as localStorage. Such assetItem(),getItem(),remove(),clear()

4. Things to note about the above concepts

What is the relationship between cookies and sessions?

A: Cookies are generally implemented based on sessions. Cookies are stored locally on the client, while sessions are stored on the server.

What is the difference between cookie and localStorage

A: Cookies are brought to the server each time a request is made, but localStorage is not. The maximum storage capacity of cookie is usually only 4K, while localStorage is generally 5Mb; The validity period of cookies generally expires after the user closes the page, while localStorage is theoretically valid forever.

You may ask, it seems that cookies and localStorage are almost unrelated, why are they compared together?

This is for historical reasons: localStorage is a new API, and how did the previous front-end implement persistent storage of data across pages before it came along? You can only use cookies, you know cookies and localStorage are stored locally on the computer, so a lot of programmers put data in cookies, but there’s a problem, everything you put in cookies, every time you request it, it goes to the server, If there are too many things in the cookie, each request will take more time. Therefore, to achieve persistent storage of data across pages, the optimal solution is to use localStorage.

The front end should never read or write cookies. Reading and writing cookies is what the back end needs to do. (Before and after refers to code separation, not people separation)

HTTP Cache & cache-control

It’s worth mentioning that cache control is also part of front-end performance optimization, so it’s worth paying attention to.

The use scenario of cache control: some websites need to load a lot of resources, resulting in the speed of every page refresh is very slow, so how to speed up the request, cache control arises at the historic moment.

The cache-control generic header is used to implement caching mechanisms by specifying directives in HTTP requests and responses. Cache directives are one-way, which means that the directives set in the request do not necessarily contain the same directives in the response.

The most common response instructions:Cache-Control: max-age=<seconds> ：

  • Sets the maximum period for which the cache is stored, after which the cache is considered expired in seconds. In contrast to Expires, time is the time relative to the request. The same URL request will not be sent to the server for a set amount of time, the browser will block the request (that is, the request was not actually sent), and then display the cached data (stored locally on hard disk or memory). In real development, we typically set it to 31536,000 or more seconds a year.
  • One caveat: In general, home pages (and even all HTML pages) should not be cached. (Chrome even disables this setting directly, meaning that cache-Control won’t work on your home page.) If you cache your home page, the user will not send any requests to the server even if the page is refreshed. If your code is updated, the user will never be able to get the latest version during the cache.
  • Use in actual development: CACHE-control is not set for HTML pages, and cache-control is set for other resources for more than one year. If the code is updated (such as JS or CSS), the query parameters of the URL of the resource request are added with a version number, or random number is added after the file name. That is, as long as the URL of your request is slightly different, caching will not be used

What is Expires & What’s wrong with it

Expires is also used to Control caching, but cache-control is now preferred in development. The Expires response header contains the date/time after which the cache Expires.

How to use Expires: Set the response header, such as: Expires: “Wed, 22 Aug 2018 07:43:17 GMT” followed by Greenwich Mean time. The cache expires when the set time expires.

So the difference between Expires and cache-control is that the former sets an expiration date and the latter sets an expiration date.

Note that the Expires header is ignored if the “max-age” or “s-max-age” directives are set in the cache-control response header. So why does cache-control take precedence over Expire?

Because cache-control is a newer technique than Expires, using Expires is buggy.

Expires bug: Time uses the computer’s local time. If the computer’s time is out of whack one day and the local time is always past your set time, it will never be able to use the cache.

What is ETag & what is MD5

First, Etag is used to give a file a version number.

So let’s look at MD5 first. MD5 is a message digest algorithm. Common use of MD5: you download a large file from the Internet. How do you know if you downloaded it correctly? So MD5 was made for this kind of situation. That is, a file on the Internet will have an MD5 value in addition to the resource itself. Then you can calculate an MD5 value for the downloaded file and compare the two. If they are identical, the following file is correct.

Etag usage scenarios:

  1. The back end calculates the MD5 value of the resource and sets it to the Etag of the response header, as shown in the following example:Etag: 33 a64df551425fcc55e4d42a148795d9f25f89d4 ""
  2. Then the next time the resource is requested, the request header is added with a value:If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
  3. The backend has the following Settings: if the request headerIf-None-MatchIs the same as the MD5 of the resource, indicating that the resource is up to date and can be returned without downloadingA status code of 304(Not Modified), then the response body is Not set under this branch.
  4. If the MD5 value is different, it indicates that your resource needs to be updated. In this case, the latest resource is returned as the response body.

Etag differs from cache-control:

  • Cache-control does not send requests directly, as long as the URL is used directly
  • Etag is requested every time, but if the resource has the same MD5, it is not downloaded

8. What is Last-Modified and how is it used

Last-modified is a response header that contains the date and time when the resource identified by the source server was Modified. It is often used as a validator to determine whether received or stored resources are consistent with each other. This is a backup mechanism because it is less accurate than ETag. This field is used for conditional requests that contain an if-modified-since or if-unmodified-since header.

Use process:

  1. When the browser requests a URL for the first time, the server returns a status of 200, indicating the resource you requested, with a last-Modified attribute in the response header, and the Last time the file was Modified at the server end in something like this:Last-Modified:Tue, 24 Feb 2009 08:01:04 GMT
  2. When the client requests this URL a second time, the browser sends an if-modified-since request header to the server, asking If the file has been Modified Since then:If-Modified-Since:Tue, 24 Feb 2009 08:01:04 GMT
  3. If the resources on the server do not change, the HTTP 304 (NotChanged.) status code is automatically returned with nothing, thus saving the amount of data transferred. When server-side code changes or the server is restarted, the resource is re-issued, returning similar to the first request. This ensures that resources are not repeatedly issued to the client and that the client can get the latest resources when the server changes.

(END)