Quais headers de resposta HTTP são necessários

Quais headers de resposta HTTP precisam ser enviados do servidor para o cliente?

Eu trabalho para otimizar os headers de resposta HTTP para minimizar a sobrecarga de resposta HTTP. Eu sei que “sobrecarga” é um pouco exagerada, mas eu gosto de uma saída limpa.

Eu vejo muitos sites, que enviam headers de cache redundantes.

por exemplo

É redundante especificar Expires e Cache-Control: max-age ou especificar Last-Modified e ETag .

  • Fonte
  • HTTP / 1.1: definições de campo de header

Depende do que você define como sendo necessário: não há campos de header que devem ser enviados com cada resposta, independentemente das circunstâncias, mas há campos de header que você realmente deve enviar. O único campo de header que chega perto é Date , mas até mesmo tem circunstâncias sob as quais não é necessário.

Na linguagem do RFC 2119 , o termo deve significar que algo é um requisito da especificação e não atender ao requisito seria inválido. Não há campos de header definidos pelas RFCs 7230 , 7231 , 7232 , 7233 , 7234 ou 7235 que DEVEM ser enviados por um servidor de origem em todos os casos .


Os seguintes headers, por exemplo, podem ser omitidos (embora você provavelmente deva enviá-los):

7.1.1.2. Encontro

Um servidor de origem NÃO DEVE enviar um campo de header de Date se ele não tiver um relógio capaz de fornecer uma aproximação razoável da instância atual no Horário Universal Coordenado. Um servidor de origem pode enviar um campo de header de Date se a resposta estiver na class de códigos de status 1xx (informativa) ou 5xx (erro de servidor). Um servidor de origem deve enviar um campo de header de Date em todos os outros casos.

Observe a última frase da citação. O campo de header de Date deve ser enviado se o servidor de origem é capaz de fornecer uma “aproximação razoável” da data no UTC, mas não há nada que pare um servidor de adulterar-se.

7.4.2. Servidor

Um servidor de origem pode gerar um campo de Server em suas respostas.

3.3.2. Comprimento do conteúdo

Além de [um número finito de casos predefinidos], na ausência de Transfer-Encoding , um servidor de origem deve enviar um campo de header Content-Length quando o tamanho do corpo de payload é conhecido antes de enviar a seção de header completa.

No assunto de Content-Length e Transfer-Encoding , observe que nenhum dos dois pode ser enviado. Nesse caso, o tamanho da resposta é “determinado pelo número de octetos recebidos antes do servidor fechar a conexão”.

3.1.1.5. Tipo de conteúdo

Se um campo de header Content-Type não estiver presente, o destinatário pode assumir um tipo de mídia application/octet-stream (RFC2046, Seção 4.5.1) ou examinar os dados para determinar seu tipo.


Existem circunstâncias sob as quais headers específicos podem ser necessários, por exemplo:

  • Um servidor de origem que não suporta conexões persistentes DEVE enviar a Connection: close em cada resposta que não tenha um código de status 1xx.
  • Um servidor de origem DEVE gerar um header Allow em uma resposta 405 (Method Not Allowed).
  • Um servidor de origem que gera uma resposta 401 (não autorizada) DEVE enviar um campo de header WWW-Authenticate contendo pelo menos um desafio.

Depende das especificidades da resposta, mas geralmente, uma resposta de um servidor de origem deve ter:

  • Encontro
  • Tipo de conteúdo
  • Servidor

e Comprimento do conteúdo, Codificação de transferência ou Conexão: fechar.

Se você quiser fazer cache, adicione Cache-Control (por exemplo, com max-age); Expirações geralmente não são mais necessárias. Se você quiser que os clientes possam validar, adicione Last-Modified ou ETag.