APRENDER. PRATICAR. EVOLUIR.O validador precisa de uma representação
Um ETag é opaco: o cliente não precisa de o interpretar como número, data ou checksum. Guarda-o associado ao recurso, à variante e ao corpo obtido. Num job de relatórios, conservar a tabela de ETags e apagar os ficheiros quebra essa associação. A resposta 304 seguinte não entrega um novo corpo que possa substituir o perdido. Antes de publicar o resultado, confirma que a representação correspondente ainda existe e satisfaz os critérios funcionais. Caso contrário, recupera-a por uma leitura sem aquele validador.
Escolher a comparação conforme a intenção
Com ETag "v1", um GET com If-None-Match: W/"v1" pode obter 304 porque este campo usa comparação fraca. O mesmo texto fraco em If-Match não satisfaz a comparação forte necessária à proteção da escrita. No laboratório, o PUT com W/"v1" recebe 412 e o estado continua em alpha. Não retires simplesmente W/ para inventar uma garantia mais forte. Obtém um validador adequado segundo o contrato e confirma como a API avalia a condição antes de aplicar alterações.
Reconciliar é diferente de trocar um cabeçalho
Ana e Bruno leem a mesma versão de configuração. Ana publica uma alteração e o servidor passa de v1 para v2. Bruno tenta substituir o corpo a partir de v1; o fixture rejeita com 412. A recuperação exige ler v2, comparar a intenção de ambos e construir uma proposta coerente. Copiar o novo ETag para o corpo antigo pode eliminar o erro visível e perder o trabalho de Ana. Num comité de mudança, identifica quem decide conflitos de conteúdo e quem aprova adiar uma alteração.
Existência, versão e precondição exigida
Distingue três contratos. If-Match com um ETag explícito testa a versão selecionada; If-Match: * exige existência, sem proteger a versão exata lida. If-None-Match: * num PUT pode exprimir criação apenas quando ainda não existe representação. Um servidor pode responder 428 se o contrato exigir uma precondição que falta. No fixture, um PUT sem If-Match recebe esse estado. Os asteriscos e a precedência entre validadores são tratados documentalmente nesta aula; o runner não implementa um parser geral de todas as condições HTTP.
Executar e ler o ensaio local
Executa run.py a partir da raiz do projeto. O primeiro GET recebe alpha e "v1"; o GET condicionado recebe 304 sem corpo. A escrita válida com "v1" produz beta e "v2"; uma tentativa seguinte baseada em "v1" recebe 412 e deixa beta intacto. Consulta os eventos, os cabeçalhos e o corpo final em evidence.json. Estes resultados foram executados com curl 8.7.1. O estado vive apenas em memória e os pedidos são sequenciais, pelo que o ensaio não demonstra atomicidade distribuída ou persistência após reinício.
Aplicar o raciocínio ao suporte e ao projeto
Num handover, entrega o contrato de precondições, um exemplo de conflito e o procedimento de reconciliação, incluindo quem autoriza repetir a escrita. Confirma que a implementação real avalia a condição e altera o estado de forma adequada à sua arquitetura. A presença de um ETag numa resposta não prova esse comportamento. Nos testes de leitura, preserva corpo e metadados da variante correta. Quando If-None-Match e If-Modified-Since coexistem, a comparação do ETag tem precedência; não escolhas a condição que simplesmente produz a resposta mais pequena.
# From the project root; synthetic local data only
python3 content/labs/http-conditions/run.py
# evidence.json: conditionalRead, validatorComparison, conditionalWrite
# Accepted write: v1 -> v2, alpha -> beta
# Rejected stale write leaves beta intactCaso fictício: dois operadores alteram limites de um batch. O segundo recebe 412, compara a versão atual e só repete depois de reconciliar os limites, mantendo a alteração já aprovada.
Armadilhas comuns
Não transformes 304 num corpo vazio, não convertas validadores fracos manualmente e não troques apenas o ETag para ultrapassar 412 sem rever o conteúdo.
Tópicos relacionados: Métodos, estados e repetição controlada · Cache, variantes e validação · Diagnóstico e orçamento de tempo
Um validador tem contexto; uma escrita rejeitada exige reconciliação, e a garantia real depende da implementação que avalia e aplica a precondição.
Referência: HTTP Semantics · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance