This is the 9th day of my participation in Gwen Challenge

HTTP itself is a stateless protocol, but sometimes we have the need to increase the state, this time extended Cookie, Cookie can be used to keep some state information during transmission.

The use of cookies

What is a Cookie?

To be clear, cookies are designed to solve the HTTP stateless problem.

In the implementation of Cookie, when the server receives the request from the client, it adds some user identification information into the Cookie. With the response returned to the client, the client stores the information in the Cookie locally. Next time it requests the server, Then the data carried in the Cookie is transmitted to the server as is. At this time, the server can identify that it is a user previously requested by the user id in the Cookie. The definition in Netscape’s official documentation is:

Cookies are a way for a server or script to maintain information on a client’s computer over HTTP. In layman’s terms, cookies are a technology that enables a website’s Web server to store a small amount of data to the client’s hard drive or memory, or to read data from the client’s hard drive. A Cookie file is a small text file created by the Web server’s CGI script and stored on the browser client’s computer while browsing a Web site.

A complete Cookie transfer process

HTTP rules are implemented by writing input to request headers and response headers, and cookies are the same.

Through the serverSet-CookieThe response header writes Cookie information to the client, which reads itSet-CookieThe information in the response header is stored, retrieved on the next request, and passedCookieThis request header transmits the Cookie’s data to the server.Let’s look at another example of Cookie usage in a browser.

In Response headers, different Cookie data is passed using set-cookie, which can be split into multiple set-cookie headers.

In the Request Header, the Cookie Header is used to pass Cookie data. Different data is passed through. Segmentation.

The details of the Cookie

At this point, I think you’ve figured out how to execute cookies. Let’s explore cookies in some detail.

The type of Cookie

Cookies are actually stored on the client, and when we say the client of cookies, we’re talking about the browser.

For cookies, we can simply divide cookies into two types: session cookies and persistent cookies

A session cookie

Session cookie is a temporary cookie used to store some temporary information and stored in memory. Session cookie will be cleared and deleted when the user exits the browser. Persistent cookies, on the other hand, have a longer life cycle and are stored on disk. They still exist after the browser restarts, but they have an expiration date and are only set to expire after that date.

Persistent cookies

The only difference between session cookies and persistent cookies is their expiration time. A cookie with an expiration time is a persistent cookie, while a cookie with an expiration time is a session cookie.

If you look closely at the previous flow chart, there is a domain field that identifies the domain name currently supported by cookies. To set the expiration time, you can use the Expires or max-age parameter, similar to the HTTP cache parameter we talked about earlier.

Cookie configuration parameters

So far we have introduced information for two Cookie configurations, Domain and Expires/ max-age, which are used to configure the Domain name and Expires policy, respectively.

All of this makes sense, because browsers are open, they visit many different sites, and it’s almost impossible to pass all cookies on every request. These configuration parameters add some additional Settings to the Cookie, perform some simple restrictions and filters, reduce the amount of transmission and ensure security.

The Domain parameter restricts the Cookie to only requests under this Domain name.

In fact, Cookie also supports some other parameters. If you open the Debug mode of Chrome, you can see the Cookie information of the current page in the Application.

The following takes the Cookie stored on the page of a wechat article as an example.

This table contains all the Cookie information currently stored, and the header is the Cookie information supported by Chrome.

Let’s look at each of them.

  • The Name:Value: Cookie stores the data as a key-value pair, so there is no dispute between the two parameters, namely the Key and Value of the data.
  • Domain: the Domain of the Cookie, limiting the transmission of request headers.
  • Path: Path prefix associated with cookies in the domain.
  • Expires/ max-age: indicates the expiration time or timeout interval.
  • HTTP: This property is True, which means that the Cookie information is carried only in the HTTP request header and cannot be accessed through document. Cookie.
  • Secure: Security, whether this Cookie is sent only when an SSL connection is used.

The Set – Cookie2 and Cookie2

Some references to set-Cookie2 and Cookie2 are legacy issues that were originally intended to extend Cookie functionality, but were not widely implemented and are now deprecated.

If you are interested, please refer to RFC 6265.

Browser restrictions on cookies

Most of the time when we talk about cookies we’re talking about server and browser communication, and different browsers have different restrictions on Cookie storage. For example, the number and size of cookies that can be stored by a single domain name.During page Cookie operations, the number of cookies should be less than 20 and the total size should be less than 4KB, which is a safe and safe range.

Cookie’s check to fill in the gaps

Cookies are safe

When we configured the Cookie parameter, we had two parameters: HTTP and the Secure attribute, which provided some degree of security.

HTTP properties

If the HTTP attribute is set to indicate that it is an “HttpOnly”, then some scripts (such as JS document.cookie) will not be able to read this cookie information, it will only appear in the request header.

Secure properties

The secure property forces the Cookie to be transmitted to the server only in an SSL environment, ensuring the security of transmission.

Cookies are not supported across domains

Cookie itself does not support cross-domain, which also ensures Cookie security to a certain extent. If cross-domain is necessary, there is basically little that can be done as the front end, most of which require the secondary cooperation of the server.

For example: Nginx reverse proxy, Jsonp, NodeJS superagent, iframe and other methods.

conclusion

Cookie in HTTP, basically all explained clearly, let’s summarize the key points again.

  • Cookies are mainly to solve the problem of HTTP stateless protocol.
  • The server sets the Cookie to the client through the set-cookie response header.
  • The client sends the previously stored Cookie data to the server through the Cookie request header.
  • Cookies are divided into temporary cookies and persistent cookies according to expiration time.
  • Cookies can be restricted by setting different parameters, such as expiration time, supported domain names, and whether they are secure.
  • Cookies are not supported across domains, and cross-domains require other ways to bypass them.
  • Cookies can only be relatively safe, nothing is absolutely safe.

The above! Last rule, post my blog, welcome to follow

Please pay attention to the official number: Full stack flying Squadron