Qual é o objetivo de If-Unmodified-Since/If-Modified-Since?Eles não foram substituídos por ETags?

Question

Parece haver duas maneiras distintas de implementar solicitações condicionais usando cabeçalhos HTTP, ambas podendo ser usadas para armazenamento em cache, solicitações de intervalo, controle de simultaneidade, etc.:

1. If-Unmodified-Since e If-Modified-Since, onde o cliente envia um carimbo de data/hora do recurso.
2. Se modificado e se nenhum modificado, onde o cliente envia um ETag representação do recurso.

Em ambos os casos, o cliente envia uma informação que possui sobre o recurso, o que permite ao servidor determinar se o recurso foi alterado desde a última vez que o cliente o viu.O servidor então decide se executará a solicitação dependendo do cabeçalho condicional fornecido pelo cliente.

Não entendo por que duas abordagens separadas estão disponíveis.Certamente, as ETags substituem os carimbos de data e hora, já que o servidor poderia facilmente optar por gerar ETags a partir de carimbos de data e hora.

Então, minhas perguntas são:

• Em quais cenários você pode preferir If-Unmodified-Since/If-Modified-Since em vez de ETags?
• Em quais cenários você pode precisar de ambos?

Answer 1

Certa vez, ponderei a mesma coisa e percebi que há uma diferença que é muito importante:As datas podem ser solicitadas, as ETags não.

Isto significa que se algum recurso foi modificado há um ano, mas nunca desde então, e nós sabemos disso.Então podemos responder corretamente a uma solicitação If-Unmodified-Since para datas arbitrárias no ano passado e concordar que com certeza...não foi modificado desde aquela data.

Um Etag só é comparável em termos de identidade.Ou é a mesma coisa ou não é.Se você tiver o mesmo recurso acima, e durante o ano o docroot foi movido para um novo disco e sistema de arquivos, dando a todos os arquivos novos inodes, mas preservando as datas de modificação.E alguém baseou as ETags no número do inode do arquivo.Então não podemos dizer que a ETag antiga ainda está bem, sem ter um registro de ETags passadas que ainda estão bem.

Portanto, não os vejo como um obsoleto o outro.Eles são para situações diferentes.Você pode obter facilmente uma data da última modificação de todos os dados na página que está prestes a veicular ou pode obter facilmente uma ETag para o que irá veicular.

Se você tiver uma página da Web dinâmica com dados de muitas pesquisas de banco de dados, pode ser difícil saber qual é a data da última modificação sem fazer com que seu banco de dados contenha muitas datas de modificação.Mas você sempre pode fazer uma soma de verificação md5 da página renderizada de resultados.

Ao oferecer suporte a esses protocolos de cache, eu definitivamente opto por apenas um deles, nunca ambos.

Answer 2

Há uma diferença bastante grande:Só posso usar ETags se já tiver solicitado uma ao servidor no passado.Carimbos de data e hora, OTOH, posso compensar à medida que avança.

Answer 3

Razão simples:compatibilidade com versões anteriores.