¿Es posible habilitar la compresión http para solicitudes?


35

Veo mucha información sobre cómo habilitar la compresión http para las respuestas del servidor, pero qué pasa con las solicitudes entrantes. ¿No tendría sentido para los navegadores comprimir publicaciones de gran formato antes de enviarlas al servidor?

Otro ejemplo es un servicio web REST que utilizamos. Tenemos que enviar solicitudes PUT frecuentes con archivos XML grandes (más de 10 MB) y definitivamente veríamos algunos beneficios de ancho de banda / velocidad en ambos lados.

Entonces, ¿es este un problema resuelto en el lado del servidor o cada aplicación web tiene que manejarlo individualmente?

Respuestas:


30

Para PUTdatos comprimidos en el servidor, debe comprimir el cuerpo de la solicitud y establecer el Content-Encoding: gzipencabezado. El encabezado en sí debe estar sin comprimir. Está documentado en mod_deflate :

El módulo mod_deflate también proporciona un filtro para descomprimir un cuerpo de solicitud comprimido gzip. Para activar esta función, debe insertar el filtro DEFLATE en la cadena de filtro de entrada utilizando SetInputFilter o AddInputFilter.

...

Ahora, si una solicitud contiene una codificación de contenido: encabezado gzip, el cuerpo se descomprimirá automáticamente. Pocos navegadores tienen la capacidad de comprimir cuerpos de solicitud. Sin embargo, algunas aplicaciones especiales realmente admiten la compresión de solicitudes, por ejemplo, algunos clientes de WebDAV.

Y un artículo que lo describe está aquí :

Entonces, ¿cómo lo haces? Aquí hay una propaganda, nuevamente desde el código fuente mod_deflate: solo funciona en la solicitud principal / sin subrequests. Esto significa que todo el cuerpo de la solicitud debe estar comprimido con gzip si elegimos usar esto, no es posible comprimir solo la parte que contiene el archivo, por ejemplo, en una solicitud de varias partes.

Por separado, un navegador puede solicitar que el contenido de la respuesta del servidor se comprima configurando el Accept-Encodingencabezado como aquí :

GET /index.html HTTP/1.1
Host: www.http-compression.com
Accept-Encoding: gzip
User-Agent: Firefox/1.0

Esto devolverá datos comprimidos al navegador.


55
+1 NB Escribes you must compress the whole request, inclusive of header. Sin embargo, los encabezados http no deben comprimirse . Lo único que debe comprimirse (en su totalidad, como dice correctamente el artículo), es el cuerpo http.
Eugene Beresovsky

1
Esto está mal: Accept-Encodingle dice al servidor, qué compresión admite el cliente. El encabezado Content-Encodingdescribe la compresión del cuerpo.
maaartinus

@maaartinus ver primera cita segundo párrafo. He reorganizado la respuesta para mayor claridad.
Andy

4

Responder a la parte sobre solicitudes comprimidas, no respuestas: sí, es posible, incluso si no parece que su uso sea generalizado. La aplicación del lado del cliente debe establecer el encabezado de codificación de contenido apropiado. En cuanto a la aplicación del lado del servidor, hay 2 opciones:

  1. la aplicación admite reinflatar el cuerpo de la solicitud por sí mismo. Una biblioteca de ejemplo que puede hacer esto es la phpxmlrpc.

  2. el servidor web infla el cuerpo de respuesta antes de pasarlo a la aplicación. Esto es posible usando el filtro mod_deflate de Apache y configurando un inputFilter


2

No de forma nativa de ningún navegador que conozca, tendrías que encontrar un complemento que lo hiciera por ti. Básicamente, debe configurar el encabezado HTTP de codificación de contenido para que el servidor sepa cómo llega la solicitud. El servidor, por supuesto, debe ser capaz de manejar esa codificación.


0

Esto no esta permitido. De acuerdo con la especificación HTTP ( RFC 2616 ), Content-EncodingNO es uno de los posibles campos de encabezado de solicitud, por lo tanto, no es posible comprimir el cuerpo de la entidad de solicitud ya que no hay una forma legal de informar al servidor que esto ha ocurrido. Cualquier compresión del cuerpo de la solicitud se realiza solo como una extensión no estándar.


12
Esta respuesta es incorrecta RFC 2616 menciona específicamente que If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type)., además, indicado por Request and Response messages MAY transfer an entity if not otherwise restricted by the request methody Content-Encodingestá listado como una opción enentity-header
PeterT
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.