我们应该在发送响应时关闭飞行前 Cors 请求的连接吗？

Posted 2023-02-27

【中文标题】我们应该在发送响应时关闭飞行前 Cors 请求的连接吗？

【英文标题】：should we close the connection of a pre-flight Cors request while sending response?

【发布时间】：2016-09-24 13:02:28

【问题描述】：

据我所知，如果 cors 请求带有一些额外的标头集，则第一个服务器需要处理它。

使用 CORS，服务器必须发送 Access-Control-Allow-Headers 标头以允许来自客户端的不常见的请求标头。

Access-Control-Allow-Headers ... - 支持的请求标头的逗号分隔列表。

例如，假设我的飞行前请求是

OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

然后我会从服务器端发送响应

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8

我的问题是—— 当我们向客户端发送飞行前响应时，我应该关闭服务器端的连接吗？

还有一件事，我如何为所有其他不同的后续请求缓存飞行前请求？

谢谢

【参考方案1】：

您可以使用

缓存 OPTIONS 请求

访问控制最大年龄

标题。 将其附加到 OPTIONS 响应的 headers 集合中。

但是，用户代理（浏览器）必须发出初始 OPTIONS 请求，您无法避免这种情况。 但是所有进一步的 OPTIONS 请求都被缓存并且不会发送到服务器。 无需关闭连接。

访问控制允许来源：http://hello-world.example

访问控制最大年龄：3628800

访问控制允许方法：PUT

按照here的解释，搜索

可以指定以下标头

到达指定的文本部分。

【讨论】：

其他不同的后续请求将再次使用 Access-Control-Allow-Headers 请求预检请求。

您不能预先缓存初始的不同请求，只能缓存不同请求的进一步 OPTION 请求。这是一个浏览器的事情。

这是答案，没有其他可能的解决方法:-)

所以如果你有 50 个休息端点，那么你将不得不发送 100 个请求。

最初是的，如果您如上所述缓存 OPTION 请求，则后续只执行一个请求而没有第二个 Option 请求。