Why does the record --post send two requests?

Here I will share with you some of the knowledge I have summarized on the Internet, I hope it will be helpful to everyone

In an interview some time ago, I was asked a question like the title. To answer this question properly, there are many knowledge points involved here.

Then in the next article we will start to raise this question bit by bit.

Same Origin Policy

In the browser, the content is very open, and any resources can be accessed, such as JavaScript files, pictures, audio/video and other resources, and even executable files from other sites can be downloaded.

But it does not mean that the browser is completely free. If it is not controlled, there will be some uncontrollable situations, such as some security problems, such as:

• Cross Site Scripting (XSS)
• SQL injection attack
• OS command injection attack
• HTTP header injection attack
• Cross Site Request Forgery (CSRF)
• etc......

If there are no restrictions on these, malicious words for our users are relatively dangerous, so some security policies are needed to protect our privacy and data security.

This leads to the most basic and core security policy: the same-origin policy.

What is the Same Origin Policy

The same-origin policy is an important security policy used to restrict how a document from one origin, or a script it loads, can interact with resources from another origin.

Two URLs are said to have the same origin if their protocol, host, and port are the same.

• Protocol: A protocol is a system that defines the rules for how data is exchanged within and between computers, eg HTTP, HTTPS.
• Host: An electronic computer or other device connected to a computer network. Network hosts can provide information resources, services and applications to users or other nodes on the network. Computers that participate in a network using the TCP/IP protocol suite are also referred to as IP hosts.
• Port: The host is computer-to-computer communication, then the port is process-to-process communication.

The following table gives http://store.company.com:80/dir/page.htmlan example of comparing with the source of the URL:

URL	result	reason
http://store.company.com:80/dir/page.html	Homologous	Only the path is different
http://store.company.com:80/dir/inner/another.html	Homologous	Only the path is different
https://store.company.com:80/secure.html	different source	Different protocols, HTTP and HTTPS
http://store.company.com:81/dir/etc.html	different source	different ports
http://news.company.com:80/dir/other.html	different source	Host is different

The same-origin policy is mainly manifested in the following three aspects: DOM, Web data and network.

• DOM 访问限制：同源策略限制了网页脚本(如 JavaScript)访问其他源的 DOM。这意味着通过脚本无法直接访问跨源页面的 DOM 元素、属性或方法。这是为了防止恶意网站从其他网站窃取敏感信息。
• Web 数据限制：同源策略也限制了从其他源加载的 Web 数据(例如 XMLHttpRequest 或 Fetch API)。在同源策略下，XMLHttpRequest 或 Fetch 请求只能发送到与当前网页具有相同源的目标。这有助于防止跨站点请求伪造(CSRF)等攻击。
• 网络通信限制：同源策略还限制了跨源的网络通信。浏览器会阻止从一个源发出的请求获取来自其他源的响应。这样做是为了确保只有受信任的源能够与服务器进行通信，以避免恶意行为。

出于安全原因，浏览器限制从脚本内发起的跨源 HTTP 请求，XMLHttpRequest 和 Fetch API，只能从加载应用程序的同一个域请求 HTTP 资源，除非使用 CORS 头文件

CORS

对于浏览器限制这个词，要着重解释一下：不一定是浏览器限制了发起跨站请求，也可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。

例如，一个网页可能通过 AJAX 请求从另一个域的服务器获取数据。虽然某些情况下这样的请求可能会成功，但如果浏览器检测到请求返回的数据可能包含恶意代码或与同源策略冲突，浏览器可能会阻止网页访问返回的数据，以确保用户的安全。

跨源资源共享(Cross-Origin Resource Sharing，CORS)是一种机制，允许在受控的条件下，不同源的网页能够请求和共享资源。由于浏览器的同源策略限制了跨域请求，CORS 提供了一种方式来解决在 Web 应用中进行跨域数据交换的问题。

CORS 的基本思想是，服务器在响应中提供一个标头(HTTP 头)，指示哪些源被允许访问资源。浏览器在发起跨域请求时会先发送一个预检请求(OPTIONS 请求)到服务器，服务器通过设置适当的 CORS 标头来指定是否允许跨域请求，并指定允许的请求源、方法、标头等信息。

简单请求

