CORS规范没有说明服务器应如何响应无效的CORS请求。例如，如果请求Origin无效，则CORS spec states：“终止这组步骤。请求超出了本规范的范围。”其他错误情况也有类似的语言，例如请求无效的方法或标头。
在CORS错误的情况下，预期的响应应该是什么？我知道不同的服务器可能需要不同的行为。但我正在寻找标准响应或响应，如果服务器所有者不在乎可以接受。
是的，我意识到我正在回答我自己的问题，但无论如何它仍然存在。我对此做了一些研究，似乎行为分为两个阵营：
1）如果CORS请求无效，则返回错误。这是Java CORS filter项目采取的路线。这个库返回
2）在响应中返回CORS头，让浏览器对访问详细信息进行排序。这似乎是更常见的方法，并且由API用于Amazon S3，SoundCloud，FourSquare和Spotify（后两种API仅受益于支持简单的CORS请求）。在这种情况下，服务器不会执行任何错误检查，只返回支持的源，方法和标头的CORS标头。浏览器仍然发出请求，但如果CORS响应头与用户的请求不匹配，则浏览器会保留用户的响应。
这些方法中的每一种都有其优点和缺点。方法＃1与CORS规范更紧密地对齐，但是没有向用户提供有用的调试信息。
方法＃2更深入地了解支持的方法和标头是什么。它也更容易实现，因为无论请求头是什么，服务器都返回相同的响应头。然而，这是以在服务器端实际执行请求为代价的，即使浏览器将阻止来自用户的响应。对于具有副作用的方法（例如POST，PUT或DELETE），这可能不是所希望的，并且突出显示CORS不应该用作认证机制的事实。
（请注意，我上面的研究并非详尽无遗。很难看到许多API的真实行为，因为它们要么使用auth，要么在不同级别阻止请求以解决其他一些错误，例如不支持的方法。）
我希望它将取决于错误的性质，但我希望有一些4xx错误，如403（如果请求未通过某些必需的标准）或404（如果方法不可用）。
我只想补充一下Monsur的答案。还有另一种行为（S3当前正在使用的行为）：
至少这是它对我有用的方式。
此外，当谈到Java时，发送403是很常见的。那个Java链接已经很老了，但Java，Spring中的事实标准是相同的。请参阅我的参考here。