REQUISIÇÃO · RESPOSTA · REPRESENTAÇÃO

A anatomia de uma mensagem HTTP

Método e alvo expressam a intenção do cliente. Status expressa o resultado. Campos acrescentam contexto; o conteúdo carrega uma representação opcional. Essa semântica permanece mesmo quando HTTP/2 e HTTP/3 usam frames binários.

Imagem: Kim Scarborough / Wikimedia Commons, CC BY-SA 2.0

QUATRO PARTES

Leia a mensagem de cima para baixo: intenção, contexto, separação e conteúdo.

Em HTTP/1.1, a representação textual torna a anatomia visível. A requisição começa com método e alvo; a resposta começa com status. Depois vêm os campos, uma linha vazia e, quando permitido e necessário, o conteúdo.

Laboratório visual · Requisição e resposta lado a lado

Destaque uma parte e compare sua função nas duas mensagens.

anatomia HTTP
Seu navegador não suporta canvas.

Linha inicial: o pedido identifica método e alvo; a resposta informa versão e status.

Linha inicialRequest line: método, request target e versão. Status line: versão, status code e reason phrase opcional na representação HTTP/1.1.
CamposMetadados e instruções em nomes e valores: tipo, preferências, autenticação, cache, tamanho, origem e muito mais.
Linha vaziaNa sintaxe textual do HTTP/1.1, marca o fim da seção de campos. Não é um detalhe decorativo.
ConteúdoSequência opcional de bytes associada à mensagem. “Body” é o termo comum; a semântica atual das RFCs usa “content”.

O CLIENTE EXPRESSA UMA INTENÇÃO

Método + alvo identificam o que o cliente quer fazer e onde.

Requisição HTTP/1.1cliente → servidor
POST /pedidos?notificar=true HTTP/1.1
Host: api.exemplo.com
Content-Type: application/json; charset=utf-8
Accept: application/json
Authorization: Bearer •••
Content-Length: 36

{"produtoId":42,"quantidade":2}
  1. POST: o método define a semântica geral — submeter conteúdo para processamento pelo recurso.
  2. /pedidos?notificar=true: o alvo combina caminho e query. O caminho identifica o recurso; a query acrescenta parâmetros definidos pela aplicação.
  3. Host: identifica a autoridade desejada, permitindo vários sites no mesmo endereço.
  4. Content-Type: descreve a mídia do conteúdo enviado; neste caso, JSON em UTF-8.
  5. Accept: informa quais tipos de representação o cliente prefere receber.
  6. Authorization: carrega credenciais do esquema escolhido. HTTPS protege o header em trânsito; logs ainda precisam evitar expô-lo.
URL e request target não são exatamente a mesma escrita. O usuário vê uma URL completa; no HTTP/1.1 para uma origem, a linha normalmente leva caminho e query, enquanto esquema e autoridade são representados pelo contexto e por Host. Em HTTP/2 e HTTP/3, pseudo-headers codificam esses componentes.

O SERVIDOR EXPRESSA UM RESULTADO

Status, campos e conteúdo contam histórias diferentes.

Resposta HTTP/1.1servidor → cliente
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Location: /pedidos/981
Cache-Control: no-store
Content-Length: 26

{"id":981,"status":"novo"}
201 CREATED

Resultado

A requisição criou um novo recurso. O status comunica a classe e o resultado principal sem obrigar a interpretar o body.

LOCATION

Referência

Indica o URI do recurso criado. Não é automaticamente uma ordem de redirecionamento neste status.

JSON

Representação

O conteúdo mostra dados úteis ao cliente. Outro cliente poderia negociar uma representação diferente do mesmo recurso.

CONTEÚDO NÃO É DELIMITADO POR “ATÉ FECHAR” SEMPRE

O receptor precisa saber quantos bytes pertencem à mensagem.

Em HTTP/1.1, regras de framing determinam o limite: Content-Length, codificação de transferência chunked em situações permitidas, semântica do método/status ou fechamento da conexão em casos específicos. Interpretar limites de forma divergente é também um problema de segurança.

SituaçãoHá conteúdo?Como pensar
GET bem-sucedidoNormalmente sim.A representação pode ser HTML, JSON, imagem ou bytes de outro tipo.
HEADNão há conteúdo de resposta.Os campos descrevem o que um GET correspondente teria, sem transferir a representação.
204 No ContentNão.O status declara ausência de conteúdo; não se deve anexar JSON vazio por hábito.
304 Not ModifiedNão.O cliente reutiliza uma representação armazenada após revalidação.
POST com JSONPode ter.Content-Type explica o formato; o método, sozinho, não define JSON.
Framing ambíguo pode causar request smuggling. Proxies e servidores precisam concordar sobre onde uma mensagem termina e a próxima começa. Não aceite combinações inválidas ou contraditórias de delimitadores.

SEMÂNTICA ESTÁVEL, REPRESENTAÇÃO DIFERENTE

HTTP/2 e HTTP/3 não enviam estas linhas literalmente.

A forma textual é excelente para aprender a semântica e observar HTTP/1.1. Nas versões modernas, campos e conteúdo são codificados em frames e streams. O significado de método, alvo, status e headers continua existindo.

AspectoHTTP/1.1HTTP/2HTTP/3
Representação no fioLinhas e bytes de conteúdo.Frames binários em streams.Frames binários em streams QUIC.
Linha inicialVisível como texto.Pseudo-headers como :method, :path e :status.Pseudo-headers equivalentes.
CamposNome e valor textuais.Comprimidos com HPACK.Comprimidos com QPACK.
MultiplexaçãoNão nativa na mesma conexão.Vários streams sobre TCP.Vários streams independentes sobre QUIC.

DevTools, proxies e bibliotecas apresentam uma visão reconstruída e amigável da mensagem. Por isso você continuará vendo “Request Method”, “Status Code” e headers mesmo quando nenhum bloco textual idêntico atravessou a rede.

PARE E PENSE

Uma resposta informa Content-Type: application/json, mas envia HTML. O cliente deve confiar na extensão da URL ou no header?

Separe nome do recurso, metadado da representação e bytes realmente recebidos.

A resposta está inconsistente. Content-Type declara o tipo da representação e deve corresponder aos bytes. A extensão da URL não define o tipo em HTTP. O cliente pode falhar ao interpretar, aplicar tratamento defensivo ou bloquear em certos contextos; a correção pertence ao servidor.

CONTINUE EXPLORANDO

Referências e itens adicionais de estudo

Referências técnicas

Documentos normativos para semântica e codificação.

Itens adicionais de estudo

Exercícios de leitura de mensagens.

  • Execute curl.exe -v https://example.com e separe o que é diagnóstico do curl do que é HTTP.
  • Use curl.exe -I e explique por que HEAD pode mostrar Content-Length sem baixar o conteúdo.
  • No DevTools, compare document, stylesheet, image e fetch por método, tipo e initiator.
  • Transforme a requisição desta aula em pseudo-headers HTTP/2.
  • Pesquise Problem Details (RFC 9457) e modele um erro JSON interoperável.