Compresión HTTP

En la mayoría de los casos, excluyendo SDCH, la negociación se hace en dos etapas, como se describe en RFC 2616:

1. El cliente web anuncia qué esquemas de compresión soporta incluyendo una lista de tokens en el HTTP request. Para Content-Encoding, la lista en un campo llamado Accept-Encoding; para Transfer-Encoding, el campo se llama TE.

GET /encrypted-area HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, deflate

2. Si el servidor soporta uno o más esquemas de compresión, los datos salientes pueden ir comprimidos de una o más formas soportados 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 usados, separados por comas.

HTTP/1.1 200 OK
Date: mon, 6 ago 2023 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

El servidor web no está para nada obligado a usar algún método de compresión - esto depende de la configuración del servidor web y también puede depender en la arquitectura interna del sitio web en cuestión.

En el caso de SDCH, se requiere una negociación de diccionario adicional, lo que puede involucrar pasos adicionales, como descargar un diccionario apropiado desde el servidor externo.

La lista oficial de tokens disponible para servidores y clientes es mantenida por IANA,[4] e incluye:

• compress - método del programa UNIX "compress" (histórico; obsoleto en la mayoría de aplicaciones y sustituido por gzip o deflate)
• deflate - compresión basada en el algoritmo deflate (descrito en RFC 1951), envuelto en el interior del formato de datos zlib (RFC 1950);
• exi - Intercambio Eficiente de XML de W3C
• gzip - formato zip GNU (que se describe en el RFC 1952). Este método es el de más amplio soporte a marzo de 2011.[5]
• identity - 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]

Además de éstos, un número de tokens no oficiales o no normalizados se utilizan libremente tanto por servidores o clientes:

• bzip2 - compresión basada en el formato libre bzip2, soportado por [lighttpd][7]
• LZMA - compresión basada en (cruda) LZMA está disponible en Opera 20, y en elinks a través de una opción en tiempo de compilación[8]
• peerdist[9] - caché y Recuperación de contenido entre pares de Microsoft
• SDCH[10][11] - Google compresión de HTTP por diccionario compartido, basado en VCDIFF (RFC 3284); soportado en forma nativa en las últimas versiones de Google Chrome, Chromium y Android, así como en los sitios web de Google.
• xz - compresión basada en LZMA2 contenido, soportada con un parche no oficial de Firefox;[12] y aplicado plenamente en mget desde 2013-12-31.[13]

• SAP NetWeaver
• Microsoft IIS: incorporado o utilizando un módulo de terceros.
• Apache HTTP Server, vía mod_deflate (a pesar de su nombre, solo soporta gzip[14])
• Hiawatha HTTP server: entrega archivos pre-comprimidos[15]
• Cherokee HTTP server, comprime gzip y deflate en línea
• Oracle iPlanet Web Server
• Zeus Web Server
• lighttpd, via mod_compress y el más nuevo mod_deflate (1.5.x)
• nginx – incorporado
• Las aplicaciones basadas en Tornado, si se fija "compress_response" en Verdadero (True) en la configuración (para versiones previas a 4.0, poner "gzip" en verdadero)
• Jetty Server – incorporado en proveerr contenido estático por omisión y disponible vía configuraciones de filtros de servlets
• GeoServer
• Apache Tomcat
• IBM Websphere
• AOLserver
• Ruby Rack, a través del middleware Rack::Deflater

La compresión en HTTP puede lograrse también usando la funcionalidad de lenguajes de Script del lado del servidor como PHP, o lenguajes de programación como Java.

Un artículo de 2009 por Arvind Jain y Jason Glasgow, ingenieros de Google, afirma que más de 99 personas-año se desperdician[16] diariamente debido al mayor tiempo de carga de las páginas cuando los usuarios no reciben contenido comprimido. Esto ocurre cuando el software antivirus interfiere con conexiones para obligarlas a ir sin compresión, donde se usan proxies (con navegadores demasiado reticentes), donde los servidores están mal configurados, y donde los errores del navegador impiden usar compresión. Internet Explorer 6, que cae a HTTP 1.0 (sin funciones como la compresión o la canalización) cuando está detrás de un proxy - una configuración común en entornos corporativos - era el navegador dominante más propensos a bajar a HTTP sin comprimir.[16]

Otro problema encontrado durante la implementación de la compresión HTTP en gran escala es debido a la definición de codificación de deflate: mientras HTTP 1.1 define la codificación de deflate como datos comprimidos con deflate (RFC 1951) dentro de una corriente de zlib formateado (RFC 1950), los productos de servidor y cliente de Microsoft históricamente lo implementaron como una corriente desinflado "en bruto",[17] lo que hace su implementación no fiable.[18][19] Por esta razón, algunos programas, incluyendo el Apache HTTP Server, sólo implementan la codificación gzip.

En 2012, se anunció un ataque general contra el uso de la compresión de datos, llamado CRIME. Si bien el ataque CRIME podría trabajar eficazmente contra un gran número de protocolos, incluyendo pero no limitado a TLS, y protocolos de capa de aplicación, tales como SPDY o HTTP, sólo exploits contra TLS y SPDY fueron demostrados y en gran medida mitigados en los 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 ser aún más extendida que la compresión combinada de SPDY y TLS.

En 2013, fue publicado una nueva instancia del ataque CRIME contra la compresión HTTP, llamado BREACH. Un ataque BREACH puede extraer tokens de acceso, direcciones de correo electrónico u otra información sensible desde tráfico web encriptado con TLS en tan sólo 30 segundos (dependiendo del número de bytes a ser extraídos), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso.[20] Todas las versiones de TLS y SSL están en riesgo de BREACH independientemente del algoritmo de encriptación o cifrado utilizado.[21] A diferencia de los casos anteriores de CRIME, que se pueden defender con éxito apagando la compresión TLS o compresión de cabecera SPDY, los BREACH explotan la compresión HTTP la cual no puede ser apagada realmente, ya que prácticamente todos los servidores web se basan en ella para mejorar las velocidades de transmisión de datos para los usuarios.[20]