Codificación de transferencia: gzip frente a codificación de contenido: gzip

¿Cuál es el estado actual de las cosas cuando se trata de si hacer

Transfer-Encoding: gzip

o un

Content-Encoding: gzip

cuando quiero permitir que los clientes, por ejemplo, con un ancho de banda limitado, indiquen su voluntad de aceptar una respuesta comprimida y el servidor tenga la última palabra sobre si comprimir o no .

Esto último es lo que hacen, por ejemplo, mod_deflate e IIS de Apache, si deja que se encargue de la compresión. Dependiendo del tamaño del contenido a comprimir, hará lo adicional Transfer-Encoding: chunked.

También incluirá un Vary: Accept-Encoding, que ya insinúa el problema. Content-Encodingparece ser parte de la entidad, por lo que cambiar las Content-Encodingcantidades a un cambio de la entidad, es decir, un Accept-Encodingencabezado diferente significa, por ejemplo, que un caché no puede usar su versión en caché de la entidad por lo demás idéntica.

¿Hay una respuesta definitiva a esto que me he perdido (y que no está enterrada dentro de un mensaje en un hilo largo en algún grupo de noticias de Apache)?

Mi impresión actual es:

• Transfer-Encoding sería, de hecho, la forma correcta de hacer lo que se hace principalmente con Content-Encoding mediante implementaciones de servidor y cliente existentes
• Content-Encoding, debido a sus implicaciones semánticas, conlleva un par de problemas (¿qué debe hacer el servidor ETagcuando comprime de forma transparente una respuesta?)
• La razón es chicken'n'egg: los navegadores no lo admiten porque los servidores no lo hacen porque los navegadores no

Así que supongo que la forma correcta sería un Transfer-Encoding: gzip(o, si además trozo el cuerpo, se convertiría Transfer-Encoding: gzip, chunked ). Y no hay razón para tocar Varyo ETagcualquier otro encabezado en ese caso, ya que es una cosa a nivel de transporte.

Por ahora no me importa demasiado el 'salto a salto' Transfer-Encoding, algo que a los demás parece preocuparles en primer lugar, porque los proxies pueden descomprimir y reenviar sin comprimir al cliente. Sin embargo, los proxies podrían reenviarlo tal como está (comprimido), si la solicitud original tiene el Accept-Encodingencabezado adecuado , que en el caso de todos los navegadores que conozco es un hecho.

Por cierto, este problema tiene al menos una década, consulte, por ejemplo, https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

Se agradecerá cualquier aclaración al respecto. Tanto en términos de lo que se considera compatible con los estándares como de lo que se considera práctico. Por ejemplo, las bibliotecas cliente HTTP que solo admitan una "codificación de contenido" transparente serían un argumento en contra de la practicidad.

Citando a Roy T. Fielding , uno de los autores de RFC 2616:

cambiar la codificación de contenido sobre la marcha de manera inconsistente (ni "nunca" ni "siempre) hace que sea imposible que las solicitudes posteriores relacionadas con ese contenido (p. ej., PUT o GET condicional) se manejen correctamente. Esta es, por supuesto, la razón por la que realizar La codificación de contenido sobre la marcha es una idea estúpida, y por eso agregué Transfer-Encoding a HTTP como la forma correcta de realizar la codificación sobre la marcha sin cambiar el recurso.

Fuente: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

En otras palabras: no realice la codificación de contenido sobre la marcha , ¡use la codificación de transferencia en su lugar!

Editar: es decir, a menos que desee ofrecer contenido comprimido con gzip a clientes que solo entienden la codificación de contenido . Que, lamentablemente, parece ser la mayoría de ellos. Pero tenga en cuenta que abandona los dominios de la especificación y puede encontrarse con problemas como el mencionado por Fielding y otros, por ejemplo, cuando se trata de caché de proxies.

El uso correcto , como se define en RFC 2616 y realmente implementado en la naturaleza, es que el cliente envíe un Accept-Encodingencabezado de solicitud (el cliente puede especificar múltiples codificaciones). El servidor puede entonces, y solo entonces, codificar la respuesta de acuerdo con las codificaciones admitidas por el cliente (si los datos del archivo aún no están almacenados en esa codificación), indicar en el Content-Encodingencabezado de respuesta qué codificación se está utilizando. A continuación, el cliente puede leer los datos del socket según el Transfer-Encoding(es decir, chunked) y luego decodificarlos según el Content-Encoding(es decir:) gzip.

Entonces, en su caso, el cliente enviaría un Accept-Encoding: gzipencabezado de solicitud, y luego el servidor puede decidir comprimir (si aún no lo ha hecho) y enviar un encabezado de respuesta Content-Encoding: gzipopcional Transfer-Encoding: chunked.

Y sí, el Transfer-Encodingencabezado se puede usar en solicitudes, pero solo para HTTP 1.1, que requiere que tanto las implementaciones de cliente como de servidor admitan la chunkedcodificación en ambas direcciones.

ETagidentifica de forma única los datos de recursos en el servidor, no los datos que se transmiten realmente. Si un recurso de URL determinado cambia su ETagvalor, significa que los datos del lado del servidor para ese recurso han cambiado.