http - funciona - ¿Por qué el navegador no puede enviar una solicitud de gzip?

request connection close (6)

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

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 se pensó casi con certeza para tener siempre pequeñas solicitudes y respuestas potencialmente grandes. La compresión no es necesaria para implementar HTTP, existen servidores y clientes que no la admiten.

La compresión HTTP es implementada por el cliente diciendo que puede admitir la compresión, y si el servidor ve esto en la solicitud y admite compresión, puede comprimir la respuesta. Para comprimir la solicitud, el cliente tendría que tener una "pre-solicitud" que realmente negociara que la solicitud se haría comprimida O tendría que requerir compresión como una codificación soportada para TODAS las solicitudes.

* ACTUALIZACIÓN Feb ''17 * Han pasado 8 años, pero como señala @ Phil_1984_ notas, una tercera solución posible sería que el cliente y el servidor negociaran soporte de compresión y luego lo utilizaran para solicitudes posteriores. De hecho, cosas como HSTS funcionan de esta manera con el almacenamiento en memoria caché del cliente que el servidor espera solo hablar TLS e ignorar cualquier enlace no encriptado. HTTP fue diseñado explícitamente para ser apátrida, pero hemos ido más allá en este punto.

HTTP está diseñado de esta manera:

El cliente dice su solicitud en texto sin formato (incluso si puede comprender las respuestas comprimidas)
Las respuestas del servidor 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á con anticipación.

Podría, siempre que pueda garantizar que el servidor lo acepte. Esto podría significar el uso de 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 una gran cantidad de diferentes servidores web y configuraciones. Hacer un cambio en la forma en que un cliente trabaja podría romper algunos de ellos.

Quizás solo el 1% de los servidores acepte solicitudes gzip, pero tal vez algunos de ellos anuncien que lo hacen, pero no pueden aceptarlo correctamente, por lo que se les negará a los usuarios la carga de archivos a esos sitios.

Históricamente ha habido una gran cantidad de implementaciones de cliente / servidor rotas: durante mucho tiempo, las respuestas gzip se rompieron en los principales navegadores web (afortunadamente ya no se usan).

Así que terminarías con listas negras de agentes de usuario o servidores (o nombres de dominio) donde esas opciones se desactivaron automáticamente, lo que es desagradable.

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

Si está escribiendo una aplicación web, asumo que tiene el control de lo que se envía al cliente y de lo que envía 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 como normal, por ejemplo request.getParameter ( ...).

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

Andy.

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