2011-09-04 24 views
55

¿Cuánto tiempo puede esperar el navegador antes de que se muestre un error antes de que el servidor responda para solicitarlo? ¿Puede ser este tiempo ilimitado?¿Cuánto tiempo esperará el navegador después de una solicitud de Ajax?

+2

No está seguro de lo que está utilizando, pero sí se puede extender el tiempo de espera. Para infinito, no sé. Aunque recomendaría no hacer un tiempo ilimitado. Si lo necesita, siempre puede configurarlo en algo así como 90 segundos o un poco más. Sin embargo, si lleva más de 30 segundos, probablemente haya una manera mejor y más rápida de hacer algo. – Matt

+1

+1 - También tengo curiosidad sobre esto. Sospeché que debe preocuparse de que el cliente le pase el tiempo. Usted no tiene control sobre esto. Una búsqueda en google apareció esto. Básicamente dice que el servidor o el navegador pueden exceder el tiempo de espera. Así que elegiría algo que el valor predeterminado para todos los navegadores no excederá. http://support.microsoft.com/kb/813827 – mrtsherman

+0

Al eliminar errores, una vez salí a almorzar después de la llamada ajax y volví al navegador esperando la respuesta. Hice clic en ir a mi depurador y el navegador recogió la respuesta. No creo que esto cuente, porque estaba depurando –

Respuesta

62

Si está utilizando una llamada jQuery $ .ajax, puede configurar la propiedad de tiempo de espera para controlar la cantidad de tiempo antes de que una solicitud regrese con un estado de tiempo de espera excedido. El tiempo de espera se establece en milisegundos, así que simplemente configúrelo a un valor muy alto. También puede establecerlo en 0 para "ilimitado", pero en mi opinión, debe establecer un valor alto en su lugar.

Nota: ilimitado es actually the default pero la mayoría de los navegadores tienen tiempos de espera predeterminados que se verán afectados.

Cuando se devuelve una llamada ajax debido al tiempo de espera, se devolverá con un estado de error de "tiempo de espera" que puede manejar con un caso separado si es necesario.

Así que si desea establecer un tiempo de espera de 3 segundos, y manejar el tiempo de espera aquí es un ejemplo:

$.ajax({ 
    url: "/your_ajax_method/", 
    type: "GET", 
    dataType: "json", 
    timeout: 3000, //Set your timeout value in milliseconds or 0 for unlimited 
    success: function(response) { alert(response); }, 
    error: function(jqXHR, textStatus, errorThrown) { 
     if(textStatus==="timeout") { 
      alert("Call has timed out"); //Handle the timeout 
     } else { 
      alert("Another error was returned"); //Handle other error type 
     } 
    } 
});​ 
+5

Al establecer el valor 'timeout' en' 0' se establece el tiempo de espera AJAX en un período indefinido (lea ilimitado). – John

+0

@John o incluso no lo configura en absoluto (leer 0 es el valor predeterminado). –

+0

Recibo un "error" en textStatus no como "timeout" – UmaShankar

3

¿Puede explicar un poco más sobre lo que está tratando de lograr? ¿Tiene un largo proceso en un servidor, desea cambiar la configuración en una máquina local o está buscando una forma de administrarlo? para un gran número de usuarios?

El tiempo que esperará el navegador depende de una serie de factores, p. donde ocurre el tiempo de espera - ¿está en el nivel TCP, el servidor o el navegador local?

Si tiene un proceso de larga ejecución en un servidor y desea actualizar una página web posteriormente, la forma más habitual de manejarlo es ejecutar el proceso largo de forma asíncrona y notificar al cliente cuando esté completo, p. tener una llamada ajax que sondee el servidor, o use HTTP 1.1 y envíe un flujo de notificación al cliente.

En cualquier caso, aún es posible que la conexión se cierre, por lo que el cliente aún necesitará la posibilidad de volver a abrirla.

14

Sí y no. Sí, el servidor puede hacerlo o estar configurado para hacerlo, no los navegadores (no sé sobre los detalles de la versión/distribuidor) pueden tener habilitados los tiempos de espera.

Hay 2 soluciones, aunque para lograr/emulando este a través de HTTP:

  • Si esto es simple un script de larga ejecución y que está a la espera de los resultados de este no es el camino a seguir, que hagan lo mismo que en vez se mencionó el cartel anterior y se usa el procesamiento asincrónico con el sondeo del servidor para los resultados, esta sería una solución de fuego mucho más segura. Por ejemplo: una secuencia de comandos en miniatura desde el lado del servidor del procesador de imágenes: el usuario carga una imagen, el servidor devuelve un 200 y una "ID de trabajo". El cliente (javascript ^^) puede usar el ID de tarea para solicitar el estado/resultado del trabajo.
  • Si su objetivo es tener algo así como una conexión en tiempo real entre el navegador y el servidor (conexión de 1 vía, una vez que el navegador realiza la solicitud no se puede enviar más información sin utilizar nuevas solicitudes (ajax ^^)), esto es llamado interrogación larga/reverse ajax y se puede usar para comunicación en tiempo real a través de http. Existen varias técnicas que utilizan 2 solicitudes largas sondeadas en paralelo, de modo que una vez que una de ellas agota el tiempo de espera, la segunda se activa y la primera intenta volver a conectarse.
+1

Gran respuesta, gracias –

2

Encontré que, en el caso de una solicitud normal (página HTML), los navegadores ejecutan el tiempo de espera después de cca. 30 segundos Es importante, porque otros participantes probablemente lo sigan: proxies, enrutadores (¿los enrutadores juegan en este juego? No estoy seguro). Estoy usando 4 segundos retraso largo del servidor (si no hay nada que enviar al cliente), y mi cliente AJAX realiza otra solicitud HTTP de inmediato (estoy en la red local, no hay retraso de Internet). 4 segundos es lo suficientemente largo como para no sobrecargar el servidor y la red con encuestas frecuentes, y es lo suficientemente corto para el caso, cuando de alguna manera una encuesta cae fuera de la fila que el cliente no puede detectar y manejar. También hay otros problemas con el cometa (solicitud HTTP larga): límite del número de solicitudes HTTP simultáneas, manejo de eventos del lado del cliente (debe enviarse al servidor de inmediato), detección y recuperación de servidores/redes inactivas , manejo multiusuario, etc.

Cuestiones relacionadas