ajax请求后浏览器会等待多长时间?
在服务器响应请求之前,浏览器可以等待多长时间才能显示错误?这个时间可以无限吗?
How long can the browser wait before an error is shown before server answers for request? Can this time be unlimited?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
如果您使用 jQuery $.ajax 调用,您可以设置 timeout 属性来控制请求返回并显示超时状态之前的时间量。超时以毫秒为单位设置,因此只需将其设置为非常高的值即可。您也可以将其设置为 0 表示“无限制”,但在我看来,您应该设置一个较高的值。
注意:无限制实际上是默认值,但大多数浏览器都有默认超时会被击中。
当 ajax 调用由于超时而返回时,它将返回“超时”错误状态,如果需要,您可以使用单独的情况进行处理。
所以如果你想设置3秒的超时,并处理超时这里是一个例子:
If you are using a jQuery $.ajax call you can set the timeout property to control the amount of time before a request returns with a timeout status. The timeout is set in milliseconds, so just set it to a very high value. You can also set it to 0 for "unlimited" but in my opinion you should just set a high value instead.
Note: unlimited is actually the default but most browsers have default timeouts that will be hit.
When an ajax call is returned due to timeout it will return with an error status of "timeout" that you can handle with a separate case if needed.
So if you want to set a timeout of 3 seconds, and handle the timeout here is an example:
是和不是。是的,服务器可以这样做或配置为这样做,浏览器(我不知道版本/发行商的具体情况)可能启用了超时。
不过,有两种解决方案可以通过 HTTP 实现/模拟这一点:
Yes and no. Yes the server can do it or be configured to do so, no the browsers (i dont know about version/distributor specifics) may have timeouts enabled.
There are 2 solutions though for achieving/emulating this over HTTP:
您能否详细解释一下您想要实现的目标 - 您在服务器上是否有一个长时间运行的进程,您是否只想更改本地计算机上的设置,或者您是否正在寻求一种管理大量数据的方法用户数?
浏览器等待的时间取决于多种因素,例如超时发生的位置 - 是在 TCP 级别、服务器还是本地浏览器?
如果服务器上有一个长时间运行的进程,并且您想随后更新网页,处理它的典型方法是异步运行长时间进程并在完成时通知客户端,例如使用 ajax 调用来轮询服务器,或者使用 HTTP 1.1 并向客户端提供通知流。
在任何一种情况下,连接仍然有可能被关闭,因此客户端仍然需要能够重新打开它。
Can you explain a bit more about what you're trying to achieve - do you have a long running process on a server, do you want to change the settings on just a local machine or are you after a way to manage it for large numbers of users?
How long the browser will wait depends on a number of factors e.g. where the timeout occurs - is it at the TCP level, the server or the local browser?
If you've got a long running process on a server and you want to update a webpage afterwards the typical way to handle it is to run the long process asynchronously and notify the client when it's complete e.g. have an ajax call that polls the server, or use HTTP 1.1 and serve out a notification stream to the client.
In either case it's still possible for the connection to be closed so the client will still need the ability to re-open it.
我发现,在正常(HTML 页面)请求的情况下,浏览器会在 cca 之后运行超时。 30秒。这很重要,因为其他参与者可能会遵循它:代理、路由器(路由器在这个游戏中玩吗?我不确定)。我使用 4 秒 长服务器端延迟(如果没有任何内容可发送到客户端),并且我的 AJAX 客户端立即执行另一个 HTTP 请求(我在本地网络上,没有互联网延迟)。 4 秒足够长,不会因频繁的轮询而使服务器和网络超载,并且对于当某个轮询以某种方式超出客户端无法检测和处理的行时的情况来说,4 秒足够短。
此外,comet(长 HTTP 请求)还存在其他问题:浏览器对同时 HTTP 请求数量的限制、客户端事件的处理(必须立即发送到服务器)、服务器/网络故障检测和恢复、多用户处理ETC。
I found, that in case of a normal (HTML page) request, browsers run to timeout after cca. 30 secs. It's important, because other participiants probably follows it: proxies, routers (do routers play in this game? I'm not sure). I am using 4 sec long server-side delay (if there's nothing to send to the client), and my AJAX client performs another HTTP request immediatelly (I am on local network, there's no internet lag). 4 sec is long enough to not to overload the server and network with frequented polls, and is short enough for the case, when somehow one poll falls out of the row which the client can't detect and handle.
Also, there're other issues with comet (long HTTP request): browser's limit on number of simultaneous HTTP request, handling of client-side events (must sent to the server immediatelly), server/network down detection and recovery, multi user handling etc.