不会触发 CORS 预检请求。这样的请求为 简单请求，。若请求满足所有下述条件，则该请求可视为 简单请求：

1. HTTP 方法限制：只能使用 GET、HEAD、POST 这三种 HTTP 方法之一。如果请求使用了其他 HTTP 方法，就不再被视为简单请求。
2. 自定义标头限制：请求的 HTTP 标头只能是以下几种常见的标头：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type(仅限于 application/x-www-form-urlencoded、multipart/form-data、text/plain)。HTML 头部 header field 字段：DPR、Download、Save-Data、Viewport-Width、WIdth。如果请求使用了其他标头，同样不再被视为简单请求。
3. 请求中没有使用 ReadableStream 对象。
4. 不使用自定义请求标头：请求不能包含用户自定义的标头。
5. 请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问

预检请求

非简单请求的 CORS 请求，会在正式通信之前，增加一次 HTTP 查询请求，称为 预检请求。

需预检的请求要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。预检请求 的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。

例如我们在掘金上删除一条沸点:

它首先会发起一个预检请求,预检请求的头信息包括两个特殊字段：

• Access-Control-Request-Method：该字段是必须的，用来列出浏览器的 CORS 请求会用到哪些 HTTP 方法，上例是 POST。
• Access-Control-Request-Headers：该字段是一个逗号分隔的字符串，指定浏览器 CORS 请求会额外发送的头信息字段，上例是 content-type,x-secsdk-csrf-token。
• access-control-allow-origin：在上述例子中，表示 https://juejin.cn 可以请求数据，也可以设置为* 符号，表示统一任意跨源请求。
• access-control-max-age：该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是 1 天(86408 秒)，即允许缓存该条回应 1 天(86408 秒)，在此期间，不用发出另一条预检请求。

一旦服务器通过了 预检请求，以后每次浏览器正常的 CORS 请求，就都跟简单请求一样，会有一个 Origin 头信息字段。服务器的回应，也都会有一个 Access-Control-Allow-Origin 头信息字段。

上面头信息中，Access-Control-Allow-Origin 字段是每次回应都必定包含的。

附带身份凭证的请求与通配符

在响应附带身份凭证的请求时：

• 服务器不能将 Access-Control-Allow-Origin 的值设为通配符 *，而应将其设置为特定的域，如：Access-Control-Allow-Origin: https://example.com。
• 服务器不能将 Access-Control-Allow-Headers 的值设为通配符 *，而应将其设置为标头名称的列表，如：Access-Control-Allow-Headers: X-PINGOTHER, Content-Type。
• 服务器不能将 Access-Control-Allow-Methods 的值设为通配符 *，而应将其设置为特定请求方法名称的列表，如：Access-Control-Allow-Methods: POST, GET。
• 对于附带身份凭证的请求(通常是 Cookie)，

这是因为请求的标头中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为 *，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 https://example.com，则请求将成功执行。

另外，响应标头中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。如果操作失败，将会抛出异常。

参考文章

• CORS 简单请求+预检请求(彻底理解跨域)
• 跨域资源共享 CORS 详解
• 跨源资源共享(CORS)

总结

预检请求是在进行跨域资源共享 CORS 时，由浏览器自动发起的一种 OPTIONS 请求。它的存在是为了保障安全，并允许服务器决定是否允许跨域请求。

跨域请求是指在浏览器中向不同域名、不同端口或不同协议的资源发送请求。出于安全原因，浏览器默认禁止跨域请求，只允许同源策略。而当网页需要进行跨域请求时，浏览器会自动发送一个预检请求，以确定是否服务器允许实际的跨域请求。

预检请求中包含了一些额外的头部信息，如 Origin 和 Access-Control-Request-Method 等，用于告知服务器实际请求的方法和来源。服务器收到预检请求后，可以根据这些头部信息，进行验证和授权判断。如果服务器认可该跨域请求，将返回一个包含 Access-Control-Allow-Origin 等头部信息的响应，浏览器才会继续发送实际的跨域请求。

使用预检请求机制可以有效地防范跨域请求带来的安全风险，保护用户数据和隐私。

整个完整的请求流程有如下图所示：

本文转载于:

https://juejin.cn/post/7269952188927017015

如果对您有所帮助，欢迎您点个关注，我会定时更新技术文档，大家一起讨论学习，一起进步。