ETag

Um ETag (Entity Tag) é um cabeçalho de resposta HTTP — tipicamente um hash ou carimbo de versão do corpo da resposta — que permite a um cliente revalidar um recurso em cache sem baixá-lo novamente.

Fluxo de trabalho:

1. Primeira solicitação: o servidor retorna o recurso com ETag: "abc123".
2. O cliente armazena a resposta em cache com o ETag.
3. Próxima solicitação: o cliente envia If-None-Match: "abc123".
4. O servidor compara o ETag atual com o do cliente. Se igual: 304 Not Modified com corpo vazio, o cliente usa sua cópia em cache. Se diferente: 200 OK com o novo corpo e novo ETag.

Dois tipos de ETag:

• ETags fortes — mudam se os bytes mudarem. Padrão.
• ETags fracos — prefixados com W/, podem corresponder a respostas “semanticamente equivalentes” (por exemplo, comprimida vs não comprimida do mesmo conteúdo).

ETag é um dos três mecanismos de validação de cache HTTP (ao lado de Last-Modified + If-Modified-Since, e Cache-Control max-age). Para sites estáticos modernos com URLs de ativos com hash de conteúdo, o ETag raramente é necessário — mas continua sendo o principal mecanismo para APIs dinâmicas que desejam cache no lado do cliente.

Exemplo prático

Um navegador busca /api/profile pela primeira vez. O servidor responde: HTTP/1.1 200 OK, ETag: "v42-7a8b9c", corpo = 4,2 KB de JSON. O navegador armazena ambos em cache. Na próxima carga de página, o navegador envia GET /api/profile com If-None-Match: "v42-7a8b9c". O servidor calcula o ETag atual — ainda "v42-7a8b9c" porque nada mudou — e responde HTTP/1.1 304 Not Modified com zero bytes de corpo. O navegador serve sua cópia em cache. Largura de banda economizada: 4,2 KB; latência de ida e volta ainda paga. Compare com Cache-Control: max-age=300, que pula completamente a ida e volta por 5 minutos — e você vê por que ETag é a segunda melhor estratégia de cache: confirma a atualidade quando a desatualização deve ser evitada, mas na verdade não salva a ida e volta de rede. Sites estáticos modernos preferem URLs com hash + max-age distante e ignoram ETag completamente.

Quando e por que isso importa

ETag importa para dois fluxos de trabalho distintos: revalidação de cache (economizando largura de banda quando as respostas são grandes e inalteradas) e controle de concorrência otimista (evitando bugs de atualização perdida em APIs REST). O erro a evitar no cache é gerar um ETag fraco a partir de um timestamp que inclui precisão sub-segundo — cada servidor em um cluster de balanceamento de carga calcula um valor diferente para o mesmo recurso, e os clientes constantemente invalidam. Use um hash de conteúdo estável (SHA-256 do corpo, frequentemente truncado para 16 caracteres) para que todas as réplicas produzam o mesmo ETag. O erro a evitar na concorrência é falhar ao validar If-Match no lado do servidor — muitos desenvolvedores adicionam o cabeçalho nas gravações, mas o servidor o ignora, deixando a condição de corrida sem solução. AWS S3, Google Cloud Storage e a API do Stripe aplicam concorrência baseada em ETag estritamente; seguir o padrão deles é o design de referência mais seguro. Referência: MDN — Cabeçalho HTTP ETag.

Controle de concorrência otimista — o segundo papel do ETag: ETag também é o mecanismo padrão para “não sobrescreva meus dados se outra pessoa os alterou”. O cliente faz GET no recurso, captura o ETag, faz edições, então envia PUT com If-Match: "abc123". Se o recurso no lado do servidor mudou desde então (ETag diferente), o servidor retorna 412 Precondition Failed e o cliente sabe que deve atualizar e refundir. AWS S3, Google Cloud Storage e a maioria das APIs REST que suportam edições simultâneas usam exatamente esse padrão. O mecanismo é anterior ao bloqueio pessimista de aplicações web e é mais escalável porque nenhum estado de bloqueio no lado do servidor é necessário.

A preocupação com privacidade dos ETags: servidores podem usar valores de ETag únicos por usuário (essencialmente um cookie emitido pelo servidor incorporado nos metadados de cache) para rastrear usuários que retornam sem definir um cookie real — o chamado “ETag cookie” ou “supercookie”. Mesmo após o usuário limpar os cookies, o navegador ainda envia o ETag de volta na próxima solicitação, identificando-o. Os navegadores agora particionam os caches HTTP por site de nível superior (Chrome 86, Firefox 85) para neutralizar esse ataque, mas a técnica permanece como uma nota de rodapé de privacidade conhecida no design de cache HTTP. Referência: RFC 9110 §8.8.3 — ETag.