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/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru