HTTP ETag - HTTP ETag

A ETag ou tag de entidade faz parte do HTTP , o protocolo da World Wide Web . É um dos vários mecanismos que o HTTP fornece para validação de cache da Web , que permite a um cliente fazer solicitações condicionais. Esse mecanismo permite que os caches sejam mais eficientes e economiza largura de banda, pois um servidor Web não precisa enviar uma resposta completa se o conteúdo não tiver sido alterado. ETags também podem ser usados para controle de simultaneidade otimista para ajudar a evitar que atualizações simultâneas de um recurso sobrescrevam umas às outras.

Um ETag é um identificador opaco atribuído por um servidor Web a uma versão específica de um recurso encontrado em um URL . Se a representação do recurso nesse URL mudar, uma nova e diferente ETag será atribuída. Usadas dessa maneira, as ETags são semelhantes às impressões digitais e podem ser comparadas rapidamente para determinar se duas representações de um recurso são iguais.

Geração de ETag

O uso de ETags no cabeçalho HTTP é opcional (não obrigatório como com alguns outros campos do cabeçalho HTTP 1.1). O método pelo qual as ETags são geradas nunca foi especificado na especificação HTTP.

Os métodos comuns de geração de ETag incluem o uso de uma função hash resistente à colisão do conteúdo do recurso, um hash do carimbo de data / hora da última modificação ou mesmo apenas um número de revisão .

Para evitar o uso de dados de cache obsoletos, os métodos usados para gerar ETags devem garantir (tanto quanto seja prático) que cada ETag é único. No entanto, uma função de geração de ETag pode ser considerada "utilizável", se puder ser provado (matematicamente) que a duplicação de ETags seria "aceitavelmente rara", mesmo que pudesse ou ocorresse.

O RFC-7232 afirma explicitamente que as ETags devem reconhecer a codificação de conteúdo , por exemplo

ETag: "123-a" – for no Content-Encoding
ETag: "123-b" – for Content-Encoding: gzip

Algumas funções de checksum anteriores que eram mais fracas do que CRC32 ou CRC64 são conhecidas por sofrerem de problemas de colisão de hash. Portanto, eles não eram bons candidatos para uso na geração de ETag.

Validação forte e fraca

O mecanismo ETag suporta validação forte e validação fraca . Eles são diferenciados pela presença de um "W /" inicial no identificador ETag, como:

"123456789"   – A strong ETag validator
W/"123456789" – A weak ETag validator

Uma correspondência de ETag fortemente validada indica que o conteúdo das duas representações de recurso é idêntico byte a byte e que todos os outros campos de entidade (como Content-Language) também estão inalterados. ETags fortes permitem o armazenamento em cache e a remontagem de respostas parciais, como ocorre com as solicitações de intervalo de bytes .

Uma correspondência de ETag de validação fraca indica apenas que as duas representações são semanticamente equivalentes , o que significa que, para fins práticos, elas são intercambiáveis e que cópias em cache podem ser usadas. No entanto, as representações de recursos não são necessariamente idênticas byte a byte e, portanto, ETags fracas não são adequadas para solicitações de intervalo de bytes. ETags fracas podem ser úteis para casos em que ETags fortes são impraticáveis para um servidor da Web gerar, como no caso de conteúdo gerado dinamicamente .

Uso típico

No uso típico, quando um URL é recuperado, o servidor Web retornará a representação atual do recurso junto com seu valor ETag correspondente, que é colocado em um campo "ETag" do cabeçalho de resposta HTTP:

ETag: "686897696a7c876b7e"

O cliente pode então decidir armazenar em cache a representação, junto com sua ETag. Posteriormente, se o cliente quiser recuperar o mesmo recurso de URL novamente, ele primeiro determinará se a versão do URL em cache local expirou (por meio dos cabeçalhos Cache-Control e Expire). Se o URL não tiver expirado, ele recuperará o recurso armazenado em cache localmente. Se for determinado que a URL expirou (está desatualizada ), o cliente enviará uma solicitação ao servidor que inclui sua cópia salva anteriormente da ETag no campo "If-None-Match".

If-None-Match: "686897696a7c876b7e"

Nessa solicitação subsequente, o servidor pode agora comparar a ETag do cliente com a ETag da versão atual do recurso. Se os valores de ETag corresponderem, significando que o recurso não foi alterado, o servidor pode enviar de volta uma resposta muito curta com um status HTTP 304 Não Modificado . O status 304 diz ao cliente que sua versão em cache ainda é boa e que ele deve usá-la.

No entanto, se os valores de ETag não corresponderem, significando que o recurso provavelmente mudou, uma resposta completa incluindo o conteúdo do recurso é retornada, como se ETags não estivessem sendo usados. Nesse caso, o cliente pode decidir substituir sua versão armazenada anteriormente em cache pela representação recém-retornada do recurso e a nova ETag.

Os valores de ETag podem ser usados em sistemas de monitoramento de página da web . O monitoramento eficiente de páginas da web é prejudicado pelo fato de que a maioria dos sites não define os cabeçalhos de ETag para páginas da web. Quando um monitor da Web não tem dicas se o conteúdo da Web foi alterado, todo o conteúdo deve ser recuperado e analisado usando recursos de computação para o editor e o assinante.

Detecção de ETag incompatível

Um site com erros às vezes pode falhar ao atualizar a ETag após a atualização de seu recurso semântico. Em 2019, um exemplo de site proeminente é export.arxiv.org . Como resultado, a resposta retornada incorretamente é o status 304 e o cliente não consegue recuperar o recurso atualizado. Para detectar um site com erros:

Armazene a resposta e a ETag em cache, supondo que haja uma ETag e que a resposta não tenha sido cancelada.
Para uma solicitação subsequente que incluiria o cabeçalho If-None-Match, não envie este cabeçalho com talvez uma probabilidade aleatória de 20%. Com essa probabilidade, se a resposta retornar um conteúdo alterado, mas a mesma ETag do que foi anteriormente armazenado em cache, marque o site como bugado e desative o armazenamento em cache de ETag para ele. Como um lembrete, para uma ETag forte, a comparação de conteúdo pode ser byte a byte, ao passo que, para uma ETag fraca, ela verificaria apenas a equivalência semântica.

Rastreamento usando ETags

As ETags podem ser usadas para rastrear usuários únicos, uma vez que os cookies HTTP estão cada vez mais sendo excluídos por usuários preocupados com a privacidade. Em julho de 2011, Ashkan Soltani e uma equipe de pesquisadores da UC Berkeley relataram que vários sites, incluindo o Hulu , estavam usando ETags para fins de rastreamento. O Hulu e o KISSmetrics pararam de "reaparecer" em 29 de julho de 2011, já que o KISSmetrics e mais de 20 de seus clientes estão enfrentando uma ação coletiva sobre o uso de cookies de rastreamento "não elimináveis" que envolvem parcialmente o uso de ETags.

Como as ETags são armazenadas em cache pelo navegador e retornadas com solicitações subsequentes para o mesmo recurso, um servidor de rastreamento pode simplesmente repetir qualquer ETag recebida do navegador para garantir que uma ETag atribuída persista indefinidamente (de maneira semelhante aos cookies persistentes ). Cabeçalhos de cache adicionais também podem aprimorar a preservação de dados ETag.

As ETags podem ser lavadas limpando o cache do navegador (as implementações variam).

Referências

ETag na especificação HTTP / 1.1
Sobre Etags and Datestamps por Lars R. Clausen (2004)

Languages

In other projects