Патч ETags в NixOS

[Maxim Dounin]

Hello!

On Sun, Jan 07, 2024 at 09:57:45AM +0300, izorkin на gmail.com wrote:

> Обнаружилась ещё одна ошибка с текущим вариантом патча:
> https://github.com/NixOS/nixpkgs/pull/278380
> 
> Некорректно кэшируются файлы, которые предварительно сжаты в формат
> gzip и/или brotli форматы.
> 
> Может получится найти какое-то альтернативный вариант решения генерации
> Etags для файлов, которые имеют фиксированную дату? 
> 
> Сейчас, Etags генерируется на основе размера файла + даты изменения.

ETag на основе размера файла и даты модификации файла - кажется 
вполне достаточным для уникальности в рамках требований к strong 
entity tags.  Тем более, что даже при совпадении ETag'ов между 
различными представлениями одного ресурса - сломаться что-либо 
может скорее теоретически, если вдруг меняются правила выбора 
представлений (e.g., включают или выключают gzip_static, а клиент 
в это время пытается делать range-запрос и комбинировать его с 
ранее полученными от другой конфигурации ответами).

Что либо менять в nginx'е я тут смысла не вижу, ETag сейчас 
содержит достаточно информации, чтобы проблем не возникало.

Что до nix store, то кажется, что возвращение размера в ETag также 
должно проблему решить.

> Поможет ли добавление ещё одного параметра, например полного пути к
> файлу? Получится такой вариант:
> размер файла + дата изменения + полный путь к файлу

Полный путь к файлу в ETag точно не имеет смысла.  Более того, его 
там быть точно не должно: если вдруг ресурс обслуживается двумя 
разными origin-серверами, это приведёт к требованию совпадения 
путей к файлу на этих серверах, а при их несовпадении - 
соответственно к полным ответам вместе 304, то есть сломает 
кэширование там, где оно сейчас работает.

Теоретически, наверное, можно пытаться в ETag вставлять какой-то 
идентификатор представления, то если для gzip_static добавлять в 
ETag что-нибудь вроде "...-gz".  Но при наличии размера в том же 
ETag'е смысла в этом исчезающие мало.

-- 
Maxim Dounin
http://mdounin.ru/