使用 Chrome/WebKit 调试 Access-Control-Allow-Origin
我正在尝试将 跨源资源共享 与 Access-Control-Allow-Origin 和相关标题。我可以在 Firefox 上运行，但 Chrome 给我权限错误，看起来像这样：
XMLHttpRequest cannot load <remote>. Origin <local> is not allowed by Access-Control-Allow-Origin.
网络检查器显示请求但没有响应（并且不包括 OPTIONS 预检请求和响应）。我使用curl 检查了请求输出并复制了所有标头，我所看到的内容符合规范的含义（同样，Firefox 接受的内容）。我不知道如何进一步调试它——是否有技巧可以在比 Chrome 通常提供的水平更低的水平上查看网络活动？有关 Chrome 如何与 Firefox 不同地解释 CORS 请求的信息？
I'm trying to use Cross-Origin Resource Sharing with Access-Control-Allow-Origin and related headers. I have it working on Firefox, but Chrome is giving me permission errors, that look this like:
XMLHttpRequest cannot load <remote>. Origin <local> is not allowed by Access-Control-Allow-Origin.
The network inspector shows the request but no response (and doesn't include the OPTIONS preflight request and response). I inspected the request output using curl and reproducing all the headers, and what I see fits what the specification implies (and again, what Firefox accepts). I'm at a loss how to debug this further -- are there tricks for seeing the network activity at a lower level than what Chrome normally provides? Information about how Chrome interprets CORS requests differently than Firefox?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我怀疑您所看到的是预检，然后由于错误而导致 Chrome 请求失败。这可以解释为什么在 Firefox 中可以工作，但在 Chrome 中却不行。
您是否在请求中发送任何自定义标头？ WebKit 中存在一个错误，其中带有自定义标头的 GET 请求失败（此处的错误：http ://code.google.com/p/chromium/issues/detail?id=57836）。我还注意到，Chrome 有时需要 Access-Control-Allow-Headers 列表中的 Content-Type 标头，即使 Content-Type 是一个简单的标头。
另外，您提到网络检查器不包括选项预检？您使用哪个网络检查器？我建议使用 Wireshark，因为它可以为您提供有关 Chrome 的检查器未提供的实际网络流量的详细信息（例如，Wireshark 将记录预检请求）。
其他一些调试技巧：
在 Safari 中尝试该请求。这将有助于缩小 Chrome 错误或 WebKit 错误的范围。
我多次看到您所看到的错误（Wireshark 显示请求但不显示响应），这是因为我的服务器不包含 Access-Control-Allow-Origin 标头，该标头不包含在内，因为 Chrome 不包含该标头t 发送 Origin 标头（参见上面的错误）。在网络跟踪中，您是否在请求中看到 Origin 标头？您是否可以控制服务器，如果可以，它是否会收到 Origin 标头？
如果没有更多细节，很难调试实际问题。如果您仍然遇到问题，可以在此处发布请求/响应标头吗？
I suspect what you're seeing is a preflight followed by a failing Chrome request due to a bug. That would explain why things work in Firefox but not in Chrome.
Are you sending any custom headers in your request? There's a bug in WebKit where GET requests with custom headers fails (bug here: http://code.google.com/p/chromium/issues/detail?id=57836). I've also noticed that Chrome sometimes expects the Content-Type header in the Access-Control-Allow-Headers list, even though Content-Type is a simple header.
Also, you mention that the network inspector doesn't include the OPTIONS preflight? Which network inspector are you using? I'd recommend using Wireshark, since this gives you details on the actual network traffic that Chrome's inspector doesn't provide (for example, Wireshark will log preflight requests).
Some other debugging tips:
Try the request out in Safari. This will help narrow it down to a Chrome bug or a WebKit bug.
The times I've seen the error you are seeing (Wireshark shows a request but not a response), it is because my server doesn't include the Access-Control-Allow-Origin header, which isn't included because Chrome isn't sending the Origin header (see bug above). In your network trace, do you see an Origin header in the request? Do you have control over the server, and if so, does it receive an Origin header?
Its tough to debug the actual issue without more details. If you are still having issues, can you post request/response headers here?