Accept-Encoding
Uso
La cabecera de solicitud HTTP Accept-Encoding forma parte del proceso de negociación de contenido y especifica qué métodos de codificación admite el cliente. El servidor elegirá uno de los métodos disponibles y después informará al cliente de la selección incluyendo la cabecera Content-Encoding en la respuesta HTTP.
Nota
En algunos casos, incluso cuando el cliente y el servidor admiten los mismos métodos de codificación, no se manipula el recurso original antes de enviarlo. Esto ocurre en situaciones en las que el valor identity del recurso también resulta aceptable. Un ejemplo común es cuando los datos ya están comprimidos y aplicar un algoritmo de compresión adicional no reducirá más el tamaño. Esto sucede con archivos de imagen precomprimidos, como JPEG. Otra situación es aquella en la que el servidor está muy cargado y no puede dedicar los recursos necesarios para manipular los datos antes de la transmisión.
Para especificar varias codificaciones se usan cabeceras HTTP Accept-Encoding separadas o, en su lugar, una lista separada por comas. También se incluye el factor q para indicar una preferencia o prioridad.
Impacto en SEO
Los rastreadores y recuperadores de Google admiten las codificaciones de contenido gzip, deflate y Brotli (br). Cada agente de usuario de Google anuncia las codificaciones admitidas en la cabecera Accept-Encoding de cada solicitud, normalmente como Accept-Encoding: gzip, deflate, br. Servir respuestas comprimidas a Googlebot reduce el ancho de banda y el tiempo de rastreo. Bingbot envía Accept-Encoding: gzip, deflate.
gzip
La directiva gzip indica que el cliente admite la compresión GNU zip. Es la codificación con mayor soporte en la web.
deflate
La directiva deflate indica que el cliente admite la compresión zlib. A pesar del nombre, utiliza un envoltorio zlib alrededor de los datos comprimidos DEFLATE en bruto.
br
La directiva br indica que el cliente admite la compresión Brotli. Para contenido basado en texto, Brotli suele alcanzar mejores relaciones de compresión que gzip.
zstd
La directiva zstd indica que el cliente admite la compresión Zstandard. Zstandard ofrece relaciones de compresión altas con velocidades de descompresión rápidas.
identity
La directiva identity indica que no se aplica ninguna codificación. Este valor se considera siempre aceptable salvo que se excluya explícitamente con identity;q=0.
* (comodín)
El comodín * coincide con cualquier codificación que no esté ya listada en la cabecera. Si no hay ninguna cabecera Accept-Encoding, el servidor trata la solicitud como si se hubiera especificado *.
;q= (valores de calidad)
El parámetro ;q= asigna a cada codificación un peso entre 0 y 1, donde 1 es la máxima prioridad y 0 significa “no aceptable”. Cuando se omite, el valor de calidad predeterminado es 1. El servidor usa estos pesos para seleccionar la codificación preferida.
Ejemplo
En este ejemplo, el cliente pide al servidor que utilice uno de varios métodos de codificación. En la primera variante, cada una de las opciones recibe la misma prioridad. En la segunda variante, se usa la directiva de valor q para asignar peso a la prioridad de las codificaciones. El servidor responde con la lista de codificaciones aplicadas, ordenadas según se procesaron.
Solicitud (variante n.º 1)
GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *Solicitud (variante n.º 2)
GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br;q=1.0, identity;q=0.5, *;q=0.25Respuesta
HTTP/1.1 200 OK
Content-Encoding: gzip, brDiagnóstico
No se aplica compresión a pesar de Accept-Encoding. Algunos proxies inversos eliminan Accept-Encoding de la solicitud antes de reenviarla. En nginx, proxy_set_header Accept-Encoding $http_accept_encoding conserva el valor original. Verifíquelo con curl -H “Accept-Encoding: gzip” -I.
Se seleccionó una codificación inesperada. Los valores de calidad (factores q) controlan el orden de preferencia. Una solicitud con Accept-Encoding: gzip;q=0.5, br;q=1.0 prefiere Brotli. Omitir los valores q asigna el mismo peso y el servidor elige libremente.
La comprobación previa CORS no incluye Accept-Encoding. La cabecera Accept-Encoding está en la lista segura de CORS y no desencadena una comprobación previa. Si la compresión deja de funcionar en las solicitudes de origen cruzado, compruebe que el servidor aplica la compresión con independencia de la cabecera Origin.
La CDN sirve respuestas sin comprimir. Algunas CDN comprimen solo cuando el origen envía una respuesta sin comprimir con un Content-Type adecuado. Verifique que el origen responde con Vary: Accept-Encoding para que la CDN almacene en caché las variantes comprimidas y sin comprimir por separado.
La codificación identity es rechazada. Enviar Accept-Encoding: identity;q=0 indica al servidor que el cliente no puede aceptar respuestas sin comprimir. Si no hay disponible ninguna codificación admitida, el servidor devuelve 406 Not Acceptable. Evite establecer identity en q=0 salvo que se garantice la disponibilidad de todas las codificaciones listadas.