为什么跨源头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的请求
方法首先需要使用
预检结果缓存条目或预检请求进行授权。

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通过< img>发送跨源GET或POST。 或< 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）以及简单请求标头。这些对应于您可以从浏览器前CORS规范发送的跨源请求的类型。非简单的跨源请求，例如带有X-header的PUT或POST / GET请求（例如）不能从浏览器前CORS规范发送。因此，对于这些类型的请求，将预检的概念写入规范中，以确保服务器不会明确选择接收这些类型的非简单的跨源浏览器请求。换句话说，如果您没有想要允许这些类型的请求，你不必改变你的服务器。预检将失败，浏览器将永远不会发送底层请求。

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请求前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屋！