使用带有 302 重定向的 jquery 进行 ajax 请求后，Firefox 中不会调用任何回调
我有一个广泛使用 ajax 的 Rails 应用程序。使用 jQuery。例如，其中一个模型完全使用 jQuery 进行管理：记录是通过 ajaxly 创建、更新和删除的。除了更新记录之外，一切都运转良好。
我做了一些测试，我发现 Firefox 中的 jQuery（Mac 上的 3.6，Windows 上的 3.5 是我测试过的）在 302 重定向到同一 URL 时检测服务器响应时存在问题。我在 Firebug 中得到的是：
POST 本地主机：3000/resources/1 -> 302 找到
获取本地主机：3000/resources/1 -> 200 确定
并且没有调用 jQuery 的 ajax 回调。既没有成功，也没有完成，也没有错误。 但是当我创建记录并且服务器重定向到另一个 URL 时，将调用“成功”回调：
POST localhost:3000/resources -> 302 找到
获取本地主机：3000/resources/1 -> 200 确定
无论我自己调用 $.ajax 还是使用 jquery.form 的 ajaxForm() 都没有关系。
有什么想法吗？
I have a Rails application that uses ajax extensively. With jQuery. For example one of the models is entirely managed with jQuery: records are created, updated and deleted ajaxly. Evertything works great except for updating records.
I did some testing and what I figured is that jQuery in Firefox (3.6 on Mac, 3.5 on Windows is what I've tested) has problem with detecting server's response when it's 302 redirected to the same URL. What I get in Firebug is:
POST localhost:3000/resources/1 -> 302 Found
GET localhost:3000/resources/1 -> 200 OK
And no jQuery's ajax callback is called. Neither success, complete nor error.
But when I create a record and server redirects to another URL "success" callback is called:
POST localhost:3000/resources -> 302 Found
GET localhost:3000/resources/1 -> 200 OK
It doesn't matter if I call $.ajax myself or if I use jquery.form's ajaxForm().
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
301/302/303 重定向是由浏览器的 XmlHttpRequest 处理程序完成的，而不是由 jQuery 完成的。这并不能解释为什么你没有成功回调。但这可以解释为什么重定向在 ajax 端没有得到很好的测试。
一个问题是某些浏览器确实遵循 302，而不是 301 或 303 重定向。在旧应用程序中，我们使用 303 see-other 响应代码并在错误处理程序中处理它。这很好，因为我们可以执行新的 GET 请求，而不是浏览器（浏览器有问题，应该已经完成了）。
但我们遇到了问题，具体取决于浏览器（我认为，不确定）。
当我看到您的 302 响应行为时，我认为您应该执行我们所做的操作：在 ajax 请求的 post 处理后删除重定向。在响应中发送您想要的最终 HTML（这将是重定向服务器端），或者构建您自己的协议（基于 JSON？），您可以在 json 键中发送协议状态，也许还有一个要检查的新 url用于另一个键的新响应，等等。
The 301/302/303 redirect are done by the XmlHttpRequest handler of the browsers, not by jQuery. This does not explain why you do not have the success callback. But it may explain why the redirection are not well tested on ajax side.
One problem is that some browser do follow the 302, and for example not the 301 or 303 redirect. In an old application we used the 303 see-other response code and handle it in the error handler. This was nice as we could do the new GET request instead of the browser (which were buggy and should have done it).
But we had problems, depending on browsers (I think, not sure).
When I see the 302 response behaviour you have I think you should do what we've done: remove the redirect after post handling for ajax requests. Send in the response either the final HTML you want (that would be a redirect server-side), or build your own protocol (based on JSON?) where you send your protocol status in a json key, and maybe a new url to check for a new response in another key, etc.