Этаг: слабый против сильного примера

Question

Я читал об Etags, и я понимаю, что есть 2 способа создания Etag, слабый и сильный.Слабые Etags в вычислительном отношении легче генерировать, чем сильные.Я также узнал, что слабых Etags практически достаточно для большинства случаев использования.

из MDN

Слабые валидаторы легко генерируются, но гораздо менее полезны для сравнений.Сильные валидаторы идеальны для сравнений, но их может быть очень трудно создать эффективно.

другой фрагмент:

Слабые значения Etag двух представлений одних и тех же ресурсов могут быть семантически эквивалентными, но не по байт-идентичным идентичным.

Мне трудно понять, что означает семантически похожий ресурс, но не байтовый же?Было бы здорово увидеть некоторые примеры.

РЕДАКТИРОВАТЬ: нашел пример здесь , но я не понимаю:

Слабая проверка: двапредставления ресурсов семантически эквивалентны, например, некоторые различия в содержании не важны с точки зрения бизнес-логики, например, текущая дата, отображаемая на странице, может не иметь значения для обновления всего ресурса для нее.

Является ли этонапример, при создании Etag вы можете решить, что изменения содержимого не важны для функциональности (например, изменение свойства css для размера шрифта), и ответить 304?Если да, то когда ресурс обновляется в браузере, как я полагаю, если Etag одинаков, браузер не получит последнюю версию.В этом случае это может означать, что когда происходит серьезное изменение и создается новый Etag, изменение свойства css будет только затем отправлено в браузер вместе с основным изменением.

Answer 1

Мое предложение - взглянуть на спецификацию, RFC 7232, раздел 2.1 .Это всего пара страниц и может ответить на все ваши вопросы.

Вы попросили примеры, вот некоторые из спецификации:

• Например,представление метеорологического отчета, который меняется в содержании каждую секунду, на основе динамических измерений, может быть сгруппировано в наборы эквивалентных представлений (с точки зрения сервера происхождения) с одним и тем же слабым средством проверки, чтобы позволить кэшированным представлениям быть действительными для разумногопериод времени.

• Время изменения представления, если оно определено только с разрешением в одну секунду, может быть слабым валидатором, если представление может бытьизменено дважды в течение одной секунды и извлекается между этими изменениями.

• Если исходный сервер отправляет тот же самый валидатор для представления с примененным к нему кодированием содержимого gzipдля представления без кодирования контента, тогда этот валидаторeak.

Последний показывает, что, вероятно, является наиболее распространенным использованием слабых ETag: серверы, преобразующие сильные ETag в слабые, когда они копируют контент. Nginx делает это, например, .

В спецификации также объясняется, когда менять слабый ETag:

Исходный сервер ДОЛЖЕН изменять слабый тег объекта всякий раз, когдаон считает предшествующие представления неприемлемыми в качестве замены текущего представления.

Другими словами, вам решать, являются ли два представления ресурса приемлемыми заменами или нет.Если это так, вы можете улучшить производительность кэширования, дав им тот же слабый ETag.