为什么跨域 HEAD 请求需要预检? [英] Why does a cross-origin HEAD request need a preflight check?

问题描述

我正在阅读关于 CORS 请求的规范，并且我发现这是关于预检请求的:

I was reading the spec on CORS requests, and I found this about preflight requests:

这些是对具有 HTTP 请求的非同源 URL 的请求GET 以外的方法，首先需要使用预检结果缓存条目或预检请求.

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.

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

I had thought the purpose of preflight requests was to check whether a request was allowed before making it, in case it (illegitimately) changed server state.

但 HEAD 和 OPTIONS 不会修改服务器状态.我一定误解了预检的原因.

But HEAD and OPTIONS don't modify server state. I must misunderstand the reason for preflight check.

对 HEAD 和 OPTIONS 而不是 GET 进行预检的目的(也称为原因、动机或原理)是什么?GET 有什么特别之处?

What is the purpose (aka the reason, motivation, or rationale) for doing a preflight check for HEAD and OPTIONS but not GET? What is special about GET?

推荐答案

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

The primary intent of preflighting is to ensure that servers aren't suddenly sent cross-origin browser-based requests that they could have never received before the CORS spec was implemented.

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

Before the CORS spec, it was impossible to send any browser-based cross-origin requests other than GET or POST. The browser simply would not allow you to fire up an XHR instance, set the method to PUT (for example) and send it off to an endpoint on a different origin. You couldn't send GET or POST cross-origin requests via XHR either, but you COULD send a cross-origin GET or POST via a form submit, or a cross-origin GET via an <img> or <script> tag, for example (which made JSONP the only option pre-CORS). Once browsers implemented the CORS spec, this changed. Now it IS possible to send any cross-origin ajax request, provided the server opts-in.

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

The CORS spec defines "simple" methods (GET and POST) along with "simple" request headers. These correspond to the types of cross-origin requests that you could already send from the browser pre-CORS spec. Non-simple cross-origin requests, such as PUT or POST/GET requests with an X-header (for example) could not be sent from a browser pre-CORS spec. So, for these types of requests, the concept of preflighting was written into the spec to ensure servers do not receive these types of non-simple cross-origin browser-based requests without explicitly opting in. In other words, if you don't want to allow these types of requests, you don't have to change your server at all. The preflight will fail, and the browser will never send the underlying request.

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

Directly addressing your question: HEAD requests do not normally result in a preflight. HEAD is considered a simple request method according to the CORS spec. As you know, HEAD requests are just GETs without a response payload. This is the most likely reason why HEAD and GET requests are treated the same, even though you could not send a cross-origin HEAD request pre-CORS from the browser. If your HEAD contains non-simple headers, it will be preflighted though, just like GET.

这篇关于为什么跨域 HEAD 请求需要预检?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！