cross-domain - 为什么跨域 HEAD 请求需要预检？

Question

我正在阅读 spec关于 CORS 请求，我发现了关于预检请求的信息:

These are requests to a non same origin URL with an HTTP request method other than GET that first need to be authorized using either a preflight result cache entry or a preflight request.

我原以为预检请求的目的是在发出请求之前检查是否允许请求，以防它(非法)更改服务器状态。

但是 HEAD 和 OPTIONS 不会修改服务器状态。我肯定误解了飞行前检查的原因。

对 HEAD 和 OPTIONS 进行预检但不对 GET 进行预检的目的(又名原因、动机或基本原理)是什么？ GET 有什么特别之处？

Answer 1

预检的主要目的是确保服务器不会突然发送基于跨域浏览器的请求，而这些请求在实现 CORS 规范之前是不可能收到的。

在 CORS 规范出现之前，除了 GET 或 POST 之外，无法发送任何基于浏览器的跨源请求。浏览器根本不允许您启动 XHR 实例、将方法设置为 PUT(例如)并将其发送到不同来源的端点。您也无法通过 XHR 发送 GET 或 POST 跨域请求，但您可以通过表单提交发送跨域 GET 或 POST，或者通过 <img> 发送跨域 GET。或<script>例如，标签(这使得 JSONP 成为 CORS 之前的唯一选择)。一旦浏览器实现了 CORS 规范，这种情况就发生了变化。现在，只要服务器选择加入，就可以发送任何跨域 ajax 请求。

CORS 规范定义了“简单”方法(GET 和 POST)以及“简单”请求 header 。这些对应于您可以从 CORS 规范之前的浏览器发送的跨源请求类型。非简单跨源请求，例如带有 X header 的 PUT 或 POST/GET 请求(例如)无法从 CORS 规范之前的浏览器发送。因此，对于这些类型的请求，预检的概念被写入规范中，以确保服务器在没有明确选择的情况下不会接收这些类型的非简单的基于浏览器的请求。换句话说，如果您不这样做如果想要允许这些类型的请求，您根本不必更改服务器。预检将会失败，浏览器将永远不会发送底层请求。

直接解决您的问题:HEAD 请求通常不会导致预检。根据 CORS 规范，HEAD 被认为是一种简单的请求方法。如您所知，HEAD 请求只是没有响应负载的 GET。这就是为什么 HEAD 和 GET 请求被同等对待的最可能原因，即使您无法从浏览器发送跨域 HEAD 请求 pre-CORS。如果您的 HEAD 包含非简单 header ，则会对其进行预检，就像 GET 一样。