Однажды я размышлял над тем же, и понял, что есть одно важное отличие: даты можно заказывать, а ETags - нет.
Это означает, что если какой-то ресурс был изменен год назад, но никогда с тех пор, и мы это знаем. Тогда мы можем правильно ответить на запрос If-Unmodified-Since для произвольных дат прошлого года и согласиться с тем, что ... он не изменился с этой даты.
Этаг сопоставим только по идентичности. Либо это то же самое, либо это не так. Если у вас тот же ресурс, что и выше, и в течение года docroot был перенесен на новый диск и файловую систему, давая всем файлам новые inode, но сохраняя даты модификации. И кто-то основал ETag на номере inode файла. Тогда мы не можем сказать, что старый ETag все еще в порядке, без журнала прошлых, все еще в порядке ETag.
Так что я не вижу их как одно устаревшее другое. Они для разных ситуаций. Либо вы можете легко получить дату последнего изменения всех данных на странице, которую вы собираетесь обслуживать, либо вы можете легко получить ETag для того, что вы будете обслуживать.
Если у вас есть динамическая веб-страница с данными из большого количества просмотров БД, может быть сложно определить дату последнего изменения, если в вашей базе данных не будет много дат изменения. Но вы всегда можете сделать контрольную сумму md5 для страницы результатов.
При поддержке этих протоколов кеширования я определенно выбираю только один из них, а не оба.