为什么不将CORS标头添加到OPTIONS路由允许浏览器访问我的API? [英] Why doesn't adding CORS headers to an OPTIONS route allow browsers to access my API?

问题描述

我正在尝试在使用Express.js Web框架的Node.js应用程序中支持CORS.我已阅读过有关如何处理此问题的Google小组讨论，并阅读一些有关CORS运作方式的文章.首先，我做到了(代码是用CoffeeScript语法编写的):

I am trying to support CORS in my Node.js application that uses the Express.js web framework. I have read a Google group discussion about how to handle this, and read a few articles about how CORS works. First, I did this (code is written in CoffeeScript syntax):

app.options "*", (req, res) ->
  res.header 'Access-Control-Allow-Origin', '*'
  res.header 'Access-Control-Allow-Credentials', true
  # try: 'POST, GET, PUT, DELETE, OPTIONS'
  res.header 'Access-Control-Allow-Methods', 'GET, OPTIONS'
  # try: 'X-Requested-With, X-HTTP-Method-Override, Content-Type, Accept'
  res.header 'Access-Control-Allow-Headers', 'Content-Type'
  # ...

它似乎不起作用.看来我的浏览器(Chrome)没有发送初始的OPTIONS请求.当我刚刚更新资源块时，我需要向以下站点提交跨域GET请求:

It doesn't seem to work. It seems like my browser (Chrome) is not sending the initial OPTIONS request. When I just updated the block for the resource I need to submit a cross-origin GET request to:

app.get "/somethingelse", (req, res) ->
  # ...
  res.header 'Access-Control-Allow-Origin', '*'
  res.header 'Access-Control-Allow-Credentials', true
  res.header 'Access-Control-Allow-Methods', 'POST, GET, PUT, DELETE, OPTIONS'
  res.header 'Access-Control-Allow-Headers', 'Content-Type'
  # ...

它有效(在Chrome中).在Safari中也可以使用.

It works (in Chrome). This also works in Safari.

我已经读过...

在实现CORS的浏览器中，每个跨域的GET或POST请求前都有一个OPTIONS请求，该请求检查GET或POST是否正常.

In a browser implementing CORS, each cross-origin GET or POST request is preceded by an OPTIONS request that checks whether the GET or POST is OK.

所以我的主要问题是，在我看来，这种情况怎么似乎没有发生?为什么不调用我的app.options块?为什么我需要在主app.get块中设置标题?

So my main question is, how come this doesn't seem to happen in my case? Why isn't my app.options block called? Why do I need to set the headers in my main app.get block?

推荐答案

要回答您的主要问题，如果POST或GET具有任何非简单的内容或标头，则CORS规范仅要求OPTIONS调用位于POST或GET之前在里面.

To answer your main question, the CORS spec only requires the OPTIONS call to precede the POST or GET if the POST or GET has any non-simple content or headers in it.

需要CORS飞行前请求(OPTIONS调用)的内容类型是任何内容类型，除了以下内容:

Content-Types that require a CORS pre-flight request (the OPTIONS call) are any Content-Type except the following:

1. application/x-www-form-urlencoded
2. multipart/form-data
3. text/plain

1. application/x-www-form-urlencoded
2. multipart/form-data
3. text/plain

除上面列出的内容类型外，任何其他内容类型都会触发飞行前请求.

Any other Content-Types apart from those listed above will trigger a pre-flight request.

对于标头，除以下内容之外的任何请求标头都会触发飞行前请求:

As for Headers, any Request Headers apart from the following will trigger a pre-flight request:

1. Accept
2. Accept-Language
3. Content-Language
4. Content-Type
5. DPR
6. Save-Data
7. Viewport-Width
8. Width

1. Accept
2. Accept-Language
3. Content-Language
4. Content-Type
5. DPR
6. Save-Data
7. Viewport-Width
8. Width

任何其他请求标头都将触发飞行前请求.

Any other Request Headers will trigger the pre-flight request.

因此，您可以添加一个自定义标头，例如:x-Trigger: CORS，它应该触发飞行前请求并点击OPTIONS块.

So, you could add a custom header such as: x-Trigger: CORS, and that should trigger the pre-flight request and hit the OPTIONS block.

请参见 MDN Web API参考-CORS预检请求

这篇关于为什么不将CORS标头添加到OPTIONS路由允许浏览器访问我的API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！