Compresión HTTP

HTTP
Persistencia Compresión HTTPS RÁPIDO
Métodos de solicitud
OPCIONES CONSEGUIR CABEZA CORREO PONER BORRAR RASTRO CONECTAR PARCHE
Campos de encabezado
Galleta Etiqueta electrónica Ubicación Referencia HTTP No disponible X-Reenviado-Para
Códigos de estado de respuesta
301 se trasladó de forma permanente 302 encontrados 303 Ver otros 403 Prohibido 404 No encontrado 451 No disponible por razones legales
Métodos de control de acceso de seguridad
Autenticación de acceso básica Autenticación de acceso mediante resumen
Vulnerabilidades de seguridad
Inyección de encabezado HTTP Contrabando de solicitudes HTTP División de la respuesta HTTP Contaminación de parámetros HTTP
en a mi

La compresión HTTP es una capacidad que se puede incorporar en servidores web y clientes web para mejorar la velocidad de transferencia y la utilización del ancho de banda. ^[1]

Los datos HTTP se comprimen antes de ser enviados desde el servidor: los navegadores compatibles anunciarán qué métodos son compatibles al servidor antes de descargar el formato correcto; los navegadores que no admiten el método de compresión compatible descargarán datos sin comprimir. Los esquemas de compresión más comunes incluyen gzip y Brotli ; la IANA mantiene una lista completa de los esquemas disponibles . ^[2]

Existen dos formas diferentes de realizar la compresión en HTTP. En un nivel inferior, un campo de encabezado Transfer-Encoding puede indicar que la carga útil de un mensaje HTTP está comprimida. En un nivel superior, un campo de encabezado Content-Encoding puede indicar que un recurso que se está transfiriendo, almacenando en caché o al que se hace referencia de otro modo está comprimido. La compresión mediante Content-Encoding tiene un mayor soporte que la de Transfer-Encoding, y algunos navegadores no anuncian su compatibilidad con la compresión Transfer-Encoding para evitar generar errores en los servidores. ^[3]

La negociación se realiza en dos pasos, descritos en RFC 2616 y RFC 9110:

1. El cliente web anuncia qué esquemas de compresión admite incluyendo una lista de tokens en la solicitud HTTP . En el caso de Content-Encoding , la lista se encuentra en un campo llamado Accept-Encoding ; en el caso de Transfer-Encoding , el campo se llama TE .

GET  /área cifrada  HTTP / 1.1 Host :  www.example.com Aceptar codificación :  gzip, deflate

2. Si el servidor admite uno o más esquemas de compresión, los datos salientes pueden comprimirse mediante uno o más métodos admitidos por ambas partes. Si este es el caso, el servidor agregará un campo Content-Encoding o Transfer-Encoding en la respuesta HTTP con los esquemas utilizados, separados por comas.

HTTP / 1.1  200  OK Fecha :  lunes, 26 de junio de 2016 22:38:34 GMT Servidor :  Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Última modificación :  miércoles, 8 de enero de 2003 23:11:55 GMT Rangos de aceptación :  bytes Longitud del contenido :  438 Conexión :  cerrada Tipo de contenido :  text/html; charset=UTF-8 Codificación del contenido :  gzip

El servidor web no está obligado de ninguna manera a utilizar ningún método de compresión: esto depende de la configuración interna del servidor web y también puede depender de la arquitectura interna del sitio web en cuestión.

La lista oficial de tokens disponibles para servidores y clientes la mantiene la IANA, ^[4] e incluye:

• br – Brotli , un algoritmo de compresión diseñado específicamente para la codificación de contenido HTTP, definido en RFC 7932 e implementado en todos los principales navegadores modernos.
• compress – método de "compresión" de programa UNIX (histórico; obsoleto en la mayoría de las aplicaciones y reemplazado por gzip o deflate)
• deflate – compresión basada en el algoritmo deflate (descrito en RFC 1951), una combinación del algoritmo LZ77 y la codificación Huffman, envuelta dentro del formato de datos zlib ( RFC 1950);
• exi – Intercambio XML eficiente del W3C
• gzip – formato zip de GNU (descrito en RFC 1952). Utiliza el algoritmo deflate para la compresión, pero el formato de datos y el algoritmo de suma de comprobación difieren de la codificación de contenido "deflate". Este método es el más ampliamente admitido a partir de marzo de 2011. ^[5]
• identidad : no se utiliza ninguna transformación. Este es el valor predeterminado para la codificación de contenido.
• pack200-gzip – Formato de transferencia de red para archivos Java ^[6]
• zstd : compresión Zstandard, definida en RFC 8478

Además de estos, los servidores o clientes utilizan en la red una serie de tokens no oficiales o no estandarizados:

• bzip2 – compresión basada en el formato gratuito bzip2, compatible con lighttpd ^[7]
• lzma – la compresión basada en LZMA (sin procesar) está disponible en Opera 20 y en elinks a través de una opción de tiempo de compilación ^[8]
• peerdist ^[9] – Almacenamiento en caché y recuperación de contenido entre pares de Microsoft
• rsync ^[10] – codificación delta en HTTP , implementada por un par de servidores proxy rproxy .
• xpress: protocolo de compresión de Microsoft utilizado por Windows 8 y versiones posteriores para las actualizaciones de aplicaciones de la Tienda Windows. Compresión basada en LZ77 que utiliza opcionalmente una codificación Huffman. ^[11]
• xz – Compresión de contenido basada en LZMA2, compatible con un parche no oficial de Firefox; ^[12] y completamente implementada en mget desde el 31 de diciembre de 2013. ^[13]

