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.
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:
- 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). - 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.