Também disponível em: English · Español · Français · العربية
Verificador de ETag
Compare duas entity tags pelas funções de comparação fraca e forte, e veja o que cada cabeçalho condicional faria com elas.
O que é um ETag, e o que significa o W/
Um ETag é uma string opaca que o servidor associa a uma versão de um recurso. O cliente guarda, devolve na requisição seguinte, e o servidor pode responder com 304 em vez do corpo inteiro se nada mudou. O valor tem uma gramática pequena: um prefixo W/ opcional e, em seguida, a tag entre aspas duplas obrigatórias.
As aspas fazem parte do valor e não são enfeite, e os caracteres permitidos são mais estreitos do que se imagina: o conjunto é %x21 e de %x23 a %x7E, o que deixa de fora a aspa dupla e, menos obviamente, o espaço. A barra invertida é aceita, embora a especificação desaconselhe usá-la porque destinatários antigos podem tentar desescapá-la.
O prefixo W/ diz que a tag é um validador fraco. A explicação de sempre é que uma tag fraca identifica uma versão semanticamente equivalente e não idêntica byte a byte, o que é verdade e faz aquilo soar como uma anotação menor sobre precisão. Não é: muda para que a tag serve.
Como usar
- Ponha o ETag do servidor no primeiro campo. Exatamente como aparece no cabeçalho da resposta, com aspas e prefixo W/ inclusive. O que estiver malformado é explicado em vez de ignorado em silêncio.
- Ponha no segundo a tag comparada com ele. Em geral é o que um cliente mandaria em If-None-Match ou em If-Match.
- Leia os dois resultados e depois a tabela de cabeçalhos. Quando as duas funções discordam, a resposta depende inteiramente de qual cabeçalho está perguntando, e a tabela abaixo detalha o que cada um faria.
Duas funções de comparação, e a que ninguém menciona
O HTTP não tem uma função de comparação para entity tags. Tem duas, e exige uma diferente em cada lugar. A seção 13.1.2 da RFC 9110 diz que o destinatário deve usar a comparação fraca para If-None-Match. A 13.1.1 diz que o servidor de origem deve usar a comparação forte para If-Match.
A comparação fraca ignora completamente o prefixo W/ e compara as tags opacas. A forte exige que sejam iguais e que ambas sejam fortes. A consequência é o que vale levar: um ETag fraco nunca satisfaz a comparação forte, nem mesmo contra uma cópia idêntica de si próprio. A especificação imprime isso na própria tabela: W/"1" contra W/"1" combina pela comparação fraca e não combina pela forte.
Então um ETag fraco cacheia perfeitamente e não aceita escrita. Todo PUT ou PATCH condicional que use If-Match para concorrência otimista falha, sempre, mande o cliente o que mandar. Não há erro explicando: a pré-condição simplesmente nunca passa. Se a sua API devolve 412 em toda atualização e o ETag começa com W/, é esse o motivo.
Não é uma configuração rara. Nos 250 domínios mais acessados, dos quais 173 responderam, só 20,2% mandam algum ETag — e desses, 25,7% são fracos, incluindo wikipedia.org, github.com e apache.org. Para uma página que é cacheada é uma escolha sensata, porque uma tag fraca sobrevive à compressão e a outras transformações que mudam os bytes sem mudar o sentido. Para um endpoint de API que as pessoas atualizam, remove um recurso que ninguém percebe ter perdido.
If-Range é o terceiro caso e funciona de outro jeito. Ali a restrição recai sobre o cliente: a seção 13.1.5 diz que um cliente não deve gerar um cabeçalho If-Range contendo uma tag fraca, então retomar um download parcial exige um validador forte por construção, e não por comparação.
Limites honestos e como isto foi conferido
Isto compara duas tags que você cola. Não faz requisição nenhuma, então não consegue dizer o que o seu próprio servidor manda: um navegador não pode ler cabeçalhos de resposta arbitrários de outra origem, e qualquer ferramenta que afirme o contrário está passando a requisição por um servidor. As ferramentas de desenvolvedor do seu navegador mostram o cabeçalho num clique, que é o jeito certo de obtê-lo.
Uma coisa que esta página de propósito não afirma: que servidores costumam emitir ETags sintaticamente inválidos. Essa era a segunda metade da ideia, e medir matou. Zero dos 35 ETags reais amostrados estavam malformados. Este cabeçalho é emitido por frameworks; quase ninguém escreve um à mão. O validador continua explicando entrada malformada, porque quem digitou uma merece resposta, mas não é o dado interessante e a página não finge que seja.
A lógica de comparação é conferida contra a tabela de quatro linhas da própria especificação, reextraída do texto da RFC a cada execução dos testes em vez de transcrita, então um erro de cópia não sobrevive. São 513 verificações e 14 controles negativos. Dois dos meus próprios casos de teste acabaram codificando suposições em vez da gramática: eu tinha uma tag com espaço como válida e uma com barra invertida como inválida, e a gramática diz o contrário nos dois casos.
Por que é grátis?
Isto é comparação de strings. Roda no seu navegador, não há servidor a pagar e não há onde se cadastrar.
Nada do que você digitar é enviado, guardado ou registrado. ETags são opacos por projeto e às vezes codificam mais sobre um recurso do que o autor pretendia, então vale dizer que eles ficam na aba.