Software · Infraestrutura & Sistemas

HTTP na Prática: Semântica de Métodos, Cache Headers, Cookies e CORS

Guia prático sobre o funcionamento real do HTTP: semântica dos verbos, Cache-Control, ETag, atributos de cookies para segurança e resolução de preflight de CORS.

Diagrama conceitual ilustrando http na prática: semântica de métodos, cache headers, cookies e cors
Neste artigo

A web moderna depende de contratos bem definidos no protocolo HTTP. Frequentemente, equipes tratam requisições como canais opacos de dados, ignorando convenções de semântica, validações de cache e políticas do navegador, o que gera gargalos de escala e vulnerabilidades severas de segurança.

sequenceDiagram
  autonumber
  participant Browser as Navegador Cliente
  participant CDN as CDN / Proxy Cache
  participant API as Backend API

  Note over Browser,API: Ciclo com ETag e Revalidação Condicional
  Browser->>CDN: GET /api/v1/produtos/100
  CDN->>API: GET /api/v1/produtos/100
  API-->>CDN: 200 OK (ETag: "w/33a28f", Cache-Control: max-age=60, must-revalidate)
  CDN-->>Browser: 200 OK (com corpo JSON e headers)

  Note over Browser: Passados 70 segundos (cache local expirado)
  Browser->>CDN: GET /api/v1/produtos/100 (If-None-Match: "w/33a28f")
  CDN->>API: GET /api/v1/produtos/100 (If-None-Match: "w/33a28f")
  API-->>CDN: 304 Not Modified (Sem corpo - payload zero)
  CDN-->>Browser: 304 Not Modified (Navegador reutiliza dados do cache local)

Métodos: Segurança e Idempotência

Dois conceitos definem a semântica dos verbos HTTP na RFC 9110:

  1. Seguro (Safe): O método não altera o estado observável do servidor. Chamadas de leitura podem ser cacheadas sem riscos colaterais (GET, HEAD, OPTIONS).
  2. Idempotente (Idempotent): Executar a mesma requisição uma vez ou dez vezes consecutivas com os mesmos parâmetros produz exatamente o mesmo estado final no servidor (PUT, DELETE, GET).

O método POST não é nem seguro nem idempotente. Duas requisições POST /pedidos debitam duas cobranças distintas caso a aplicação não implemente chaves de idempotência (Idempotency-Key).

Cabeçalhos de Cache: Max-Age, Stale-While-Revalidate e ETag

O cabeçalho Cache-Control direciona navegadores e proxies intermediários sobre a durabilidade dos dados:

  • no-store: Proíbe qualquer armazenamento em disco ou memória por navegadores e CDNs. Usado para dados sensíveis, tokens e extratos bancários.
  • no-cache: Permite armazenar a resposta, mas exige revalidar com o servidor de origem antes de exibi-la.
  • public, max-age=3600, stale-while-revalidate=86400: A resposta é válida por uma hora. Se expirada, a CDN entrega o dado antigo imediatamente enquanto atualiza a cópia em segundo plano.
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: public, max-age=300, must-revalidate
ETag: "8f14e45fceea167a5a36dedd4bea2543"
Vary: Accept-Encoding, Authorization

Anatomia dos Cookies de Sessão

Cookies armazenam credenciais ou identificadores de sessão com flags obrigatórias de proteção:

  • HttpOnly: Impede acesso ao cookie via JavaScript (document.cookie), mitigando roubo de sessão através de ataques Cross-Site Scripting (XSS).
  • Secure: Garante que o cookie trafegue exclusivamente por conexões TLS/HTTPS.
  • SameSite=Strict: Bloqueia o envio do cookie em requisições de origem externa, prevenindo ataques Cross-Site Request Forgery (CSRF).

CORS e o Mecanismo de Preflight

O mecanismo de Cross-Origin Resource Sharing (CORS) é implementado pelo navegador, e não pela API. Se uma página em https://app.empresa.com dispara um fetch para https://api.empresa.com, o navegador envia previamente uma requisição OPTIONS (preflight) validando se o servidor autoriza aquela origem, método e cabeçalhos customizados antes de liberar o envio do payload real.

Explorar este tema no Grafo de Conhecimento