Hello! On Fri, Jan 12, 2024 at 10:35:38PM +0300, izor...@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
