¿Qué hacer con Chrome enviando solicitudes adicionales?

Google Chrome envía varias solicitudes para recuperar una página, y eso es, aparentemente, no un error, sino una función. Y nosotros como desarrolladores solo tenemos que lidiar con eso.

Por lo que pude extraer en cinco minutos, Chrome lo hace solo para hacer que la navegación sea más rápida, así que si una conexión se pierde, la segunda se hará cargo.

Supongo que si el sitio web está bien desarrollado, entonces su funcionalidad no se romperá por esto, porque las solicitudes múltiples simplemente no son nuevas.

Pero no estoy seguro de haber contabilizado todas las situaciones que esta característica puede producir.

¿Habría alguna situación especial? ¿Alguna de las mejores prácticas para lidiar con ellos?

Actualización 1: ¡Ahora veo por qué la página de mi banco arroja un error cuando abro la página con chrome! Dice: “Solo una ventana del navegador debe estar abierta”. Esa es su solución a las amenazas de seguridad? !!

Su mejor opción es seguir las mejores prácticas de desarrollo web estándar: no cambie el estado de la aplicación como resultado de una llamada GET.

Si está preocupado, le recomiendo que actualice las pruebas de la unidad de capa de datos para que se dupliquen las llamadas GET y asegúrese de que devuelvan la misma información.

(No veo este comportamiento con Chrome 8.0.552.224, por cierto, ¿es muy nuevo?)

Vi el comportamiento sujeto mientras escribía mi aplicación de servidor y encontré que las respuestas anteriores probablemente no sean ciertas.

Chrome distribuye una única solicitud en múltiples http para buscar recursos en paralelo. En este caso, es una imagen que obtiene como un http get separado.

He adjuntado capturas de pantalla de captura de paquetes a través de wireshark.

Es para una solicitud de obtención simple al puerto 8080 para el cual mi servidor devuelve un mensaje de saludo.

Chrome envía la segunda solicitud de obtención para obtener el icono favorito que ve en la parte superior de cada pestaña abierta . NO es un segundo momento para atender el tiempo de espera ni nada por el estilo.

Debería considerarse otro elemento que difiere entre los navegadores.

Aquí hay una pregunta de referencia que encontré este último

Chrome envía dos solicitudes SO

Chrome solicita el icono favorito

Problema de Chrome en el código de google

Este comportamiento puede ser causado por SRC = ” o SRC = ‘#’ en IMG o (como en mi caso) etiqueta IFRAME. Reemplazar ‘#’ por ‘about: blank’ ha solucionado el problema.

Aquí http://forums.mozillazine.org/viewtopic.php?f=7&t=1816755 dicen que las tags SCRIPT también pueden ser el problema.

Esto solo ocurre cuando habilito la extensión “webug” (que es un reemplazo de FirePHP para Chrome). Si deshabilito la extensión, el servidor solo obtiene una solicitud.

También puede ser causado por tags de link con atributos href vacíos, al menos en Chromium (v41). Por ejemplo, cada una de las siguientes líneas generará una consulta adicional en la página:

    

Parece que buscar atributos vacíos en la página es un buen punto de partida, ya sea href o src .

Mi observación de esta característica (error / característica / lo que sea) se produce cuando estoy escribiendo en una URL y el autocompletado aterriza en una coincidencia sin dejar de escribir en la URL. Chrome toma esa coincidencia y obtiene la página, supongo que para los beneficios de almacenamiento en caché que se producirían al cargar la página usted mismo ….

Acabo de implementar un token Guid de un solo uso (asp.net/TSQL) que se genera cuando se genera el primer formulario en una serie de dos (+ página de confirmación). El token se registra como “pendiente” en el DB cuando se genera. El token Guid acompaña las publicaciones como un campo oculto, y finalmente se marca como cerrado cuando se completa la operación del usuario (pago). Este mecanismo funciona y evita que cualquiera de los formularios se vuelva a enviar después de que se realice el pago. Sin embargo, veo 2 o 3 (!?) Tokens adicionales generados por solicitudes adicionales rápidamente uno después del otro. La primera solicitud es lo que termina en frente del usuario (localhost – es decir, yo), donde el contenido generado termina por las otras dos solicitudes que no tengo idea. Inicialmente me pregunté por qué los controladores de Page_Load disparaban varias veces para una impresión de una página, así que probé una bandera en Http.Context.Current, pero me di cuenta de que las solicitudes posteriores entraban en la misma URL pero sin datos de publicación, y Vaciar Http.Context.Corrent arrays – es decir, completamente (para fines prácticos) solicitudes HTTP separadas. ¿Cómo manejar esto? ¿Algún tipo de token y lógica para rechazar solicitudes posteriores de contenido del cuerpo de la página mientras el primero aún está en proceso? ¿Supongo que esto podría tener lugar como un contexto global?

Estaba teniendo este problema, pero ninguna de las soluciones aquí era el problema. Para mí, fue causado por la extensión APNG en Chrome (soporte para PNG animados). Una vez que deshabilité esa extensión, ya no vi solicitudes dobles de imágenes en el navegador. Debo señalar que independientemente de si la página estaba generando una imagen PNG, la desactivación de esta extensión solucionó el problema (es decir, APNG parece causar el problema para las imágenes independientemente del tipo de imagen, no tienen que ser PNG).

También tuve muchas otras extensiones (como “Desarrollador web”, que muchos han sugerido que es el problema), y ese no era el problema. Deshabilitarlos no solucionó el problema. También estoy ejecutando en modo desarrollador y eso no hizo una diferencia para mí en absoluto.

Estoy teniendo el mismo error. Y al igual que la respuesta anterior, este problema se debe a que he instalado la extensión Validator Chrome. Una vez que desactivo la extensión, funciona normalmente.

En mi caso, tengo datos de enpoint (json) en un servidor diferente y el navegador realiza primero una solicitud vacía (Método de solicitud: OPTIONS) para verificar si un punto final acepta solicitudes de mi servidor, política de Mismo origen. También goot saber es una aplicación angular 1. En conclusión, realizo solicitudes de localhost a una base de datos falsos en línea.

En mi caso, fue Chrome (v65) el que hizo un segundo GET /favicon.ico , aunque la respuesta fue text/plain por lo tanto, claramente no hay ningún al referirse al ícono. Dejó de hacer eso después de que respondí con un 404.

Firefox (v59) enviaba 2 solicitudes de favicon ; nuevamente dejó de hacer esto después del 404.