Патч ETags в NixOS

[Maxim Dounin]

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/