Hello!

On Fri, Jan 12, 2024 at 10:35:38PM +0300, izorkin@gmail.com wrote:

> Вы писали 9 января 2024 г., 5:26:08:
>
> > Что до nix store, то кажется, что возвращение размера в ETag также
> > должно проблему решить.
>
> В том то и дело, что размер не всегда меняется.

Дата модификации и размер - на практике достаточная комбинация для
отслеживания версий файлов и их различных представлений, по
крайней мере в рамках тех представлений файлов, которые умеет
возвращать nginx (исходный файл и его gzip-версия).

В nix store, в силу отказа от времени, время надо на что-то заменять,
как минимум в ситуациях, когда полных путь, включающих store hash,
не фигурирует в URL'е. Но это ортогональный вопрос (и скорее
вопрос к самой концепции, которая получилась не очень совместимой
с HTTP).

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

Hash-сумма файла в качестве ETag - в целом отличное решение,
проблема тут ровно одна: её нужно как-то получить, ибо системный
вызов fstat() никаких hash-сумм почему-то не возвращает. Считать
на лету - очевидно, плохой вариант для нагруженного сервера, так
как файл придётся на каждый запрос читать дважды. А получать
hash-сумму откуда-то ещё, скажем из внешнего файла или
extended-атрибутов - выглядит в лучшем случае дополнительной фичей
(смотри https://trac.nginx.org/nginx/ticket/2351 например).

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru