CORS规范没有说明服务器应该如何响应无效的CORS请求。例如，如果请求Origin无效，CORS规范声明:"终止这组步骤。该请求超出了本规范的范围。"对于其他错误情况，例如请求无效的方法或头，也有类似的语言。
在CORS错误的情况下，预期的响应应该是什么?我理解不同的服务器可能需要不同的行为。但我正在寻找一个标准的响应或响应，可以接受，如果服务器所有者不关心。
是的，我意识到我在回答我自己的问题，但不管怎样，还是要这样。我对此做了一些研究，行为似乎分为两大阵营:
1)如果CORS请求无效返回错误。这是Java CORS过滤器项目采用的路由。这个库返回
- 400错误请求，不符合规范
- 403
- 405方法不允许无效方法
2)在响应中返回CORS报头，并让浏览器整理访问详细信息。这似乎是更常见的方法，Amazon S3、SoundCloud、FourSquare和Spotify的api都使用了这种方法(后两个api受益于只支持简单的CORS请求)。在这种情况下，服务器不做任何错误检查，只返回支持的源、方法和头的CORS标头。浏览器仍然发出请求，但如果CORS响应头与用户的请求不匹配，浏览器将拒绝用户的响应。
这些方法各有优缺点。方法#1更接近CORS规范，但没有向用户提供有用的调试信息。
方法#2提供了更多关于支持的方法和头文件的信息。它也更容易实现，因为无论请求头是什么，服务器都返回相同的响应头。然而，这是以在服务器端实际执行请求为代价的，即使浏览器将阻止来自用户的响应。对于具有副作用的方法，如POST、PUT或DELETE，这可能是不可取的，并且突出了CORS不应用作身份验证机制的事实。
请注意，我上面的研究绝不是详尽无遗的。很难看到许多api的真实行为，因为它们要么需要授权，要么因为其他错误(例如不支持的方法)在不同级别阻止请求。我只是想补充一下Monsur的答案。存在另一种行为(S3当前正在使用的行为):
只发送与请求的Origin匹配的CORS响应头。否则，根本不发送任何CORS头，让您的浏览器或任何其他客户端自行决定。
至少对我来说是这样的
同样，在Java中，通常发送403。这个Java链接很老了，但是Java的事实上的标准，Spring，方法是一样的。
我希望这取决于错误的性质，但我希望出现一些4xx错误，如403(如果请求不符合某些必需的标准)或404(如果方法不可用)。