NoPadrão HTTP 1.1, diz que "Se nenhum campo Accept-Encoding estiver na solicitação, qualquer codificação de conteúdo será considerada aceitável pelo agente do usuário."
O que significa que um servidor pode, por exemplo, retornar um corpo de resposta codificado em gzip se o campo de codificação de aceitação for omitido.
Na prática, entretanto, parece que os servidores mais comumente usados (por exemplo, Apache, nginx) não farão isso e enviarão uma resposta descompactada se o campo for omitido.
É justo dizer que o comportamento mais coloquial é usar apenas codificações explicitamente sugeridas pelo cliente? Este parece ser um curso de ação mais lógico - fazer com que o cliente forneça uma lista de codificações que ele pode manipular - apesar de ser contrário ao padrão.
Responder1
Nenhuma codificação é considerada aceitável, mesmo que não Accept-Encodingexistam cabeçalhos. Na falta de qualquer outra orientação, não se preocupar em comprimir é uma escolha comum. Economiza trabalho, explicitamente permitido pelas especificações.
Se a representação não tiver codificação de conteúdo, ela será aceitável por padrão, a menos que seja especificamente excluída pelo campo Accept-Encoding informando "identity;q=0" ou "*;q=0" sem uma entrada mais específica para "identity" .
Ou, quando não for fornecida, Accept-Encodinguma implementação poderá escolher o que quiser por meio de algum algoritmo. Ignorar a negociação de conteúdo apresenta o pequeno risco de o cliente não saber o que fazer com a codificação. Pessoalmente, gostaria, Content-Encoding: zstdmas a partir de 2022 não é comum em agentes de usuário.