对无效 CORS 请求的预期响应是什么? [英] What is the expected response to an invalid CORS request?

问题描述

CORS 规范没有说明服务器应如何响应无效的 CORS 请求.例如，如果请求 Origin 无效，CORS 规范声明:终止这组步骤. 该请求超出了本规范的范围."其他错误情况也有类似的语言，例如请求无效的方法或标头.

The CORS spec is silent on how servers should respond to invalid CORS requests. For example, if the request Origin is invalid, the CORS spec states: "terminate this set of steps. The request is outside the scope of this specification." There is similar language for other error cases, such as requesting invalid methods or headers.

如果出现 CORS 错误，预期的响应应该是什么?我了解不同的服务器可能需要不同的行为.但我正在寻找一个或多个标准响应，如果服务器所有者不在乎，则可以接受.

What should the expected response be in the case of CORS errors? I understand that different servers may require different behavior. But I'm looking for a standard response or responses that could be acceptable if the server owner doesn't care.

推荐答案

是的，我意识到我正在回答我自己的问题，但无论如何它都在这里.我对此进行了一些研究，似乎行为分为两个阵营:

Yes, I realize I'm answering my own question, but here it goes anyway. I did some research into this and it seems like behavior falls into two camps:

1) 如果 CORS 请求无效，则返回错误. 这是 Java CORS 过滤器 项目.这个库返回

1) Return an error if the CORS request is invalid. This is the route taken by the Java CORS filter project. This library returns

• 400 Bad Request 用于不符合规范的请求
• 403 Forbidden for invalid origins or headers.
• 405 Method Not Allow for invalid方法

2) 在响应中返回 CORS 标头并让浏览器整理访问详细信息. 这似乎是更常见的方法，并且被用于 Amazon S3、SoundCloud、FourSquare 和 Spotify(后两个 API 受益于仅支持简单的 CORS 请求).在这种情况下，服务器不做任何错误检查，而只是返回支持的源、方法和标头的 CORS 标头.浏览器仍然发出请求，但如果 CORS 响应标头与用户的请求不匹配，浏览器将拒绝用户的响应.

2) Return CORS headers in the response and let the browser sort out the access details. This seems to be the far more common approach, and is used by the APIs for Amazon S3, SoundCloud, FourSquare and Spotify (the latter two APIs benefit from only supporting simple CORS requests). In this case, the server doesn't do any error checking, and just returns the CORS headers for the supported origin, method and headers. The browser still makes the request, but if the CORS response headers don't match the user's request, the browser withholds the response from the user.

这些方法各有优缺点.方法 #1 更接近 CORS 规范，但没有为用户提供有用的调试信息.

Each of these methods has their pros and cons. Method #1 is more closely aligned to the CORS spec, but provides no useful debugging information to the user.

方法 #2 更深入地了解支持的方法和标头是什么.它也更容易实现，因为无论请求标头如何，服务器都会返回相同的响应标头.然而，这是以在服务器端实际执行请求为代价的，即使浏览器会阻止用户的响应.这对于具有副作用的方法(例如 POST、PUT 或 DELETE)可能是不可取的，并强调了 CORS 不应用作身份验证机制这一事实.

Method #2 provides more insight into what the supported methods and headers are. It is also easier to implement, since the server is returning the same response headers regardless of the request headers. However this comes at the expense of actually executing the request on the server-side, even though the browser will block the response from the user. This may not be desirable for a method with side-effects, such as POST, PUT or DELETE and highlights the fact that CORS should not be used as an authentication mechanism.

(请注意，我上面的研究绝不是详尽无遗的.很难看到许多 API 的真实行为，因为它们要么需要身份验证，要么因其他错误(例如不受支持)而在不同级别阻止请求方法.)

(Note that my research above is by no means exhaustive. It was tough to see the true behavior for many APIs, since they either required auth, or blocked the request at a different level for some other error, such as an unsupported method.)

这篇关于对无效 CORS 请求的预期响应是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！