Prototype.js，AJAX表单提交偶尔返回状态0，XHR停留在readyState 1
我在 Prototype 1.7.0 和使用 form.request() 提交 AJAX 表单时遇到了一个奇怪的问题。
响应状态为 202 或 200，具体取决于服务器是否期望在超时后再次使用相同的表单提交进行轮询。 200表示响应内容已完成并将显示给用户（后端使用WebWork的execAndWait拦截器来执行长时间运行的作业）。
问题是，大多数时候，一切都运转良好。但是，偶尔，响应会以状态代码 0 和 XMLHTTPRequest readState 1 返回。Firebug 指示来自后端的正确响应代码，并且实际响应内容很好，只是 Prototype 的 on200 和 on202 处理程序没有触发（on0做）。
网上似乎也有类似的问题报道，但没有最终的解决方案。这是一些众所周知的问题吗？
I've got an odd problem here with Prototype 1.7.0 and an AJAX form submission using form.request().
The response status is either 202 or 200 depending on whether the server expects to be polled again with the same form submission after a timeout. 200 indicates that the response contents are done and are to be displayed to the user (backend uses WebWork's execAndWait-interceptor to execute a long-running job).
The problem is that most of the time, everything works just fine. However, occasionally, the response comes back as status code 0 and XMLHTTPRequest readyState 1. Firebug indicates correct response codes are coming from the backend, and that the actual response contents are fine, it's just that Prototype's on200 and on202 handlers do not fire (on0 does).
It appears there are similar issues reported over the Internet, but there is no conclusive solution. Is this some well known problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
原型的响应代码 0 意味着它无法与服务器通信。您可以通过在请求中添加“on0: function() {}”事件处理程序来解决此问题。
如何处理它取决于您...要么提醒用户出现问题，然后重新显示其表单，要么默默地尝试在循环中将您的请求重新提交到后端。如果您选择第二个选项，请设置等待超时，每次您无法与服务器通信时，请将其乘以某个因子，这样您就不会无限循环浏览器。
您可能还想考虑在客户端对这些请求进行排队，这样您一次只能按顺序触发一个请求。
希望有帮助。
A response code 0 from prototype means that it can't communicate with the server. You can remedy this by adding an "on0: function() {}" event handler in your request.
How you handle it is up to you...either alert the user that something went wrong, and redisplay their form, or silently try and re-submit your request to the backend in a loop. If you choose the second option, set a wait timeout and each time you can't talk to the server multiply it by some factor so you don't infinite loop their browser.
You might also want to look into queuing these requests on the client-side so you're only firing one at a time, in order.
Hope that helps.