En elEstándar HTTP 1.1, dice que "Si no hay ningún campo de codificación de aceptación en la solicitud, el agente de usuario considera aceptable cualquier codificación de contenido".
Lo que significa que un servidor puede, por ejemplo, devolver un cuerpo de respuesta codificado en gzip si se omite el campo de codificación de aceptación.
Sin embargo, en la práctica, parece que los servidores más utilizados (por ejemplo, Apache, nginx) no harán esto y enviarán una respuesta sin comprimir si se omite el campo.
¿Es justo decir que el comportamiento más coloquial es utilizar únicamente codificaciones sugeridas explícitamente por el cliente? Esto parece un curso de acción más lógico (hacer que el cliente proporcione una lista de codificaciones que puede manejar) a pesar de ser contrario al estándar.
Respuesta1
No se supone que ninguna codificación sea aceptable incluso si no Accept-Encodingexisten encabezados. A falta de otra orientación, no molestarse en comprimir es una opción común. Guarda trabajo, permitido explícitamente por especificación.
Si la representación no tiene codificación de contenido, entonces es aceptable de forma predeterminada a menos que se excluya específicamente en el campo Aceptar codificación que indique "identidad;q=0" o "*;q=0" sin una entrada más específica para "identidad". .
O, cuando no se proporciona, Accept-Encodinguna implementación podría elegir lo que quiera mediante algún algoritmo. Saltarse la negociación de contenido tiene el ligero riesgo de que el cliente no sepa qué hacer con la codificación. Personalmente me gustaría Content-Encoding: zstdpero a partir de 2022 no es común en los agentes de usuario.