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

Transfer-Encoding: gzip

o un

Content-Encoding: gzip

cuando quiero permitirclientela con por ejemplo ancho de banda limitado aSeñalar su disposición a aceptar una respuesta comprimida. y elEl servidor tiene la última palabra para comprimir o no.

Lo último es lo que p. El mod_deflate e IIS de Apache lo hacen, si dejas que se encargue de la compresión. Dependiendo del tamaño del contenido a comprimir, hará el adicionalTransfer-Encoding: chunked.

También incluirá unVary: Accept-Encoding, que ya alude al problema.Content-Encoding Parece ser parte de la entidad, por lo que cambiar laContent-Encoding equivale a un cambio de la entidad, es decir, una diferenteAccept-Encoding encabezado significa, por ejemplo, un caché no puede usar su versión en caché de la entidad de lo contrario idéntica.

¿Hay una respuesta definitiva a esta pregunta que haya omitido (y eso no está enterrado dentro de un mensaje en una larga cadena en algún grupo de noticias de apache)?

Mi impresión actual es:

La codificación de transferencia sería, de hecho, la manera correcta de hacer lo que se hace principalmente con la codificación de contenido mediante el servidor existente y las implementaciones de clientes.La codificación de contenido, debido a sus implicaciones semánticas, conlleva un par de problemas (qué debe hacer el servidor al servidor).ETag cuando 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 lo admiten

Así que estoy asumiendo que el camino correcto sería unTransfer-Encoding: gzip (O, si además partí el cuerpo,se convertiría Transfer-Encoding: gzip, chunked). Y no hay razón para tocar.Vary oETag o cualquier otro encabezado en ese caso, ya que es una cosa de nivel de transporte.

Por ahora no me importa demasiado el "salto por salto" deTransfer-Encoding, algo que a los demás parece preocuparles ante todo, ya que los proxies pueden descomprimir y enviar al cliente sin comprimir. Sin embargo, los proxies podrían reenviarlos tal como están (comprimidos), si la solicitud original tiene el valor correcto.Accept-Encoding encabezado, que en el caso de todos los navegadores que conozco es un hecho.

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

Cualquier aclaración sobre esto será apreciada. Tanto en términos de lo que se considera que cumple con las normas y lo que se considera práctico. Por ejemplo, las bibliotecas de cliente HTTP que solo admiten la "codificación de contenido" transparente serían un argumento en contra de la practicidad.