2010-07-24 17 views
14

Estoy construyendo una aplicación AJAX que utiliza tanto el contenido HTTP como el encabezado HTTP para enviar y recibir datos. ¿Hay algún punto en el que los datos recibidos del encabezado HTTP no sean leídos por el navegador porque son demasiado grandes? En caso afirmativo, ¿cuál es el límite y es el mismo comportamiento en todo el navegador?¿Pueden los encabezados HTTP ser demasiado grandes para los navegadores?

Sé que teóricamente no hay límite para el tamaño de las cabeceras HTTP, pero en práctica lo que es el punto que más allá de eso, podría tener un problema en ciertas plataformas, navegadores o con cierto tipo de software instalado en el equipo cliente o máquina Estoy buscando más en una línea guía para la práctica segura de usar encabezados HTTP. En otras palabras, ¿hasta qué punto se pueden usar encabezados HTTP para transmitir datos adicionales sin que haya problemas potenciales en la línea?


Gracias, por toda la información sobre esta pregunta, fue muy apreciada e interesante. La respuesta de Thomas obtuvo la recompensa, pero Jon Hanna's answer trajo un muy buen punto sobre el proxy.

+1

Qué tipo de datos que está transmittin g a través de los encabezados? Si usa AJAX, ¿por qué no usa JSON o XML en lugar de poner cosas en los encabezados? – iblamefish

+0

Ha indicado en la pregunta, ya estoy usando el contenido del resultado para los datos. Los datos pasados ​​en el encabezado son datos adicionales. Para los datos enviados, son datos codificados JSON. – HoLyVieR

+0

duplicado de http://stackoverflow.com/questions/1097651/is-there-a-practical-http-header-length-limit – ankitjaininfo

Respuesta

6

En la práctica, aunque existen reglas que prohíben los proxies de no pasar ciertos encabezados (de hecho, reglas bastante claras sobre las cuales se puede modificar e incluso cómo informar a un proxy sobre si puede modificar un nuevo encabezado agregado por un estándar posterior), esto solo se aplica a los proxies "transparentes", y no todos los proxies son transparentes. En particular, algunos borran encabezados que no entienden como una práctica de seguridad deliberada.

Además, en la práctica algunos se portan mal (aunque las cosas son mucho mejores de lo que eran).

Por lo tanto, más allá de los encabezados de núcleo obvios, la cantidad de información de encabezado de la que puede depender al pasar del servidor al cliente es cero.

Esta es solo una de las razones por las que nunca debe confiar en que los encabezados se usen bien (por ejemplo, prepárese para que el cliente repita una solicitud de algo que debe haber guardado en caché o para que el servidor envíe toda la entidad cuando solicita un rango), salvo el caso obvio de los encabezados de autenticación (bajo el principio de falla de seguridad).

2

El RFC para HTTP/1.1 claramente no limita la longitud de los encabezados o el cuerpo.

De acuerdo a esta página navegadores modernos (Firefox, Safari, Opera), con la excepción de IE pueden manejar URIs muy largos: http://www.boutell.com/newfaq/misc/urllength.html. Sé que es diferente de recibir encabezados, pero al menos muestra que pueden crear y enviar enormes solicitudes HTTP (posiblemente de longitud ilimitada).

Si hay algún límite en los navegadores que sería algo así como el tamaño de la memoria o el límite de un tipo variable disponible, etc.

+1

Para todos los votantes que voten esto, tenga en cuenta que esto solo establece cuál es el protocolo, que en teoría es lo que deben manejar los navegadores, pero todos saben que la teoría a menudo no es lo mismo que la práctica. Esta no es la respuesta que estoy buscando. Esto es simplemente un sentimiento sobre cuál sería la respuesta. Quiero algo más que solo "Tengo la sensación de que sería algo así como". – HoLyVieR

+1

Estoy de acuerdo con HoLyVieR, esta no es realmente una respuesta. Es solo información relacionada. Realmente, esta no es una gran pregunta, en primer lugar, está pidiendo estadísticas que realmente no se publican porque a la gente no le importa lo suficiente. Sin embargo, para alguien que se preocupa lo suficiente, ¿qué tan difícil es escribir una aplicación AJAX que pruebe los límites de un navegador y luego ejecutar eso en varios navegadores? Los resultados serían mucho más confiables que preguntar a otros que no hayan realizado tales pruebas. –

