O Que Há Dentro de uma Resposta HTTP?

Mar 12, 2026 · 4 min read

Toda vez que seu navegador carrega uma página ou seu JavaScript chama fetch(), um servidor envia de volta uma resposta HTTP. Você vê o resultado — uma página renderizada, alguns dados JSON, uma mensagem de erro — mas a resposta em si contém mais estrutura do que a maioria dos desenvolvedores conscientemente pensa. Compreender essa estrutura lhe dá um modelo mental mais claro ao depurar no DevTools ou manipular respostas em código.

Uma resposta HTTP tem três partes: uma linha de status, cabeçalhos e um corpo opcional.

Pontos-Chave

Toda resposta HTTP consiste em três partes: uma linha de status (ou pseudo-cabeçalho :status no HTTP/2 e HTTP/3), cabeçalhos e um corpo opcional.
Os códigos de status são agrupados pelo primeiro dígito — 2xx para sucesso, 3xx para redirecionamento, 4xx para erros do cliente e 5xx para erros do servidor.
Os cabeçalhos de resposta controlam cache, segurança, cookies e interpretação de conteúdo — eles dizem ao navegador como manipular a carga útil, não apenas o que ela é.
Nem todos os cabeçalhos de resposta são acessíveis ao JavaScript frontend em requisições cross-origin. Os servidores devem usar Access-Control-Expose-Headers para permitir acesso além do conjunto padrão seguro.

A Anatomia de uma Resposta HTTP: Status, Cabeçalhos, Corpo

A Linha de Status

No HTTP/1.1, a resposta começa com uma única linha de status:

HTTP/1.1 200 OK

Esta linha contém a versão do protocolo, um código de status de três dígitos e uma frase de razão legível por humanos. A frase de razão é apenas informativa — o código de status é o que os navegadores e clientes realmente utilizam.

Os códigos de status HTTP são agrupados pelo primeiro dígito:

Faixa	Significado
1xx	Informacional (requisição recebida, processamento continua)
2xx	Sucesso (200 OK, 201 Created, 204 No Content)
3xx	Redirecionamento (301 Moved Permanently, 304 Not Modified)
4xx	Erro do cliente (400 Bad Request, 401 Unauthorized, 404 Not Found)
5xx	Erro do servidor (500 Internal Server Error, 503 Service Unavailable)

Uma observação sobre HTTP/2 e HTTP/3: A linha de status textual acima é específica do formato de transmissão HTTP/1.1. No HTTP/2 e HTTP/3, não há linha de status. Em vez disso, o status é transmitido através de um pseudo-cabeçalho :status (por exemplo, :status: 200). A semântica é idêntica — o código de status significa a mesma coisa — mas a representação difere. O DevTools normaliza a representação, então você ainda verá o código de status familiar independentemente da versão do protocolo.

Cabeçalhos de Resposta HTTP: O Que Eles Realmente Fazem

Os cabeçalhos de resposta são metadados. Eles dizem ao navegador como manipular a resposta, não o que o conteúdo é. Cada cabeçalho é um nome que não diferencia maiúsculas de minúsculas seguido por dois pontos e um valor.

Aqui estão as categorias que você encontrará com mais frequência:

Metadados de conteúdo

Content-Type: application/json; charset=utf-8 — informa ao navegador em qual formato o corpo está e como decodificá-lo.
Content-Length: 1024 — o tamanho do corpo em bytes.

Cache

Cache-Control: max-age=3600, public — instrui o navegador e CDNs por quanto tempo armazenar em cache a resposta.
ETag: "abc123" — uma impressão digital do recurso, usada para requisições condicionais. Se o recurso não mudou, o servidor retorna 304 Not Modified em vez do corpo completo.

Segurança

Content-Security-Policy — restringe de quais fontes o navegador pode carregar scripts, estilos e outros recursos.
Strict-Transport-Security — informa ao navegador para conectar apenas via HTTPS por uma duração especificada.

Cookies

Set-Cookie: session=xyz; HttpOnly; Secure — instrui o navegador a armazenar um cookie. Uma única resposta pode incluir múltiplos cabeçalhos Set-Cookie, um por cookie.

Uma restrição importante: nem todos os cabeçalhos de resposta são acessíveis ao JavaScript frontend. Por padrão, a Fetch API expõe apenas um pequeno conjunto de cabeçalhos “seguros” de respostas cross-origin. Os servidores devem listar explicitamente cabeçalhos adicionais em Access-Control-Expose-Headers para que seu JavaScript possa lê-los.

O Corpo da Resposta

O corpo é a carga útil real — HTML, JSON, uma imagem, um arquivo. Nem toda resposta tem um. Uma resposta 204 No Content ou 304 Not Modified intencionalmente omite o corpo. Nesses casos, o próprio código de status é a mensagem.

O cabeçalho Content-Type informa ao navegador como interpretar o que chega no corpo.

Recursos Menos Comuns que Vale a Pena Conhecer

As respostas HTTP também podem incluir respostas informacionais como 103 Early Hints, que permite aos servidores sugerir recursos para pré-carregar antes da resposta principal chegar. Trailers — cabeçalhos enviados após o corpo — existem no HTTP/1.1 (com codificação de transferência fragmentada) e no HTTP/2 e HTTP/3 como cabeçalhos finais, mas são raramente encontrados no trabalho frontend cotidiano. Vale a pena conhecê-los, mas você não os verá frequentemente no DevTools.

Conclusão

Pense em uma resposta HTTP como um envelope. O código de status informa se a entrega foi bem-sucedida. Os cabeçalhos são instruções do lado de fora — manuseie com cuidado, refrigere após abrir, expira em 24 horas. O corpo é o que está dentro. Quando algo quebra, verifique o código de status primeiro, depois os cabeçalhos — eles geralmente dizem exatamente o que deu errado e o que fazer em seguida.

Perguntas Frequentes

Content-Length especifica o tamanho exato do corpo da resposta em bytes. Transfer-Encoding, tipicamente definido como chunked, significa que o corpo é enviado em pedaços sem um tamanho total predeterminado. No HTTP/1.1 uma resposta usa um ou outro. A codificação fragmentada é comum para conteúdo gerado dinamicamente onde o servidor não conhece o tamanho final antecipadamente.

Para requisições cross-origin, a Fetch API expõe apenas um conjunto limitado de cabeçalhos de resposta seguros para CORS por padrão. Estes incluem Cache-Control, Content-Language, Content-Type, Expires, Last-Modified e Pragma. Para acessar qualquer outro cabeçalho do JavaScript, o servidor deve incluí-lo no cabeçalho de resposta Access-Control-Expose-Headers.

Use 204 No Content quando o servidor processar com sucesso uma requisição mas não tiver corpo para retornar. Isso é comum para operações DELETE ou envios de formulários onde o cliente não precisa de dados atualizados em resposta. Um 200 OK é mais apropriado quando você quer enviar uma carga útil de confirmação ou recurso atualizado de volta ao cliente.

Abra o DevTools com F12 ou Ctrl+Shift+I, vá para a aba Network e clique em qualquer requisição na lista. O painel Headers mostra tanto os cabeçalhos de requisição quanto de resposta. Você também pode filtrar por tipo de requisição e pesquisar por nomes específicos de cabeçalhos. A aba Response mostra o conteúdo bruto do corpo retornado pelo servidor.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.