对无效CORS请求的预期响应是什么?

mon*_*sur 14 cors

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

在CORS错误的情况下,预期的响应应该是什么?我知道不同的服务器可能需要不同的行为.但我正在寻找标准响应或响应,如果服务器所有者不在乎可以接受.

mon*_*sur 20

是的,我意识到我正在回答我自己的问题,但无论如何它仍然存在.我对此做了一些研究,似乎行为分为两个阵营:

1)如果CORS请求无效,则返回错误.这是Java CORS过滤器项目采用的路由.这个库返回

  • 400错误请求不符合规范的请求
  • 403禁止无效的来源或标题.
  • 405方法不允许使用无效方法

2)在响应中返回CORS头,让浏览器对访问详细信息进行排序.这似乎是更常见的方法,并且由API用于Amazon S3,SoundCloud,FourSquare和Spotify(后两个API仅受益于支持简单的CORS请求).在这种情况下,服务器不会执行任何错误检查,只返回支持的源,方法和标头的CORS标头.浏览器仍然发出请求,但如果CORS响应头与用户的请求不匹配,则浏览器会保留用户的响应.

这些方法中的每一种都有其优点和缺点.方法#1与CORS规范更紧密地对齐,但是没有向用户提供有用的调试信息.

方法#2更深入地了解支持的方法和标头是什么.它也更容易实现,因为无论请求头是什么,服务器都返回相同的响应头.然而,这是以在服务器端实际执行请求为代价的,即使浏览器将阻止来自用户的响应.对于具有副作用的方法(例如POST,PUT或DELETE),这可能不是所希望的,并且突出显示CORS不应该用作认证机制的事实.

(请注意,我上面的研究并非详尽无遗.很难看到许多API的真实行为,因为它们要么使用auth,要么在不同级别阻止请求以解决其他一些错误,例如不支持的方法.)