跨域 cors 请求两次_请求两次的故事-CORS

跨域 cors 请求两次

The story of requesting twice, allow me to explain how it all began.

请求两次的故事，让我解释一下这是如何开始的。

While working on a feature, I decided to look at the network tab and observed that the first request was sent with method OPTIONS, and the following request after it was the request with the correct method eg GET, POST etc, which is returning the expected payload. Basically two calls for the same request.

在使用某个功能时，我决定查看“网络”选项卡，并观察到第一个请求是使用方法OPTIONS发送的，随后的请求是使用正确方法(例如GET，POST等)的请求，该请求正在返回预期的结果有效载荷。 基本上是两个请求相同的请求。

Here take a look at the screen shots below

这里看看下面的屏幕截图

After digging few docs, I realised it was an expected behaviour. It is related to the concept of HTTP access control (CORS).

挖掘了几篇文档后，我意识到这是一种预期的行为。 它与HTTP访问控制(CORS)的概念有关。

To understand it better, let me explain a bit about CORS and requests.

为了更好地理解它，让我解释一些有关CORS和请求的信息。

HTTP访问控制(CORS) (HTTP access control (CORS))

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use.

跨域资源共享( CORS )是一种机制，它使用附加的HTTP标头来使用户代理获得从与当前使用的站点不同的源(域)上的服务器访问选定资源的权限。

Let us understand the above image above to get a better understanding of CORS.

让我们了解上面的图片，以更好地了解CORS。

1. Same Origin Request: We have opened domain-a.com, where we are requesting a blue image hosted in web server domain-a.com. Since we are performing our requests in the same domain, it is called a Same-origin request.

   相同来源请求：我们已经打开domain-a.com ，在这里我们请求托管在Web服务器domain-a.com中的蓝色图像 。 由于我们在同一个域中执行请求，因此称为“同源请求”。

2. Cross Origin Request: We have opened domain-a.com, where we are requesting a red image hosted in web server domain-b.com. Since we are performing our requests in different domains, it is called a Cross-origin Request.

   跨源请求：我们已经打开domain-a.com ，在此我们请求托管在Web服务器domain-b.com中的红色图像 。 由于我们在不同的域中执行请求，因此称为跨源请求。

简单的要求 (Simple requests)

These are requests that doesn't send it’s first request as method OPTIONS. It is fired only once.

这些请求不会将其第一个请求作为方法OPTIONS发送。 它仅发射一次。

Surely it begs the question, why will the first request have method OPTIONS if we are not sending it, please have patience it will be explained below in preflight section ☺

毫无疑问，这是一个问题，如果我们不发送第一个请求，为什么第一个请求会有方法OPTIONS，请耐心等待，这将在以下预检部分section中进行说明。

But before that let us understand what are the points that make request simple.

但是在此之前，让我们了解使请求变得简单的要点。

1. The only allowed methods in simple request are:
   简单请求中唯一允许的方法是：

• GET

  得到

• HEAD

  头

• POST

  开机自检

2. Apart from the headers set automatically by the user agent (for example, connection , User-Agent, or any of the other headers with names defined in the Fetch spec as a “forbidden header name”), the only headers which are allowed to be manually set are those which the Fetch spec defines as being a “CORS-safelisted request-header”, which are:

2.除了由用户代理自动设置的标头(例如，connection， User-Agent或其他名称在Fetch规范中定义为“禁止标头名”的标头)外，仅允许使用标头可以手动设置的是Fetch规范定义为“ CORS安全列出的请求标头”的那些标头 ，它们是：

• Accept
  接受
• Accept-Language
  接受语言
• Content-Language
  内容语言
• Content-Type
  内容类型
• DPR
  DPR
• Downlink
  下行链接
• Save-Data
  保存数据
• Viewport-Width
  视口宽度
• Width
  宽度

3. The only allowed values for the Content-Type header are:

3. Content-Type标头的唯一允许值为：

• application/x-www-form-urlencoded
  应用程序/ x-www-form-urlencoded
• multipart/form-data
  多部分/表单数据
• text/plain
  文字/纯文字

4. No event listeners are registered on any XMLHttpRequestUpload object used in the request.

4.没有在事件中使用的任何XMLHttpRequestUpload对象上注册事件侦听器。

5. No ReadableStream object is used in the request.

5.请求中未使用ReadableStream对象。

事前要求 (Preflighted requests)

Preflighted request is a type of request which sends an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data. It is evident from the screenshots above.

预检请求是一种请求，它通过OPTIONS方法将HTTP请求发送到另一个域上的资源，以确定实际请求是否可以安全发送。 跨站点请求这样被预检，因为它们可能会影响用户数据。 从上面的截图可以明显看出。

For requests like PUT, DELETE, PATCH etc, preflight requests are sent.

对于PUT，DELETE，PATCH等请求，将发送预检请求。

Below flowchart summarises really well how it works.

下面的流程图很好地总结了它是如何工作的。

This flowchart opens up a door to a whole new knowledge. Couldn’t help but appreciate how good it is!

该流程图为全新的知识打开了一扇门。 不禁感激它有多棒！

Strangely enough even GET request was observed to have preflights which for my case was due to presence of custom header Authorization, which can be seen from the screenshot below

奇怪的是，即使是GET请求也被发现有预检，对于我而言，这是由于存在自定义标头授权，可以从下面的屏幕截图中看到

飞行前要求不好吗？ (Is Preflight request bad?)

It is a small request without a body, but I always felt it as a bother. It is still a request, and each request is a cost, no matter how small that request is, so I definitely recommend to try and avoid having such cases.

没有身体这是一个很小的要求，但是我一直觉得这很麻烦。 它仍然是一个请求，每个请求都是成本，无论该请求有多小，所以我绝对建议尝试避免此类情况。

我们如何避免呢？ (How do we avoid it?)

Well the easiest solution is avoid CORS, try to keep our resources and APIs in the same domain. It is really that simple.

最简单的解决方案是避免使用CORS，请尝试将我们的资源和API放在同一域中。 真的就是这么简单。

结论 (Conclusion)

It is always good to be armed with knowledge of how requests work. Even if the cost is very low, it still matters. Saving small requests can make our application really fast in the long run. Well I believe in the future, which is fast and furious.

知道请求如何工作总是很好。 即使成本很低，它仍然很重要。 从长远来看，保存小的请求可以使我们的应用程序真正更快。 好吧，我相信未来，这是快速而愤怒的。

Follow me on twitter to get more updates regarding new articles and to stay updated in latest frontend developments. Also share this article on twitter to help others know about it. Sharing is caring ^_^

跟我来 Twitter以获得有关新文章的更多更新，并保持最新的前端开发更新。 也可以在Twitter上分享此文章，以帮助其他人了解它。 分享是关怀^ _ ^

一些有用的资源 (Some helpful resources)

Below are some of the links that inspired this article

以下是一些启发本文的链接

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

   https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS

2. https://stackoverflow.com/questions/24704638/options-request-makes-application-2x-slower

   https://stackoverflow.com/questions/24704638/options-request-makes-application-2x-slower

3. https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it/29954326

   https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it/29954326

4. https://www.html5rocks.com/en/tutorials/cors/

   https://www.html5rocks.com/zh-CN/tutorials/cors/

翻译自: https://www.freecodecamp.org/news/the-story-of-requesting-twice-cors/

跨域 cors 请求两次