Shulou(Shulou.com)06/02 Report--

This article mainly explains "take you to know HTTP cool techs". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and study "take you to understand HTTP cool techs".

HTTP content negotiation

What is content negotiation?

In HTTP, content negotiation is a mechanism for providing different representations of resources on the same URL. The content negotiation mechanism means that the client and the server negotiate the resource content of the response, and then provide the most suitable resource to the client. The content consultation is based on the language, character set, encoding and so on of the response resource.

Types of content negotiation

There are three main types of content negotiation:

Server driven negotiation (Server-driven Negotiation)

In this way, the content is negotiated by the server. The server will automatically process the request according to the header field.

Client-driven negotiation (Agent-driven Negotiation)

In this way, the client negotiates the content.

Transparent negotiation (Transparent Negotiation)

It is a combination of server-driven and client-driven, and it is a method of content negotiation between server and client.

There are many categories of content negotiation, and the main types are Accept, Accept-Charset, Accept-Encoding, Accept-Language, and Content-Language.

Generally speaking, the client uses the Accept header to tell the server what kind of data it wants to receive, while the server uses the Content header to tell the client what kind of data is actually sent.

Why content negotiation is needed

Why do we need content negotiation? Before answering this question, let's take a look at the difference between TCP and HTTP.

In the TCP / IP protocol stack, the transmitted data is basically in header+body format. However, because TCP and UDP are transport layer protocols, they do not care what the body data is, as long as the data is sent to each other to complete the task.

Unlike the HTTP protocol, it is an application layer protocol, and when the data arrives, you need to tell the application what the data is. Of course, without telling the application what type of data it is, the application can tell by constantly trying, but this approach is undoubtedly inefficient and there is a good chance that the file type will not be detected.

So in view of this, the browser and the server need to agree on the data transmission, and the browser needs to tell the server what kind of data they want to receive, what kind of compression format, what language, which character set, etc.; and the server needs to tell the client what kind of service it can provide.

So we introduce several concepts of content negotiation, which will be discussed in turn.

Content negotiation header

Accept

The accept request HTTP header advertises the MIME types that the client can accept.

So what is the MIME type? You should know what MIME is before you answer this question.

MIME: MIME (Multipurpose Internet Mail Extensions) is an Internet standard that describes the type of message content. MIME messages can contain text, images, audio, video, and other application-specific data.

In other words, a MIME type is actually a collection of message content types. So what are the types of MIME?

Text files: text/html, text/plain, text/css, application/xhtml+xml, application/xml

Picture files: image/jpeg, image/gif, image/png

Video files: video/mpeg, video/quicktime

Application binaries: application/octet-stream, application/zip

For example, if the browser does not support the display of PNG images, then Accept does not specify image/png, but specifies image types such as image/gif and image/jpeg that can be processed.

The general MIME type is also used with the attribute Q. What is Q? Q represents weight. Let's take a look at an example.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

What does this mean? If you want to increase the priority of the media type displayed, use Q = to represent the extra weight value. When the weight is not displayed, the default value is 1.0. I will give you a table and you will understand.

QMIME1.0text/html1.0application/xhtml+xml0.9application/xml0.8/

In other words, this is a placement order, the weight is high in the front, low in the back, the application/xml;q=0.9 is an indivisible whole.

Accept-Charset

The Accept-charset attribute specifies the character encoding accepted by the server to process the form data; the Accept-charset attribute allows you to specify a series of character sets that the server must support to correctly interpret the data in the form.

Accept-Charset does not have a corresponding header. The server will put this value in Content-Type and use charset=xxx to represent it.

For example, the browser requests the character set of GBK or UTF-8, and the server returns the UTF-8 encoding, as follows

Accept-Charset: gbk, utf-8 Content-Type: text/html; charset=utf-8

Accept-Language

The first field, Accept-Language, is used to inform the server about the natural language set (Chinese or English, etc.) that the user agent can handle, as well as the relative priority of the natural language set. Multiple natural language sets can be specified at one time. As with the Accept header field, the relative priority is represented by the weight value Q =.

Accept-Language: en-US,en;q=0.5

Accept-Encoding

The HTTP header indicates the encoding of the content that the client wants the server to return, which is usually a compression algorithm. Accept-Encoding is also part of content negotiation, using and selecting Content-Encoding content through the client to return.

Even if both the client and the server can support the same compression algorithm, the server may choose not to compress and return, which may be due to both situations:

The data to be sent has already been compressed once, and the second compression will not cause the data to be sent smaller.

The server is overloaded and cannot bear the performance overhead caused by compression. In general, if the server uses more than 80% CPU, Microsoft does not recommend using compression.

Here is how to use Accept-Encoding

Accept-Encoding: gzip Accept-Encoding: compress Accept-Encoding: deflate Accept-Encoding: br Accept-Encoding: identity Accept-Encoding: * Accept-Encoding: deflate, gzip;q=1.0, *; qroom0.5

The above expressions have listed all the attributes of Accept-Encoding.

