根据CORS规范（7.1.7 - 重定向步骤（简单的跨源请求））：
- 如果请求URL源与原始URL源不同，请将源origin设置为全局唯一标识符（变为＆＃34; null＆＃34;传输时）。
我有一个场景，来自a.blah.com的javascript通过向b.blah.com发送一个CORS请求（即Origin请求头），b.blah.com以302和location = c.blah.com进行响应。如果我正确地阅读规范，这应该导致对c.blah.com的请求包含Origin header =＆＃34; null＆＃34;。相反，Origin头不存在，因此对c.blah.com的请求不被视为CORS请求。
Chrome 54中遇到了上述行为。我还没有确认其他浏览器中的确切请求内容，但我检查过我的特定应用程序流程在Chrome 54，Firefox 37和IE 11浏览器中有效，这意味着它们从不请参见Origin标头设置为＆＃34; null＆＃34; （如果收到Origin =＆＃34; null＆＃34;），我的服务将大声失败请求。
这一切让我担心，因为虽然我的应用程序正在运行，但它实际上不应该，并且我不想忽略这一事实。我误解了规格吗？对于我错过的规范行为有什么警告吗？
所有流量都是HTTPS，而不是在CORS响应头中返回*（通配符），在适当的情况下使用-credentials标志/标头设置，不使用代理，所有演员都在不同的机器上，所以不应该是localhost gotcha ... < / p>
感谢。
答案 0 :(得分：2)
在我的原始配置中，对b.blah.com的请求是由js（不是xhr）发布的表单。经过一番挖掘之后，似乎由于请求是由js触发的，因此在b.blah.com的请求中保证了一个Origin头，但是导致c.blah.com的重定向是由浏览器处理的，没有任何脚本/ xhr干预，因此重定向没有用Origin标头装饰。
我设置了一个测试，其中对b.blah.com的请求是xhr，这确实导致在重定向到c.blah.com时出现Origin =“null”。
我想我需要更好地研究何时实施同源政策的细微差别。
感谢。