res node headers javascript http http-headers

javascript - node - return headers



Google.com y clients1.google.com/generate_204 (11)

Estuve investigando la actividad en red de google.com en Firebug solo porque tenía curiosidad y noté que una solicitud me decía "204 Sin contenido".

Resulta que un 204 Sin contenido "está pensado principalmente para permitir la entrada de acciones sin provocar un cambio en la vista del documento activo del usuario, aunque cualquier metainformación nueva o actualizada DEBERÍA aplicarse al documento actualmente en el agente activo del usuario. ver." Lo que sea.

Miré el código fuente de JS y vi que "generate_204" se solicita así:

(new Image).src="http://clients1.google.com/generate_204"

Sin declaración / asignación de variables en absoluto.

Mi primera idea es que se estaba utilizando para rastrear si Javascript está habilitado. Pero la llamada "(nueva imagen) .src = ''...''" se llama desde un archivo JS externo cargado dinámicamente de todos modos, por lo que sería inútil.

¿Alguien tiene alguna idea sobre cuál podría ser el punto?

ACTUALIZAR

"/ generate_204" parece estar disponible en muchos servicios / servidores de google (por ejemplo, maps.google.com/generate_204, maps.gstatic.com/generate_204, etc ...).

Puede aprovechar esto al precargar las páginas de generate_204 para cada servicio de propiedad de Google que pueda usar su aplicación web. Me gusta esto:

window.onload = function(){ var two_o_fours = [ // google maps domain ... "http://maps.google.com/generate_204", // google maps images domains ... "http://mt0.google.com/generate_204", "http://mt1.google.com/generate_204", "http://mt2.google.com/generate_204", "http://mt3.google.com/generate_204", // you can add your own 204 page for your subdomains too! "http://sub.domain.com/generate_204" ]; for(var i = 0, l = two_o_fours.length; i < l; ++i){ (new Image).src = two_o_fours[i]; } };


En el caso de que Chrome detecte tiempos de espera de conexión SSL, errores de certificado u otros problemas de red que puedan ser causados ​​por un portal cautivo (la red WiFi de un hotel, por ejemplo), Chrome enviará una solicitud sin cookies a http://www.gstatic.com/generate_204 y verifica el código de respuesta. Si se redirecciona esa solicitud, Chrome abrirá el objetivo de redireccionamiento en una nueva pestaña suponiendo que se trata de una página de inicio de sesión. Las solicitudes a la página de detección del portal cautivo no se registran.

Fuente: Informe técnico de privacidad de Google Chrome


A veces, 204 respuestas se usan en AJAX para rastrear los clics y la actividad de la página. En este caso, la única información que se transmite al servidor en la solicitud de obtención es una cookie y no información específica en los parámetros de solicitud, por lo que este no parece ser el caso aquí.

Parece que clients1.google.com es el servidor detrás de las sugerencias de búsqueda de Google. Cuando visita http://www.google.com , la cookie se transfiere a http://clients1.google.com/generate_204 . Tal vez esto es para iniciar algún tipo de sesión en el servidor? Cualquiera que sea el uso, dudo que sea un uso muy estándar.


Al igual que Snukker dijo, clients1.google.com es de donde provienen las sugerencias de búsqueda. Supongo que hacen una solicitud para forzar clients1.google.com a su caché de DNS antes de que lo necesite, por lo que tendrá menos latencia en la primera solicitud "real".

Google Chrome ya hace eso para cualquier enlace en una página, y (creo) cuando escribes una dirección en la barra de direcciones. Esto parece una forma de hacer que todos los navegadores hagan lo mismo.


Bueno, he estado viendo esto por algunas veces y como resultado, Google registra los comentarios de los que provienen desde la primera vez que visitan el google.com, por ejemplo; Seguir con Google Chrome tengo un 90% de conjetura de que es para los Referers de registro , tal vez las estadísticas de User-Agent son bien conocidas cuando Google lanza su lista de estándares de uso del navegador:

Encabezados de respuesta

  • Longitud del contenido: 0
  • Tipo de contenido: texto / html
  • Fecha: vie, 21 de mayo de 2010 17:06:24 GMT
  • Servidor: GFE / 2.0

Aquí " Referer " debajo de " ^ Encabezados de solicitud " muestra las estadísticas de Google que mucha gente viene de Microsoft.com , también analiza la palabra " Windows 7 " para ayudarme a enfocarme en Windows 7 en mis búsquedas posteriores en esa sesión

// Steven


El generador 204 podría estar cargando dinámicamente las sugerencias de los criterios de búsqueda. Como puedo ver en mi script de prueba de carga, esto es aparentemente responsable de cada llamada al servidor cada vez que el usuario escribe en el cuadro de texto



Encontré este hilo viejo mientras buscaba en google para generar_204, ya que Android parece usar esto para determinar si el wlan está abierto (se recibe la respuesta 204) cerrado (sin respuesta alguna) o bloqueado (el redireccionamiento al portal cautivo está presente). En ese caso, se muestra una notificación de que se requiere iniciar sesión en WiFi ...


Este documento explica:

http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1417&context=ecetr&sei-redir=1

( Buscar genera204 )

Sección relevante:

Entre los diferentes objetos, una función de JavaScript desencadena una solicitud generate204 enviada al servidor de video que se supone que sirve el video. Esto inicia la captación previa de video, que tiene dos objetivos principales: primero, obliga al cliente a realizar la resolución DNS del nombre del servidor de video. En segundo lugar, obliga al cliente a abrir una conexión TCP hacia el servidor de video. Ambos ayudan a acelerar la fase de descarga de video.

Además, la solicitud generate204 tiene exactamente el mismo formato y las mismas opciones de la solicitud de descarga de video real, por lo que el servidor de video finalmente recibe la advertencia de que un cliente posiblemente descargue ese video muy pronto. Tenga en cuenta que el servidor de video responde con una respuesta de 204 No Content , como lo implica el comando, y hasta el momento no se ha descargado ningún contenido de video.


Google está usando esto para detectar si el dispositivo está en línea o en un portal cautivo.

Shill, el administrador de conexión para Chromium OS, intenta detectar servicios que se encuentran dentro de un portal cautivo cada vez que un servicio pasa al estado listo. Esta determinación de estar en un portal cautivo o estar en línea se realiza al intentar recuperar la página web http://clients3.google.com/generate_204 . Se sabe que esta URL bien conocida devuelve una página vacía con un estado HTTP 204. Si por algún motivo no se devuelve la página web, o se recibe una respuesta HTTP distinta de 204, entonces se indica que el servicio se encuentra en el estado del portal.

Aquí está la explicación relevante del Informe de privacidad de Google Chrome :

En el caso de que Chrome detecte tiempos de espera de conexión SSL, errores de certificado u otros problemas de red que puedan ser causados ​​por un portal cautivo (la red WiFi de un hotel, por ejemplo), Chrome enviará una solicitud sin cookies a http://www.gstatic.com/generate_204 y verifica el código de respuesta. Si se redirecciona esa solicitud, Chrome abrirá el objetivo de redireccionamiento en una nueva pestaña suponiendo que se trata de una página de inicio de sesión. Las solicitudes a la página de detección del portal cautivo no se registran.

Más información: http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection


Muchas aplicaciones acceden a esta URL para determinar si tienen una conexión que solo conduce a un portal cautivo.

La idea es que cualquier portal cautivo piense que este es un sitio web "normal" y luego lo redireccione a su sitio de portal, que se devuelve con un estado 200. Si una aplicación intenta acceder a un sitio web normal, se enfrenta a una situación totalmente inesperada respuesta y puede tener problemas para descubrir lo que está mal. Sin embargo, con esta URL es fácil: si obtiene el estado 200, se encuentra dentro de un portal cautivo y puede decirle a su usuario que haga algo al respecto (generalmente inicie sesión en el portal usando un navegador o apague el WiFi y confíe en 3G, si están usando un teléfono). Si obtiene el estado 204, se conectó a Google, por lo que su aplicación está realmente conectada a Internet.

Microsoft y Apple usan un enfoque ligeramente diferente; ambos tienen algunas URL que devuelven un mensaje de texto breve muy específico con un estado 200, por lo que en lugar de acceder a la url de Google puedes ir a "captive.apple.com" y verificar el estado 200 con data = "Success" y nada más. Si obtienes el estado 200 y no exactamente esos datos, entonces estás de nuevo en un portal cautivo.


con la enorme misión de google para detener el spam y el robo de su base de datos de búsqueda, creo que esto es parte del esfuerzo por rastrear bots, etc.

un simple pseudo antibot podría ir así.

On GET (google.*) Save RemoteEndPoint { If RemoteEndPoint GETs (clients1.google.com/generate_204) Then Set botAlert_stage1 = false; Else Set botAlert_stage1 = true; End If }

También creo que el último ''tema'' de la página principal de Google también es una nueva herramienta para ayudar con la actividad antispam / bot.

** NOTA ** ipv6.google.com también incluye esta medida.

Solo mis dos sin fundamento sin blindaje 2p.