Gzip: the encoding format generated by the file compression program gzip, using Lempel-Ziv encoding (LZ77) and 32-bit CRC compression format, which can be read by interested students (https://en.wikipedia.org/wiki...)

Compress: use the compressed format of Lempel-Ziv-Welch (LZW) algorithm, which can be read by interested students (https://en.wikipedia.org/wiki...)

Deflate: compression format using zlib structure and deflate compression algorithm, refer to (https://en.wikipedia.org/wiki...) and (https://en.wikipedia.org/wiki...)

Br: compression format using the Brotli algorithm, refer to (https://en.wikipedia.org/wiki...)

Default encoding format that does not perform compression or does not change

*: match any content encoding that is not listed in the header. If Accept-Encoding is not listed, this is the default value, which does not mean the number of entries.

Holding any algorithm only means that there is no preference.

; Q = uses the weight Q value to indicate the relative priority, which is the same as the header field Accept.

Content-Type

The Content-Type entity header is used to indicate the MIME type of the resource. In response, the Content-Type header tells the client what the content type of the returned content is actually. Content-type has two values: MIME type and character set encoding, such as

Content-Type: text/html; charset=UTF-8

In some cases, browsers will perform MIME sniffing and may not necessarily follow the value of this header; to prevent this behavior, you can set the header X-Content-Type-Options to nosniff.

Content-Encoding

The Content-Encoding entity header is used to compress the media type, which lets the client know how to decode, thus allowing the client to obtain the MIME type referenced by the Content-Type header. It is expressed as follows

Content-Encoding: gzip Content-Encoding: compress Content-Encoding: deflate Content-Encoding: identity Content-Encoding: br Content-Encoding: gzip, identity Content-Encoding: deflate, gzip

Content-Language

Content-Language entity headers are used to describe audience-oriented languages so that users can distinguish according to their own preferred language. For example

Content-Language: de-DE Content-Language: en-US Content-Language: de-DE, en-CA

Below, according to the request / response headers corresponding to the content negotiation, I have listed a picture for your reference. Note that Accept-Charset does not have a corresponding Content-Charset, but is represented by Content-Type.

HTTP certification

HTTP provides functions for access control and authentication. Here is an introduction to the permissions and authentication functions of HTTP.

General HTTP authentication framework

RFC 7235 defines the HTTP authentication framework, and the server can check client requests against the definition of its document. Clients can also provide authentication information based on their document definitions.

The workflow of the request / response is as follows: the server responds to the client with a state of 401 (unauthorized) that the client server needs authentication information, and the client provides at least one www-Authenticate response header to authenticate the authorization information. Clients who want to authenticate through the server can add an authentication header to the request header field to authenticate. The general authentication process is as follows

First of all, the client initiates a HTTP request without any authentication headers, and the server responds to the HTTP request and finds that the HTTP information does not have authentication credentials. The server returns 401through the www-Authenticate header to tell the client that the request has not been authenticated. Then the client authenticates the user, and re-initiates the HTTP request after the authentication is completed. This HTTP request has user authentication credentials (note that the entire authentication process must be secured through a HTTPS connection). After arriving at the server, the server will check the authentication information. If it does not meet the server authentication information, it will return 403 Forbidden to indicate that the user authentication failed. If the authentication information is satisfied, 200 OK will be returned.

We know that the HTTP connection between the client and the server can be resent by the proxy cache, so the authentication information also applies to the proxy server.

Agent authentication

Since resource authentication and agent authentication can coexist, different headers and status codes are required. In the case of an agent, the status code 407 is returned (agent authentication is required), the Proxy-Authenticate response header contains at least one case applicable to the agent, and the Proxy-Authorization request header is used to provide the certificate to the proxy server. Let's take a look at these two headers respectively.

Proxy-Authenticate

The HTTP Proxy-Authenticate response header defines an authentication method that should be used to access resources behind the proxy server. It authenticates the request to the proxy server, allowing it to send further requests. For example

Proxy-Authenticate: Basic Proxy-Authenticate: Basic realm= "Access to the internal site"

Proxy-Authorization

This HTTP request header is similar to the above Proxy-Authenticate splicing, but the concept is different. This header is used to provide credentials to the proxy server, such as

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

The following is the request / response authentication process for the proxy server

This process is similar to the general process, so we will not describe it in detail.

Access prohibited

If the proxy server receives insufficient valid credentials to gain access to a given resource, the server should respond with a 403 Forbidden status code. Unlike 401 Unauthorized and 407 Proxy Authorization Required, this user cannot authenticate.

WWW-Authenticate and Proxy-Authenticate headers

The WWW-Authenticate and Proxy-Authenticate response headers define authentication methods to gain access to resources. They need to specify which authentication scheme to use so that clients who want authorization know how to provide credentials. Their general expressions are as follows

WWW-Authenticate: realm= Proxy-Authenticate: realm=

I think you will wonder what realm is when you see it from above. Let's explain it now.

Is an authentication protocol, and Basic is the most commonly used of the following protocols

The Basic HTT P authentication scheme is defined in RFC 7617, which transmits credentials as user ID / password pairs and encodes them using base64. (interested students can take a look at https://tools.ietf.org/html/r...

Other authentication protocols mainly include

Authentication protocol reference source Basic looks up RFC 7617Magne Base64-encoded credentials Bearer looks up RFC 6750, carries tokens to access resources protected by OAuth 2.0.Digest looks up RFC 7616 Firefox only supports md5 hash, see error bug 472823 to get SHA encryption support HOBA check RFC 7486Mutual check RFC 8120AWS4-HMAC-SHA256 check AWS docs

AWS4-HMAC-SHA256 check AWS docs

Realm is used to describe a protected area or to indicate the scope of protection, which may be such as Access to the staging site (access to the landing site) or the like, so that users can know which area they want to visit.

Authorization and Proxy-Authorization headers

The Authorization and Proxy-Authorization request headers contain the credentials used to authenticate the user agent through the proxy server. Here, the type is required again, followed by credentials, which can be encoded or encrypted, depending on which authentication scheme is used. It is generally expressed as follows

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

HTTP caching

By caching requests / responses to help improve system performance, Web caching reduces latency and network traffic, thus reducing the time it takes for resources to acquire locks. Because the link is long and the network delay is uncontrollable, it is expensive for browsers to use HTTP to obtain resources. Therefore, it is very necessary to cache the data and reuse it as much as possible the next time it is requested. When the Web cache has a requested resource in its storage, it intercepts the request and returns the resource directly, rather than going to the source server to download and retrieve it again. By doing so, two small goals can be achieved.

Lighten the server load

Improve system performance

Let's talk about what HTTP caches have.

Different types of caches

There are several different types of HTTP caches, which can be divided into two main categories: private caches and shared caches.

Shared cache: a shared cache is a cache that stores requests / responses that are reused by multiple users.

Private cache: private cache, also known as private cache, is only applicable to a single user.

Do not cache expired resources: all requests go directly to the server, which downloads the resources and returns.

We mainly discuss browser caching and proxy caching, but the real situation is not only these two caches, but also gateway caching, CDN, reverse proxy caching and load balancer. Deploying them on Web servers can improve the reliability, performance and scalability of websites and Web applications.

Do not cache expired resources

Do not cache expired resources, that is, browsers and proxies do not cache expired resources. Requests initiated by the client will go directly to the server. You can use no-cache headers to represent that expired resources are not cached.

No-cache belongs to the Cache-Control universal header, and its general representation is as follows

Cache-Control: no-cache

You can also use max-age = 0 to achieve the effect of not caching.

Cache-Control: max-age=0

Private cache

The private cache is only used to cache a single user, and you may see the cache in the browser settings, which contains all documents downloaded by the server through HTTP. This cache is used to enable accessed documents to move forward / backward and save operations without resending requests to the source server.

You can use private to implement private caching, which is contrary to the use of public, where the cache server caches only specific clients, and the cache server does not return caches for requests sent by other clients. Its general representation is as follows

Cache-Control: private

Shared cache

A shared cache is used to store a response cache to be reused by multiple users. The shared cache is generally represented by public, and the public attribute appears only in the client response, indicating that the response can be cached by any cache. The general representation is as follows

Cache-Control: public

Cache control

The Cache-Control general header field in HTTP/1.1 is used to perform cache control, which allows you to define the cache policy through the various instructions it provides. Let's introduce these attributes in turn.

Do not cach

No-store is the real sense of non-caching, each time the server receives a request from the client, it will return the latest resources to the client.

Cache-Control: no-store

Cached but requires verification

Do not cache expired resources as above

Private and shared cach

Same as above

Cache expiration

A very important instruction in the cache is max-age, which is the longest time a resource is considered fresh, as opposed to Expires, which is relative to the request time. For files that will not change in the application, you can usually add an active cache. Here is a representation of mag-age

Cache-Control: max-age=31536000

Cache verification

Must-revalidate indicates that the cache must verify the status of outdated resources before using them, and that expired resources should not be used.

Cache-Control: must-revalidate

The following is a cache verification diagram

What is fresh data?

Once the resource is stored in the cache, it can theoretically be used by the cache forever. However, the storage space of either browser cache or proxy cache is limited, so the cache is cleared periodically, a process called cache cache eviction. On the other hand, the cache on the server is also updated periodically. HTTP, as an application layer protocol, is a client-server model, and HTTP is a stateless protocol, so when resources change, the server cannot notify the cache and the client. So the server must somehow inform the client that the cache has been updated. The server provides the concept of expiration time, informing the client that before this expiration time, the resource is fresh, that is, unchanged. Outside the scope of this expiration time, the resource is out of date. The expiration algorithm (Eviction algorithms) usually prioritizes the use of new resources over old ones.

Note here that expired resources are not reclaimed or ignored, and when the cache receives expired resources, it forwards the request using If-None-Match to check that it is still valid. If valid, the server returns a 304 Not Modified response header without any response body, saving some bandwidth.

The following is the process of using a shared cache proxy

This diagram should be easy to understand, just to talk about the role of Age. Age is a HTTP response header that tells the client how long ago the source server created the response. Its unit is seconds. The Age header is usually close to 0. If it is 0, it may be obtained from the source server. If it does not indicate that it may be created by the proxy server, then the value of Age represents the time that the cached response re-initiates authentication until the authentication is completed.

The effectiveness of the cache is determined by multiple headers, not by a single header. If Cache-control:max-age=N is specified, the cache will be saved for N seconds. If this generic header does not exist, it is checked for the existence of the Expires header. If the Exprires header exists, its value minus the value of the Date header determines its validity. Finally, if neither max-age nor expires exists, look for the Last-Modified header, and if this header exists, the validity of the cache is equal to the value of the Date header minus the value of the Last-modified header divided by 10.

Cache verification

When the validity period of the cache resource is reached, it will be validated or retrieved again. Validation can be performed only if the server provides a strong or weak validator.

Reauthentication is triggered when the user presses the reload button. If the cached response contains a Cache-control:must-revalidate header, the event is also triggered under normal browsing. Another factor is the cache validation preference in the Advanced-> Cache preferences panel. There is an option to force validation each time the document is loaded.

Etag

We mentioned strong validator and weak validator above, which implements the function of formal Etag in the header of validator function, which means that HTTP user agents (such as browsers) do not know what the string represents and cannot predict its value. If the Etag header is part of the resource response, the client can issue an If-None-Match in the header of a future request to validate the cached resource.

The Last-Modified response header can be used as a weak validator because it has only 1 second resolution time. If the Last-Modified header is present in the response, the client can issue an If-Modified-Since request header to validate the cache resource. (we will introduce more about Etag in the conditional request.)

Avoid collision

By using Etag and If-Match headers, you can detect and avoid collisions.

For example, when editing a MDN, the current Wiki content is hashed and placed in the Etag in the response

Etag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

When the changes are saved to the Wiki page (publishing data), the POST request contains the If-Match header, which contains the Etag value to check for validity.

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

If the hash values do not match, the document has been edited in the middle and a 412 Precondition Failed error is returned.

Cache unoccupied resources

Another typical use of Etag headers is to cache unchanged resources. If a user accesses a given URL (Etag is set) again and the URL is out of date, the client will send the value of its Etag in the If-None-Match header field.

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

The server compares the client's Etag (sent through If-None-Match) with Etag to get its current resource version, and if both values match (that is, the resource has not changed), the server will send back a 304Not Modified state without a principal, which tells the client that the response cache is still available.

HTTP CROS cross-domain

The full name of CROS is Cross-Origin Resource Sharing (CROS), which is translated into Chinese for cross-domain resource sharing. It is a mechanism. What kind of mechanism is it? It is a mechanism that allows Web applications running on an origin to access specified resources from different source servers. Before you can understand this mechanism, you need to know what an origin is.

Origin

The content of Origin in Web concept is defined by scheme (protocol)-protocol, host (domain)-host and URL port-port used to access it. The two objects have the same source only if scheme, host, and port all match. The security policy with the same protocol, the same domain name and the same port is also called the same origin policy (Same Origin Policy). Some actions are limited to content with the same source, and you can use CORS to remove this restriction.

Cross-domain characteristics

Here is an example of a cross-domain problem to see if you know what cross-domain is.

(1) http://example.com/app1/index.html (2) http://example.com/app2/index.html

Do the above two URL have cross-domain problems?

The above two URL do not have cross-domain problems, because the two URL have the same protocol (scheme) and host (host).

So do the following two have cross-domain problems?

Http://Example.com:80 http://example.com

These two URL also do not have cross-domain problem, why not have, the port is different. In fact, their two ports are the same.

Maybe you will think that these two URL are different. Don't worry, I have thrown out the argument about whether they are the same or not.

The protocol and domain name parts are case-insensitive, but the path part depends on the server platform. Windows and Mac OS X systems are case-insensitive, while server systems using UNIX and Linux systems are case-sensitive

In other words, the Example.com and example.com above are actually the same URL, and because the two addresses have the same scheme and host, the server passes HTTP content through port 80 by default, so the two addresses are the same.

Do the following two URL addresses have cross-domain problems?

Http://example.com/app1 https://example.com/app2

The scheme of the two URL is different, so the two URL have cross-domain problems.

Let's see if the following three URL have cross-domain problems.

Http://example.com http://www.example.com http://myapp.example.com

These three URL also have cross-domain problems because they belong to the host host that cannot reach the server.

Whether the following two URL have cross-domain problems

Http://example.com http://example.com:8080

These two URL also have cross-domain problems because the default ports of the two URL are different.

Homologous strategy

For security reasons, browsers restrict cross-domain HTTP requests from scripts. XMLHttpRequest and other Fetch interfaces follow the same origin policy (same-origin policy). That is, applications that use these API want to request the same resources, so they should have the same source, unless responses from other sources include the correct CORS headers.

The same origin policy is an important security policy that limits how documents or scripts loaded from one source interact with resources from another source. It helps to isolate potentially malicious documents and reduce possible attack vectors.

As we mentioned above, if two URL have the same protocol, host, and port number (if specified), then both URL have the same source. Here are some examples of whether you have the same source or not.

Destination source http://store.company.com/dir/page.html

URLOutcomeReason http://store.company.com/dir2... Only path with different http://store.company.com/dir/... from the same source Only path with different https://store.company.com/pag... from the same source Different source protocols do not work with http://store.company.com:81/dir/page.html, different source default ports, different http://news.company.com/dir/p.... Hosts from different sources are different.

Now that I've introduced you to different sources twice, you should know how to tell whether two URL belong to the same source.

Well, now that you know what a cross-domain problem is, I'm going to ask you, which requests will result in cross-domain requests? This is what we are going to discuss next.

Cross-domain request

Cross-domain requests may be made from the following requests:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Call XMLHttpRequest or Fetch api.

What is XMLHttpRequest? (I am a back-end programmer, the front-end does not quite understand, simply explain, if the explanation is not good, ask the front-end bosses not to beat me.)

All modern browsers have a built-in XMLHttpReqeust object that can be used to request data from the server.

XMLHttpReqeust is important to developers, and XMLHttpReqeust objects can be used to do the following

There is no need to refresh the page to update the page

Request data from the server after the page is loaded

Get data from the server after the page is loaded

Send data to the server in the background

Using the XMLHttpRequest (XHR) object to interact with the server, you can retrieve data from URL without having to refresh the entire page, which allows the page to update part of the page without interrupting the user's operations. XMLHttpRequest is widely used in AJAX asynchronous programming.

Back to what Fetch API is, Fetch provides a general definition of request and response objects (and other network requests). It also provides definitions of related concepts, such as CORS and HTTP Origin header semantics, and replaces their respective definitions elsewhere.

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Web fonts (used for cross-domain fonts in @ font-face in CSS) so that the server can deploy TrueType fonts that can only be used by Web sites that allow cross-site loading and use.

WebGL texture

Use drawImage () to draw an image / video frame on the canvas

CSS shape of the picture

Overview of cross-domain functionality

The cross-domain resource sharing standard works by adding new HTTP headers that allow the server to describe which sources are allowed to read information from Web browsers. In addition, for HTTP request methods that may cause side effects on server data (especially GET or HTTP methods other than some MIME type POST methods), the specification requires the browser to pre-check the request, use the HTTP OPTIONS request method to request the supported method from the server, and then send the actual request after the server approves it. The server can also tell the client whether credentials (such as Cookies and HTTP authentication) should be sent with the request.

Note: a CORS failure can lead to an error, but for security reasons, the details of the error do not apply to JavaScript. All the code knows that an error has occurred. The only way to determine the specific problem is to look at the browser's console for more information.

access control

Next, I will discuss with you three scenarios that demonstrate how cross-domain resource sharing works. All of these examples use XMLHttpRequest, which can make cross-site requests in any supported browser.

Simple request

Some requests do not trigger CORS prechecks (we'll talk about them later). A simple request is a request that meets all the conditions.

Allow the following methods: GET, HEAD, and POST

Except for headers that are automatically set by the user agent (such as Connection, User-Agent, or other headers defined as forbidden header names in the Fetch specification), the only headers that are allowed to be set manually are those that the Fetch specification defines as request headers listed securely by CORS, which are:

Accept

Accept-Language

Content-Language

Content-Type (described below)

DPR

Downlink

Save-Data

Viewport-Width

Width

The only allowed value for the Content-Type header is

Application/x-www-form-urlencoded

Multipart/form-data

Text/plain

Event listeners are not registered on any XMLHttpRequestUpload objects used in the request; these can be accessed using the XMLHttpRequest.upload property.

The ReadableStream object is not used in the request.

For example, suppose the web content https://foo.example wants to get the resources of the https://bar.other domain, then the code in JavaScript might write something like this

Const xhr = new XMLHttpRequest (); const url = 'https://bar.other/resources/public-data/'; xhr.open (' GET', url); xhr.onreadystatechange = someHandler; xhr.send ()

This uses CORS headers to handle privileges to perform some kind of conversion between the client and the server.

Let's look at what the browser will send to the server in this case, and let's see how the server responds:

GET / resources/public-data/ HTTP/1.1 Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.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 Connection: keep-alive Origin: https://foo.example

Notice the header Origin of the request, which indicates that the call came from https://foo.example. Let's see how the server responds.

HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 00:23:53 GMT Server: Apache/2 Access-Control-Allow-Origin: * Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/xml [… XML Data...]

The server sends Access-Control-Allow-Origin in response. The simplest access control protocol is demonstrated using Origin headers and Access-Control-Allow-Origin. In this case, the server uses Access-Control-Allow-Origin as a response, which means that the resource can be accessed by any domain.

If resource owners in https://bar.other want to restrict access to resources to requests from https://foo.example only, they should send the following response

Access-Control-Allow-Origin: https://foo.example

Currently, no domain other than https://foo.example can access https://bar.other resources in a cross-domain manner.

Pre-check request

Unlike the simple request discussed above, the pre-check request first sends an HTTP request to a resource in another domain through the OPTIONS method to determine whether the actual request can be safely sent. Cross-sites are pre-checked in this way because they may affect user data.

The following is a pre-check example

Const xhr = new XMLHttpRequest (); xhr.open ('POST',' https://bar.other/resources/post-here/'); xhr.setRequestHeader ('XMurPINGOTHER,' pingpong'); xhr.setRequestHeader ('Content-Type',' application/xml'); xhr.onreadystatechange = handler; xhr.send ('Arun')

The above example creates a XML request body to send along with the POST request. In addition, a non-standard request header X-PINGOTHER is set, which is not part of HTTP/1.1, but is usually useful for Web programs. Because the requested Content-Type uses application/xml and has a custom header set, the request is prechecked. As shown in the following figure

As described below, the actual POST request does not contain Access-Control-Request- * headers; only OPTIONS requests need them.

Let's take a look at the complete client / server interaction, starting with the pre-check request / response

OPTIONS / resources/post-here/ HTTP/1.1 Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en Qroom0.5 Accept-Encoding: gzip,deflate Connection: keep-alive Origin: http://foo.example Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-TypeHTTP/1.1 204No Content Date: Mon, 01 Dec 2008 01:15:39 GMT Server: Apache/2 Access-Control-Allow-Origin: https://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 Keep-Alive: timeout=2, max=100 Connection: Keep-Alive

The above lines 1-11 represent the pre-check request, which uses the OPYIIONS method, and the browser determines whether the request needs to be sent based on the request parameters used in the above JavaScript code snippet, so that the server can respond whether the request can be sent using the actual request parameters. OPTIONS is a HTTP / 1.1method for determining more information from the server and is a secure method, which means it cannot be used to change resources. Note that along with the OPTIONS request, two other request headers are sent (lines 9 and 10, respectively)

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

The Access-Control-Request-Method header notifies the server as part of the pre-check request, which is sent using the POST request method when the actual request is sent.

The Access-Control-Request-Headers header informs the server that when a request is sent, it will be sent along with the X-PINGOTHER and Content-Type custom headers. The server can determine whether to accept the request in this case.

The following lines 1-11 are responses from the server, indicating that the POST request and X-PINGOTHER are acceptable. Let's focus on the following lines

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

The server completes the response indicating that the source http://foo.example is an acceptable URL, allowing POST, GET, and OPTIONS to make requests, and allowing custom headers X-PINGOTHER, Content-Type. Finally, Access-Control-Max-Age gives a value in seconds that indicates how long the response to the pre-check request can be cached, during which no additional pre-check requests are sent.

After the pre-inspection request is completed, the actual request will be sent:

POST / resources/post-here/ HTTP/1.1 Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.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 Connection: keep-alive X-PINGOTHER: pingpong Content-Type: text/xml Charset=UTF-8 Referer: https://foo.example/examples/preflightInvocation.html Content-Length: 55 Origin: https://foo.example Pragma: no-cache Cache-Control: no-cache ArunHTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:15:40 GMT Server: Apache/2 Access-Control-Allow-Origin: https://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]

Many headers in the formal response have been discussed in previous articles. We will not introduce them in detail in this article. Readers can refer to

Do you still have a headache about these concepts of HTTP? Look up

Request with credential

The most interesting feature of XMLHttpRequest or Fetch and CORS is the ability to issue credential requests that know HTTP Cookie and HTTP authentication. By default, the browser does not send credentials in cross-site XMLHttpRequest or Fetch calls. You must set a specific flag when calling the XMLHttpRequest object or the Request constructor.

In the following example, the content initially loaded from http://foo.example makes a simple GET request for the resource on the http://bar.other with Cookies set. The possible code on foo.example is as follows

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

Line 7 shows the flag on XMLHttpRequest, which must be set to make calls using Cookie. By default, calls are made without using Cookie. Because this is a simple GET request, there is no pre-checking, but the browser will reject any response without Access-Control-Allow-Credentials: the header is true, which means that the response does not return the content of the web page.

The above request can be represented by the following figure

This is a sample exchange between the client and the server:

GET / resources/access-control-with-credentials/ HTTP/1.1 Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en Qroom0.5 Accept-Encoding: gzip,deflate Connection: keep-alive Referer: http://foo.example/examples/credential.html Origin: http://foo.example Cookie: pageAccess=2HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:34:52 GMT Server: Apache/2 Access-Control-Allow-Origin: https://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]

Line 10 above contains the content Cookie that points to the http://bar.other, but if the bar.other does not respond with Access-Control-Allow-Credentials:true (line 5 below), the response will be ignored and the content returned by the site cannot be used.

Request credentials and wildcards

When responding to a credential request, the server must specify a source in the Access-Control-Allow-Credentials and cannot write the * wildcard directly

Because the request header in the above sample code contains the Cookie header, the request will fail if the wildcard character * is specified in Access-Control-Allow-Credentials.

Note that the Set-Cookie response header in the above example also has another value set, and if a failure occurs, an exception will be thrown (depending on the API used).

HTTP response header

Some of the HTTP headers defined by the server cross-domain sharing specification are listed below, which are briefly summarized above. Now let's take a look at them, mainly introducing the following

Access-Control-Allow-Origin

Access-Control-Allow-Credentials

Access-Control-Allow-Headers

Access-Control-Allow-Methods

Access-Control-Expose-Headers

Access-Control-Max-Age

Access-Control-Request-Headers

Access-Control-Request-Method

Origin

Access-Control-Allow-Origin

Access-Control-Allow-Origin is the HTTP response header that indicates whether the response can share resources with a given source. Access-Control-Allow-Origin specifying a single resource tells the browser to allow the specified source to access the resource. For requests without credentials, tell the browser to allow any source to access the resource.

For example, if you want to allow code from the source https://mozilla.org to access resources, you can use the following specified method

Access-Control-Allow-Origin: https://mozilla.org Vary: Origin

If the server specifies a single source instead of the * wildcard, the server should also include that source in the Vary response header.

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials is the response header for HTTP, which tells the browser whether to expose the response to the front-end JavaScript code when a credential request (Request.credentials) is included.

At this point you will ask what is Request.credentials? Don't worry, let's show you. First of all, let's see what Request is.

In fact, Request is a class of interfaces for Fetch API that represent resource requests. Generally, there are two ways to create Request objects

Create a Request object using the Request () constructor

It can also be created through the FetchEvent.request api operation

Next, what does Request.credentials mean? the credential read-only attribute of the Request interface indicates whether the user agent should send cookie from other domains in the case of cross-domain requests. (for more information on methods of other Request objects, see https://developer.mozilla.org...)

When a request contains (Request.credentials) in credential mode is sent, if the Access-Control-Allow-Credentials value is true, the browser will expose the response only to the front-end JavaScript code.

Access-Control-Allow-Credentials: true

Credentials generally include cookie, authentication header and TLS client certificate

When used as part of the response to a pre-inspection request, this indicates whether the actual request can be made using credentials. Note that simple GET requests are not pre-checked.

You can refer to a practical example, https://www.jianshu.com/p/ea4....

Access-Control-Allow-Headers

Access-Control-Allow-Headers is a response header, which is used to respond to pre-check requests, which HTTP headers can be used when it makes the actual request.

Example

Custom header

This is an example of the Access-Control-Allow-Headers header. It indicates that in addition to request headers such as those listed in CROS security, CROS requests to the server also support a custom header named X-Custom-Header.

Access-Control-Allow-Headers: X-Custom-Header

Multiple headers

This example shows how Access-Control-Allow-Headers uses multiple headers

Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests

Bypass other restrictions

Although request headers listed in CORS security are always allowed and usually do not need to be listed in Access-Control-Allow-Headers, listing them will bypass other applicable restrictions anyway.

Access-Control-Allow-Headers: Accept

Here you may wonder, which are the security headers listed by CORS? (don't be too tired, it's so troublesome)

With the following Accep, Accept-Language, Content-Language, Content-Type, there is no need to send a pre-check request in the CORS context if and only if these headers are included.

Access-Control-Allow-Methods

Access-Control-Allow-Methods is also a response header, which specifies which methods of accessing resources can use pre-check requests. For example

Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Methods: *

Access-Control-Expose-Headers

The Access-Control-Expose-Headers response header indicates which headers can be exposed as part of the response. By default, only six response headers listed in CORS security are exposed, namely

Cache-Control

Content-Language

Content-Type

Expires

Last-Modified

Pragma

If you want the client to have access to other headers, you must list them using the Access-Control-Expose-Headers header. Here is an example

To expose request headers that are not listed securely in CORS, you can specify as follows

Access-Control-Expose-Headers: Content-Length

To otherwise expose custom headers, such as X-Kuma-Revision, you can specify multiple headers separated by commas

Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision

You can also use wildcards in non-credential requests

Access-Control-Expose-Headers: *

However, this does not come with Authorization headers, so if you need to expose it, you need to explicitly list

Access-Control-Expose-Headers: *, Authorization

Access-Control-Max-Age

The Access-Control-Max-Age response header indicates how long the results of the pre-check request can be cached, such as

Access-Control-Max-Age: 600

Indicates that the pre-check request can be cached for 10 minutes

Access-Control-Request-Headers

Browsers use Access-Control-Request-Headers request headers when issuing pre-check requests to let the server know which HTTP headers the client might send when the actual request is made.

Access-Control-Request-Headers: X-PINGOTHER, Content-Type

Access-Control-Request-Method

Similarly, the Access-Control-Request-Method response header tells the server which HTTP method to use when making a pre-check request. This header is required because the pre-check request is always OPTIONS and the method used is different from the actual request.

Access-Control-Request-Method: POST

Origin

The Origin request header indicates the source of the match, it contains no information, only the server name, it is sent with the CORS request and the POST request, it is similar to the Referer header, but unlike this header, it does not expose the entire path. For example

Origin: https://developer.mozilla.org

HTTP conditional request

HTTP has the concept of conditional request to determine whether the resource has been updated by comparing the value generated by the resource update with the value of the validator. Such requests are important for verifying the contents of the cache, conditional requests, and the integrity of resources.

Principle

HTTP conditional requests execute different requests based on the values of specific headers that define a prerequisite, and if the prerequisites match or do not match, the result of the request will be different.

For secure methods, such as GET, the resources used to request documents, they are sent back only when the conditions of the conditional request are met, so this approach can save bandwidth.

What is a secure method? for HTTP, a secure method is a method that does not change the state of the server. In other words, if the method is a read-only operation, then it must be a secure method, such as a GET request, it must be a secure method, because it just requests resources. Several common methods are definitely safe: GET, HEAD, and OPTIONS. All safe methods are idempotent (what does this fucking idempotent mean? But not all idempotent methods are safe, for example, PUT and DELETE are idempotent, but not secure

Idempotency: if the same client initiates one or more HTTP requests and gets the same result, then HTTP is idempotent. (we don't delve into idempotency this time.)

For non-secure methods, such as PUT, conditional requests can be used to transfer documents only if the original document is the same as the resources stored on the server. (the PUT method is usually used to transfer files, just like FTP protocol file upload.)

Verification

All conditional requests attempt to check whether the resource stored on the server matches a particular version of the resource. To meet this situation, the conditional request needs to indicate the version of the resource. Since it is impossible to compare the entire file character by character, you need to depict the entire file as a value, and then compare this value with the resources on the server, which is called a comparator, which has two conditions

The last modified date of the document

An opaque string that uniquely identifies each version, called an entity tag or Etag.

Comparing whether two resources are the same version is a bit complicated, depending on the context, there are two kinds of equality checks

Use strong Etag for verification when byte-to-byte comparisons are expected, such as when resuming downloads

Use if Etag to validate when the user agent needs to compare whether two resources have the same content

The HTTP protocol uses strong authentication by default, which specifies when weak authentication is performed.

Strong verification

Strong authentication guarantees byte-level verification, strict verification is very strict, may be difficult to guarantee at the server level, but it can guarantee that data will not be lost at any time, but this verification loses performance.

It is difficult to implement strong validation using Last-Modified, which is usually done by using Etag with the MD5 hash value of the resource.

Weak verification

Weak validation is different from strong validation because if the content is equal, it will assume that two versions of the document are the same. For example, the only difference between one page and another is that the footer has a different date, so the page is considered the same as the other pages. When using strong validation, the two versions are considered to be different. Building a validated Etag system can be complex because it requires understanding the importance of each page element, but it is useful for optimizing cache performance.

Here's how Etag implements strength verification.

The Etag response header is a version-specific identity that makes the cache more efficient and saves bandwidth, because the Web server does not need to resend the full response if the cache content has not changed. In addition, Etag can prevent resources from overwriting each other at the same time.

If a resource on a given URL changes, a new Etag value must be generated, and by comparing them, you can determine whether the two representations of the resource are the same.

There are two kinds of Etag values, one is strong Etag, the other is weak Etag

A strong Etag value that changes no matter how slightly the entity changes, which is generally expressed as follows

Etag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Weak Etag value, and weak Etag value is only used to indicate whether the resource is the same. The Etag value will be changed only when the resource changes fundamentally and there is a difference. At this point, W / is appended at the beginning of the field value.

Etag: W / "0815"

Let's discuss the relationship between the header of conditional request and Etag in detail.

Conditional request

The main headers of the conditional request are as follows

If-Match

If-None-Match

If-Modified-Since

If-Unmodified-Since

If-Range

If-Match

For the GET and POST methods, the server returns the requested resource only if it matches one of the listed Etag (response headers). Here is a new word Etag. We will talk about the usage of Etag later. For methods such as PUT and other non-secure methods, in this case, it will only upload resources.

Here are two common cases

For the GET and POST methods, the Range header is used together, which ensures that the scope of the new request is the same as the resource of the previous request, and returns a 416 response if it does not match.

For other methods, especially the PUT method, If-Match prevents the loss of updates, and the server compares the field value of If-Match to the Etag value of the resource, and the request is executed only if the two are consistent. Otherwise, the response of the status code 412 Precondition Failed is returned. For example

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d" If-Match: *

If-None-Match

A conditional request, which is the opposite of If-Match, can be processed only if the field value of If-None-Match is inconsistent with the Etag value. For GET and HEAD, the server will return 200 OK in response only if the server does not have an Etag that matches the given resource. For other methods, the request is processed only if the Etag of the final existing resource does not match any of the values listed.

When the If-None-Match sent by GET and POST matches Etag, the server returns 304.

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d" If-None-Match: W / "67ab43", "54ed21", "7892dd" If-None-Match: *

If-Modified-Since

If-Modified-Since is part of a HTTP conditional request, and a 200 OK response will be returned only if the server modifies the resources required for the request after a given date. If the server does not modify the content after a given date, the response returns 304 without any response body. If-Modified-Since can only use GET and HEAD requests.

When If-Modified-Since is used in conjunction with If-None-Match, it is ignored unless the server does not support If-None-Match. It is generally expressed as follows

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

Note: this is Greenwich mean time. HTTP dates are always expressed in Greenwich mean time, not local time.

If-Range

If-Range is also a conditional request, and if the condition is met (the value of If-Range is the same as the Etag value or the date and time of the update), a range request will be issued, otherwise all resources will be returned. Its general expression is as follows

If-Range: Wed, 21 Oct 2015 07:28:00 GMT If-Range: bfc13a64729c4290ef5b2c2730249c88ca92d82d

If-Unmodified-Since

The If-Unmodified-Since HTTP request header is also a conditional request, and the server returns the requested resource only if it has not been modified after a given date. If an update occurs after the specified date and time, it is returned with a status code 412 Precondition Failed in response.

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT

Example of conditional request

Cache update

The most common example of a conditional request is the update cache, which is sent back to the requested resource in a state of 200 OK if the cache is empty or there is no cache. As shown in the following figure

The client sends no request for the first time, the cache is empty and there is no conditional request. After receiving the client request, the server sets the validator Last-Modified and Etag tags, and sends these two tags back to the client along with the response.

The next time the client sends the same request, it will be extracted directly from the cache, and as long as the cache does not expire, no new request will arrive at the server to re-download the resource. However, once the cache expires, the client does not directly use the cached value, but issues a conditional request. The validator value is used as a parameter for the If-Modified-Since and If-Match headers.

After the cache expires, the client re-initiates the request, and after receiving the request, the server finds that if the resource has not changed, the server will send back a 304 Not Modified response, which refreshes the cache again and allows the client to use the cached resource. Although a response / request round trip consumes some resources, it is more efficient than transmitting the entire resource over the wire again.

If the resource has changed, the server only returns a 200 OK response with the new version of the resource, as if there were no conditional requests, and the client reuses the new resource, from this point of view, caching is a prerequisite for conditional requests.

Breakpoint continuation

HTTP can support partial downloads of files, which allows you to resume previous operations by retaining the information you have obtained, thereby saving bandwidth and time.

Servers that support breakpoint continuation broadcast this message by sending Accept-Ranges headers, and when this happens, clients can resume downloads by sending Ranges headers that lack a range

Here you may have a question about what Ranges and Content-Range are. Let's explain.

Range

The Range HTTP request header indicates that the server should return resources for specified parts of the document, and can request one Range at a time to return multiple parts, and the server will return these resources to each document. If the server returns successfully, it returns a 206response; if the Range range is invalid, the server returns a 416Range Not Satisfiable error; the server can also ignore the Range header and return 200in response.

Range: bytes=200-1000, 2000-6576, 19000-

There is also an indication that

Range: bytes=0-499,500

They represent the first 500 bytes and the last 500 bytes of the request, respectively, and the server may reject the request if the ranges overlap.

Content-Range

The Content-Range response header of HTTP is set for the range request. When the response is returned, the header field Content-Range is used to tell the client which part of the response entity is in line with the client request, and the field is in bytes. Its general expression is as follows

Content-Range: bytes 200-1000 Universe 67589

The above code indicates that 200-1000 bytes are returned from all 67589 bytes

Then you should also know what the above Content-Range means.

The principle of breakpoint continuation is relatively simple, but there is a potential problem with this approach: if the resource is updated during two downloads, the scope obtained will correspond to two different versions of the resource, and the final document will be corrupted.

To prevent this from happening, conditional requests are used. For scope, there are two ways to do this. One way is to use If-Modified-Since and If-Match, where the server returns an error if the prerequisites fail; then the client downloads again from scratch.

Even if this method works, it adds additional response / request exchanges when document resources change. This degrades performance, and HTTP has specific headers to avoid this situation, If-Range.

The solution is more efficient but slightly less flexible because only one Etag can be used in this case.

Avoid losing updates through optimistic locks

The most common operation in Web applications is resource updates. This is common in any file system or application, but any application that allows remote resources to be stored requires this mechanism.

You can do this using the put method, where the client first reads the original file and modifies it, and then sends them to the server.

There is a problem with the above request response, and once concurrency is taken into account, things become inaccurate. When the client modifies the resource locally and intends to resend, the second client can get the same resource and modify the resource, which can cause problems. When they resend the request to the server, the changes made by the first client will be overwritten by the second client modification, because the second client modification does not know that the first client is modifying. The party who submits and updates the resource will not communicate it to the other party, so which customer's changes will change depending on the speed at which they submit; it depends on the performance of the client, the server, and even on the performance of manually editing documents on the client side. For example, the following process

If no two users operate the server at the same time, this problem does not exist. However, in reality, it is impossible for only a single user to appear, so in order to avoid or avoid this problem, we want client resources to be notified when they are prompted for updates or when changes are rejected.

The conditional request allows the optimistic locking algorithm to be implemented. The concept is to allow all clients to obtain copies of resources, then let them modify resources locally, and successfully control concurrency by allowing the first client to submit updates, and updates based on later versions of this server will be rejected.

This is done using If-Match or If-Unmodified-Since headers. If the Etag does not match the original file, or if the file has been modified since it was obtained, the update is rejected and a 412 Precondition Failed error is displayed.

HTTP Cookies

Cookie in the HTTP protocol includes Web Cookie and browser Cookie, which is a small piece of data sent by the server to the Web browser. The server sends it to the browser's Cookie, which stores it and sends it to the server with the next request. Typically, it is used to determine whether two requests come from the same browser, such as keeping the user logged in.

HTTP Cookie mechanism is a supplement and improvement of stateless HTTP protocol.

Cookie is mainly used for the following three purposes

Session management

Login, shopping cart, game score or other things the server should remember

Individuation

User preferences, themes, or other settings

Tracking

Record and analyze user behavior

Cookie was used for general client-side storage. Although this is legal because they are the only way to store data on the client, modern storage API is now recommended. Cookie are sent with each request, so they can degrade performance (especially for mobile data connections). The modern API stored on the client is Web storage API (localStorage and sessionStorage) and IndexedDB.

Create Cookie

When a HTTP request is received from the client, the server can send a Set-Cookie header with a response, the Cookie is usually stored by the browser, and then send the Cookie together with the HTTP header to the server. You can specify an expiration date or duration, after which Cookie will no longer be sent. In addition, restrictions on specific domains and paths can be set to limit where cookie is sent.

Set-Cookie and Cookie headers

The Set-Cookie HTTP response header sends the cookie from the server to the user agent. Here is an example of sending a Cookie

HTTP/2.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [page content]

This header tells the client to store Cookie

Now, with each new request to the server, the browser will use the Cookie header to send all previously stored cookie back to the server.

GET / sample_page.html HTTP/2.0 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Cookie is mainly divided into three categories, which are the Secure and HttpOnly tags of session Cookie, persistent Cookie and Cookie. Let's introduce them in turn.

Session Cookies

The above example creates a session Cookie, and the session Cookie has a feature that the Cookie is deleted when the client is closed because it does not specify an Expires or Max-Age instruction. You should be familiar with these two instructions here.

However, Web browsers may use session restore, which makes most session Cookie permanent, as if the browser had never been closed

Permanent Cookies

A permanent Cookie does not expire when the client is shut down, but outside a specific date (Expires) or a specific length of time (Max-Age). For example

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

Secure and HttpOnly tags for Cookie

Secure Cookie needs to be sent to the server through the HTTPS protocol and encrypted. Even if it is secure, sensitive information should not be stored in cookie because they are inherently insecure and this flag does not provide real protection.

The role of HttpOnly

The lack of HttpOnly attribute in session cookie can cause attackers to obtain user cookie information through programs (JS scripts, Applet, etc.), resulting in disclosure of user cookie information and increasing the threat of cross-site scripting attacks by attackers.

HttpOnly is an extension of cookie made by Microsoft, which specifies whether cookie can be accessed through client script.

If the HttpOnly property is not set to true in Cookie, it may cause Cookie to be stolen. The stolen Cookie can contain sensitive information that identifies the users of the site, such as ASP.NET session ID or Forms authentication tickets, and attackers can replay the stolen Cookie in order to disguise as users or obtain sensitive information and carry out cross-site scripting attacks.

Scope of Cookie

The Domain and Path identities define the scope of the Cookie: that is, to which URL the Cookie should be sent.

The Domain identity specifies which hosts can accept Cookie. If not specified, the default is the current host (no subdomain name). If Domain is specified, the subdomain name is generally included.

Thank you for your reading, the above is the content of "take you to understand HTTP cool techs". After the study of this article, I believe you have a deeper understanding of the problem of bringing you to understand HTTP cool techs, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.