¿Por qué el navegador no puede enviar la solicitud de gzip?

Question

Si el servidor web puede enviar una respuesta de gzip, ¿por qué el navegador no puede enviar la solicitud de gzip?

Answer 1

El cliente y el servidor tienen que ponerse de acuerdo sobre cómo comunicarse; parte de esto es si la comunicación puede ser comprimida. HTTP se diseñó como un modelo de solicitud / respuesta, y la creación original fue probablemente concebida para tener siempre pequeñas solicitudes y respuestas potencialmente grandes. La compresión no es necesaria para implementar HTTP, hay servidores y clientes que no lo admiten.

El cliente implementa la compresión HTTP diciendo que puede admitir la compresión, y si el servidor ve esto en la solicitud y es compatible con la compresión, puede comprimir la respuesta. Para comprimir la solicitud, el cliente debería tener una " solicitud previa " que realmente negoció que la solicitud se realizaría comprimida O tendría que requerir compresión como una codificación compatible para TODAS las solicitudes.

* ACTUALIZACIÓN Feb '17 * Han pasado 8 años, pero como observa @ Phil_1984_, una tercera solución posible sería que el cliente y el servidor negocien el soporte de compresión y luego lo utilicen para las solicitudes posteriores. De hecho, cosas como HSTS funcionan de esta manera con el almacenamiento en caché del cliente que el servidor espera que solo hable TLS e ignore los enlaces no cifrados. HTTP fue diseñado explícitamente para ser sin estado, pero hemos avanzado más allá de eso en este punto.

Answer 2

Un cliente no puede saber de antemano que un servidor entendería una solicitud gzipped, pero el servidor puede saber que el cliente aceptará una.

Answer 3

Podría, siempre que pueda garantizar que el servidor lo acepte. Esto podría significar utilizar una solicitud de OPCIONES.

Hay muchas cosas que los navegadores web podrían hacer (por ejemplo, canalización) que no hacen. Los desarrolladores de navegadores web consideran las implicaciones de compatibilidad de un cambio.

En un entorno heterogéneo, hay muchos servidores y configuraciones web diferentes. Hacer un cambio en la forma en que funciona un cliente podría romper algunos de ellos.

Es posible que solo el 1% de los servidores acepte solicitudes comprimidas con gzip, pero tal vez algunos de ellos anuncien que sí, pero no pueden aceptarlo correctamente, por lo que a los usuarios no se les permite subir archivos a esos sitios.

Históricamente, ha habido muchas implementaciones de cliente / servidor rotas: durante mucho tiempo, las respuestas de gzipped se rompieron en los principales navegadores web (afortunadamente, ahora casi no existen).

Por lo tanto, terminarás con listas negras de agentes de usuario o servidores (o nombres de dominio) donde esas opciones se desactivaron automáticamente, lo cual es desagradable.

Answer 4

Porque no sabe que el servidor puede aceptarlo. Una transacción HTTP tiene una sola solicitud enviada por el cliente seguida de una respuesta. Una de las cosas que el cliente envía es qué codificación / compresión puede soportar. El servidor puede entonces decidir cómo comprimir la respuesta. El cliente no tiene este lujo.

Answer 5

Si está escribiendo una aplicación web, asumo que usted tiene el control de lo que se envía al cliente y lo que se envía desde el cliente.

Sería bastante fácil escribir una implementación de gzip en javascript, que comprime los datos de la publicación que se envían al servidor. El servidor podría tener un filtro (término j2ee), que sabe que los datos del cliente se envían comprimidos, este filtro descomprime los datos y luego pasa los datos al servlet (o clases de acción en Struts) que leen los datos normalmente, por ejemplo. request.getParameter (...).

Esto parece perfectamente lógico y factible si tienes el control. Como mencionan otras publicaciones, no puedes confiar en el navegador para hacer esto automáticamente, pero como estás escribiendo las páginas web, puedes hacer que el navegador realice la compresión que buscas (con un poco de trabajo).

Andy.

Answer 6

HTTP está diseñado de esta manera:

• El cliente responde a su solicitud en texto sin formato (incluso si puede comprender las respuestas comprimidas)
• El servidor responde con la codificación adecuada (comprimida o no)

PERO EN ESTE DISEÑO, el cliente no puede enviar solicitudes comprimidas porque no sabe si el servidor lo entenderá de antemano.