compresión HTTP

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

Los datos HTTP se comprimen antes de enviarse desde el servidor: los navegadores compatibles informarán al servidor sobre los métodos de compresión que admiten antes de descargar el formato correcto; los navegadores que no admitan métodos de compresión compatibles descargarán los 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. A un nivel inferior, un campo de encabezado Transfer-Encoding puede indicar que la carga útil de un mensaje HTTP está comprimida. A un nivel superior, un campo de encabezado Content-Encoding puede indicar que un recurso que se está transfiriendo, almacenando en caché o referenciando de otra manera está comprimido. La compresión mediante Content-Encoding es más compatible que la de Transfer-Encoding, y algunos navegadores no anuncian compatibilidad con la compresión Transfer-Encoding para evitar errores en los servidores. ^{[ 3 ]}

La negociación se realiza en dos etapas, descritas en los 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 . Para Content-Encoding , la lista está 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 admite uno o más esquemas de compresión, los datos salientes pueden comprimirse mediante uno o más métodos compatibles con ambas partes. En tal caso, el servidor añadirá un campo Content-Encoding o Transfer-Encoding en la respuesta HTTP con los esquemas utilizados, separados por comas.

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

The web server is by no means obligated to use any compression method – this depends on the internal settings of the web server and also may depend on the internal architecture of the website in question.

The official list of tokens available to servers and client is maintained by IANA,^[4] and it includes:

• br – Brotli, a compression algorithm specifically designed for HTTP content encoding, defined in RFC 7932 and implemented in all modern major browsers.
• compress – UNIX "compress" program method (historic; deprecated in most applications and replaced by gzip or deflate)
• deflate – compression based on the deflate algorithm (described in RFC 1951), a combination of the LZ77 algorithm and Huffman coding, wrapped inside the zlib data format (RFC 1950);
• exi – W3C Efficient XML Interchange
• gzip – GNU zip format (described in RFC 1952). Uses the deflate algorithm for compression, but the data format and the checksum algorithm differ from the "deflate" content-encoding. This method is the most broadly supported as of March 2011.^[5]
• identity – No transformation is used. This is the default value for content coding.
• pack200-gzip – Network Transfer Format for Java Archives^[6]
• zstd – Zstandard compression, defined in RFC 8478

In addition to these, a number of unofficial or non-standardized tokens are used in the wild by either servers or clients:

• bzip2 – compression based on the free bzip2 format, supported by lighttpd^[7]
• lzip – compression based on the free lzip format, supported by wget^[8] and Links^[9]
• lzma – compression based on (raw) LZMA is available in Opera 20, and in elinks via a compile-time option^[10]
• peerdist^[11] – Microsoft Peer Content Caching and Retrieval
• rsync^[12] – delta encoding in HTTP, implemented by a pair of rproxy proxies.
• xpress – Microsoft compression protocol used by Windows 8 and later for Windows Store application updates. LZ77-based compression optionally using a Huffman encoding.^[13]
• xz – LZMA2-based content compression, supported by a non-official Firefox patch;^[14] and fully implemented in mget since 2013-12-31.^[15]

• SAP NetWeaver
• Microsoft IIS: built-in or using third-party module
• Apache HTTP Server, via mod_deflate (despite its name, only supporting gzip^[16]), and mod_brotli
• Hiawatha HTTP server: serves pre-compressed files^[17]
• Cherokee HTTP server, On the fly gzip and deflate compressions
• Oracle iPlanet Web Server
• Zeus Web Server
• lighttpd
• nginx – built-in
• Applications based on Tornado, if "compress_response" is set to True in the application settings (for versions prior to 4.0, set "gzip" to True)
• Jetty Server – built-into default static content serving and available via servlet filter configurations
• GeoServer
• Apache Tomcat
• IBM Websphere
• AOLserver
• RubyRack, via the Rack::Deflater middleware
• HAProxy
• Varnish – built-in. Works also with ESI
• Armeria – Serving pre-compressed files^[18]
• NaviServer – built-in, dynamic and static compression
• Caddy – built-in via encode

Many content delivery networks also implement HTTP compression to improve speedy delivery of resources to end users.

The compression in HTTP can also be achieved by using the functionality of server-side scripting languages like PHP, or programming languages like Java.

Various online tools exist to verify a working implementation of HTTP compression. These online tools usually request multiple variants of a URL, each with different request headers (with varying Accept-Encoding content). HTTP compression is considered to be implemented correctly when the server returns a document in a compressed format.^[19] By comparing the sizes of the returned documents, the effective compression ratio can be calculated (even between different compression algorithms).

Un artículo de 2009 de los ingenieros de Google Arvind Jain y Jason Glasgow afirma que se pierden más de 99 años-persona diariamente ^{[ 20 ]} debido al aumento en el 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 forzarlas a no comprimirse, cuando se utilizan proxies (con navegadores web demasiado cautelosos), cuando los servidores están mal configurados y cuando los errores del navegador impiden el uso de la compresión. Internet Explorer 6, que recurre 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—  era el navegador más propenso a volver a HTTP sin comprimir. ^{[ 20 ]}

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 la implementaron como un flujo deflate "en bruto", ^{[ 21 ]} lo que hace que su implementación no sea confiable. ^{[ 22 ] [ 23 ]} Por esta razón, algunos programas, incluido el servidor HTTP Apache, solo implementan la codificación gzip .

La compresión permite realizar un ataque de texto plano elegido : si un atacante logra inyectar cualquier contenido deseado en la página, puede determinar si esta contiene dicho contenido 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, que 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 podía funcionar eficazmente contra un gran número de protocolos, incluidos TLS y protocolos de capa de aplicación como SPDY o HTTP, solo se demostraron vulnerabilidades contra TLS y SPDY, las cuales fueron mitigadas en gran medida en navegadores y servidores. La vulnerabilidad de CRIME contra la compresión HTTP no se ha mitigado en absoluto, a pesar de que sus autores advirtieron que podría ser 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 (dependiendo del número de bytes a extraer), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso. ^{[ 24 ]} Todas las versiones de TLS y SSL son vulnerables a BREACH, independientemente del algoritmo de cifrado o cifrado utilizado. ^{[ 25 ]} A diferencia de las instancias anteriores de CRIME , que se pueden contrarrestar desactivando la compresión TLS o la compresión de encabezados SPDY, BREACH explota la compresión HTTP, que no se puede desactivar de forma realista, ya que prácticamente todos los servidores web dependen de ella para mejorar la velocidad de transmisión de datos para los usuarios. ^{[ 24 ]}

A partir de 2016, el ataque TIME y el ataque HEIST son de dominio público. ^{[ 26 ] [ 27 ] [ 28 ] [ 29 ]}

• RFC 2616: Hypertext Transfer Protocol – HTTP/1.1
• RFC 9110: HTTP Semantics
• HTTP Content-Coding Values by Internet Assigned Numbers Authority
• Compression with lighttpd
• Coding Horror: HTTP Compression on IIS 6.0Archived 2014-02-06 at the Wayback Machine
• 15 Seconds: Web Site Compression at the Wayback Machine(archived July 16, 2011)
• Using HTTP CompressionArchived 2016-03-14 at the Wayback Machine by Martin Brown of Server Watch
• Using HTTP Compression in PHP
• Dynamic and static HTTP compression with Apache httpd