Cneonction y nnCoection encabezados HTTP

A menudo tenemos algunos problemas en términos de interoperabilidad en la Web. Uno de estos problemas para los proveedores de navegadores es el encabezado HTTP Connection mal escrito. Los errores más comunes están dados por estas dos formas.Cneonction y nnCoection encabezados HTTP

nnCoection: 
Cneonction:

Hay ha habido algunos artículos sobre esto, incluyendo Fun with HTTP headers. A menudo sucede por período, luego desaparece. Parece que algunos de ellos son creados por equilibradores de carga como this example: NetScaler Appliance.

¿Conoces otras instancias de hardware o software que crean estos problemas?

Actualización Aquí un ejemplo, entre otros, de un sitio que no devuelve un buen encabezado HTTP Connection.

curl -sI ehg-nokiafin.hitbox.com 
HTTP/1.1 200 OK 
Date: Tue, 25 Jan 2011 20:35:45 GMT 
Server: Hitbox Gateway 9.3.6-rc1 
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP LAW NID PSA ADM OUR IND NAV COM" 
Cneonction: close 
Pragma: no-cache 
Cache-Control: max-age=0, private, proxy-revalidate 
Expires: Tue, 25 Jan 2011 20:35:46 GMT 
Content-Type: text/plain 
Content-Length: 23

actualización 2011-01-26

en el foro sobre Amazon AWS, hay una thread sobre nnCoection. Un comentario dice:

FYI, la razón por la que escribe mal la palabra conexión es para que el Internet comprobación de suma (una simple suma) todavía añade arriba, de esta manera el cambio puede ocurrir en nivel de paquete . Si fuera completamente eliminado el encabezado, tendría que dejar de reenviar la respuesta hasta el encabezado fue leído completamente, por lo que podría reescribir los encabezados, recalcular la suma de comprobación y luego enviarla.

con

sum(ord(c) for c in "Connection")

sum(ord(c) for c in "nnCoection")

tanto da 1040

Fuente

2011-01-25 karlcow

¿Estás seguro de que es un problema real ? El artículo vinculado sugiere que este tipo de encabezados están "mal escritos a propósito" para que un equilibrador de carga, proxy inverso u otro middlebox pueda vencer los deseos del servidor de que la conexión se mantenga activa, sin tener que rastrear un delta en la posición de transmisión TCP sobre el vida de la conexión. De hecho, algo como esto puede ser necesario para volver a activar un servidor caído y recuperado, forzando a las conexiones mantenidas a vivir a otros servidores a migrar a la que se puso en línea.

Si tiene un protocolo que depende de HTTP Connection: keep-alive para funcionar (cough), probablemente lo esté haciendo mal.

Fuente

2011-01-25 20:41:47

en el caso del equilibrador de carga, hay un segundo encabezado de conexión. pero hay muchos casos en que no se envía nada más. Editaré la publicación para dar un ejemplo. – karlcow

Se ve bien. Creo que están mal escritos por los equilibradores de carga TCP, por lo que a) los clientes los ignorarán yb) no tendrán que volver a calcular la suma de comprobación. Esta es una forma deliberada, aunque bastante hackosa de hacerlo. Lo he visto antes en otros casos. – MarkR

@MarkR Buen punto sobre la suma de comprobación.Ambos errores ortográficos resultan del intercambio de palabras adyacentes de 16 bits, y el que se usa es probablemente dependiente de si la C inicial cae en un límite de palabras; ya que TCP usa una suma de comprobación de complemento de las palabras de 16 bits, el intercambio de dos palabras de 16 bits no invalidará la suma de comprobación. Por otro lado, probablemente no verás esas travesuras reproducidas con HTTPS. –

Cneonction y nnCoection encabezados HTTP

Respuesta

Cuestiones relacionadas