0

En teoría, no hay límite a la cantidad de datos que se pueden enviar en el navegador. Es casi como decir que hay un límite en la cantidad de contenido que puede estar en el cuerpo de una página web.

Si es posible, intente transmitir los datos a través del cuerpo del documento. Para estar seguro, considere dividir los datos, de modo que haya múltiples pases para cargar.

4

Dos cosas.

En primer lugar, ¿por qué no ejecutar una prueba que le da al navegador cabeceras progresivamente más grandes y esperar hasta que llegue a un número que no funciona? Simplemente ejecútalo una vez en cada navegador. Esa es la manera más segura de resolver esto. Incluso si no es del todo integral, al menos tiene algunos números prácticos con los que puede hablar, y esos números probablemente cubrirán a la gran mayoría de sus usuarios.

En segundo lugar, estoy de acuerdo con que todos digan que esta es una mala idea. No debería ser difícil encontrar una solución diferente si realmente está preocupado por llegar al límite. Incluso si lo prueba en cada navegador, todavía hay firewalls, etc. de los que preocuparse, y no hay forma de que pueda probar cada combinación (y estoy casi seguro de que nadie más lo ha hecho antes) . No podrá obtener un límite estricto para cada caso.

Aunque en teoría, todo debería funcionar bien, más tarde podría haber ese caso de borde que te muerde en el trasero si decides hacerlo.

TL; DR: Esta es una mala idea. Ahórrese el problema y encuentre una solución real en lugar de una solución alternativa.


Editar: Dado que usted menciona que las peticiones pueden venir de varios tipos de fuentes, por qué no basta con especificar la fuente en el encabezado de la solicitud y tienen los datos contenidos en su totalidad en el cuerpo? Tenga algún tipo de campo Source o ClientType en el encabezado que especifica de dónde proviene la solicitud. Si proviene de un navegador, incluya el HTML en el cuerpo; si proviene de una aplicación PHP, ponga algunas cosas específicas de PHP allí; etc. Si el campo está vacío, no agregue ningún dato extra.

+1

+1 para dar el tipo de fuente o cliente. Puede usar los parámetros GET para especificar qué tipo de respuesta se debe dar. –

38

respuestas cortas:

mismo comportamiento: No se

límite Menor en los navegadores populares:

  • 10KB por cabecera
  • 256 KB para todas las cabeceras en una de las respuestas.

resultados de las pruebas de MacBook con Mac OS X 10.6.4:

respuesta más grande cargado con éxito, todos los datos en un encabezado:

  • Opera 10: 150 MB
  • Safari 5: 20 MB
  • IE 6 a través de vino: 10 MB
  • Chrome 5: 250KB
  • F irefox 3.6: 10KB

Nota Esos grandes cabeceras extravagantes en Opera, Safari e IE tomó minutos en cargar.

Nota para Chrome: El límite real parece ser de 256 KB para todo el encabezado HTTP. Aparece el mensaje de error: "Error 325 (net :: ERR_RESPONSE_HEADERS_TOO_BIG): error desconocido."

Nota para Firefox: Al enviar datos a través de múltiples cabeceras 100MB funcionó muy bien, apenas se separan más de 10'000 cabeceras

Mi conclusión:. Si quieres apoyar todos los populares navegadores de 10 KB por cada cabecera parece ser el límite y 256 KB para todas las cabeceras junto

Mi código PHP utiliza para generar esas respuestas:.

<?php 

ini_set('memory_limit', '1024M'); 
set_time_limit(90); 
$header = ""; 

$bytes = 256000; 

for($i=0;$i<$bytes;$i++) { 
    $header .= "1"; 
} 

header("MyData: ".$header); 
/* Firfox multiple headers 
for($i=1;$i<1000;$i++) { 
    header("MyData".$i.": ".$header); 
}*/ 

echo "Length of header: ".($bytes/1024).' kilobytes'; 

?> 
+0

https://cs.chromium.org/chromium/src/net/http/http_stream_parser.h?q=ERR_RESPONSE_HEADERS_TOO_BIG&sq=package:chromium&dr=C&l=159 Parece que Chrome nunca se ha ampliado. – jcolebrand

Cuestiones relacionadas