• SAP NetWeaver
• Microsoft IIS : integrado o mediante módulo de terceros
• Servidor HTTP Apache , a través de mod_deflate (a pesar de su nombre, solo admite gzip ^[14] ) y mod_brotli
• Servidor HTTP Hiawatha : sirve archivos precomprimidos ^[15]
• Servidor HTTP Cherokee , compresiones gzip y deflate sobre la marcha
• Servidor web Oracle iPlanet
• Servidor web Zeus
• luztpd
• nginx – integrado
• Aplicaciones basadas en Tornado , si "compress_response" está configurado como Verdadero en la configuración de la aplicación (para versiones anteriores a 4.0, configure "gzip" como Verdadero)
• Jetty Server : servicio de contenido estático predeterminado integrado y disponible a través de configuraciones de filtro de servlet
• GeoServidor
• Apache Tomcat
• IBM Websphere
• Servidor AOL
• Ruby Rack , a través del middleware Rack::Deflater
• Proxy de alta disponibilidad
• Barniz incorporado. Funciona también con ESI.
• Armeria – Sirviendo archivos precomprimidos ^[16]
• NaviServer : compresión integrada, dinámica y estática
• Caddy – integrado mediante codificación

Muchas redes de distribución de contenido también implementan la compresión HTTP para mejorar la entrega rápida de recursos a los usuarios finales.

La compresión en HTTP también se puede lograr utilizando la funcionalidad de lenguajes de script del lado del servidor como PHP , o lenguajes de programación como Java .

Existen varias herramientas en línea para verificar una implementación funcional de la compresión HTTP. Estas herramientas en línea suelen solicitar múltiples variantes de una URL, cada una con diferentes encabezados de solicitud (con contenido de Accept-Encoding variable). Se considera que la compresión HTTP se implementa correctamente cuando el servidor devuelve un documento en un formato comprimido. ^[17] Al comparar los tamaños de los documentos devueltos, se puede calcular la tasa de compresión efectiva (incluso entre diferentes algoritmos de compresión).

Un artículo de 2009 de los ingenieros de Google Arvind Jain y Jason Glasgow afirma que se desperdician más de 99 años-persona ^[18] diariamente debido al aumento del tiempo de carga de las páginas cuando los usuarios no reciben contenido comprimido. Esto ocurre cuando el software antivirus interfiere con las conexiones para obligarlas a descomprimirse, cuando se utilizan servidores proxy (con navegadores web demasiado cautelosos), cuando los servidores están mal configurados y cuando los errores del navegador impiden que se utilice la compresión. Internet Explorer 6, que se reduce a HTTP 1.0 (sin funciones como compresión o canalización) cuando está detrás de un proxy (una configuración común en entornos corporativos), fue el navegador principal más propenso a volver a HTTP sin comprimir. ^[18]

Otro problema encontrado al implementar la compresión HTTP a gran escala se debe a la definición de codificación deflate : mientras que HTTP 1.1 define la codificación deflate como datos comprimidos con deflate (RFC 1951) dentro de un flujo con formato zlib (RFC 1950), los productos de servidor y cliente de Microsoft históricamente lo implementaron como un flujo deflate "sin procesar", ^[19] lo que hace que su implementación no sea confiable. ^{[20] [21]} Por esta razón, algunos programas, incluido el servidor HTTP Apache, solo implementan la codificación gzip .

La compresión permite realizar una forma de ataque de texto simple elegido : si un atacante puede inyectar cualquier contenido elegido en la página, puede saber si la página contiene el contenido dado observando el aumento de tamaño del flujo cifrado. Si el aumento es menor de lo esperado para inyecciones aleatorias, significa que el compresor ha encontrado una repetición en el texto, es decir, el contenido inyectado se superpone a la información secreta. Esta es la idea detrás de CRIME.

En 2012, se anunció un ataque general contra el uso de la compresión de datos, denominado CRIME . Si bien el ataque CRIME podría funcionar de manera efectiva contra una gran cantidad de protocolos, incluidos, entre otros, TLS y protocolos de capa de aplicación como SPDY o HTTP, solo se demostraron y mitigaron en gran medida los exploits contra TLS y SPDY en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, a pesar de que los autores de CRIME han advertido que esta vulnerabilidad podría estar incluso más extendida que la compresión SPDY y TLS combinadas.

En 2013, se publicó una nueva instancia del ataque CRIME contra la compresión HTTP, denominada BREACH. Un ataque BREACH puede extraer tokens de inicio de sesión, direcciones de correo electrónico u otra información confidencial del tráfico web cifrado con TLS en tan solo 30 segundos (según la cantidad de bytes que se extraigan), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso. ^[22] Todas las versiones de TLS y SSL están en riesgo por BREACH independientemente del algoritmo de cifrado o el cifrado utilizado. ^[23] A diferencia de las instancias anteriores de CRIME , contra las que se puede defender con éxito desactivando la compresión TLS o la compresión de encabezado SPDY, BREACH explota la compresión HTTP que no se puede desactivar de manera realista, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para los usuarios. ^[22]

A partir de 2016, el ataque TIME y el ataque HEIST son ahora de conocimiento público. ^{[24] [25] [26] [27]}

• RFC 2616: Protocolo de transferencia de hipertexto – HTTP/1.1
• RFC 9110: Semántica HTTP
• Valores de codificación de contenido HTTP por parte de la Autoridad de Números Asignados de Internet
• Compresión con lighttpd
• Horror de codificación: compresión HTTP en IIS 6.0 Archivado el 6 de febrero de 2014 en Wayback Machine
• 15 segundos: compresión de sitios web en Wayback Machine (archivado el 16 de julio de 2011)
• Uso de la compresión HTTP Archivado el 14 de marzo de 2016 en Wayback Machine por Martin Brown de Server Watch
• Uso de compresión HTTP en PHP
• Compresión HTTP dinámica y estática con Apache httpd