From alexcool на gmail.com Sun Nov 12 00:46:40 2023 From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=) Date: Sun, 12 Nov 2023 07:46:40 +0700 Subject: cache loader atime Message-ID: Здравствуйте. При перезагрузке nginx теряется LRU информация кэша. Возможно ли сделать так, чтобы cache loader обращал внимание на atime файлов и использовал эти данные для формирования LRU информации? С наилучшими пожеланиями. Алексей. From mdounin на mdounin.ru Sun Nov 12 21:18:54 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Nov 2023 00:18:54 +0300 Subject: cache loader atime In-Reply-To: References: Message-ID: Hello! On Sun, Nov 12, 2023 at 07:46:40AM +0700, Алексей wrote: > При перезагрузке nginx теряется LRU информация кэша. > > Возможно ли сделать так, чтобы cache loader обращал внимание на atime > файлов и использовал эти данные для формирования LRU информации? Теоретически - наверное, можно попробовать такое напрограммировать. На практике - во-первых, подозреваю в таком режиме проблемы с производительностью для больших кэшей (сортировать миллионы элементов кэша при его загрузке, чтобы получить LRU, банально ресурсоёмко). Во-вторых, полезность atime, кажется, под большим вопросом - даже если atime есть (в нагруженных конфигурациях его часто просто отключают), примерно любых операций с сервером может оказаться достаточно, чтобы все элементы кэша подлежали удалению сразу после запуска nginx'а, скажем, при inactive=10m (по умолчанию). -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Thu Nov 16 17:06:12 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 16 Nov 2023 20:06:12 +0300 Subject: =?windows-1251?B?bmdpbnhRdWljOiDs4Orx6Ozg6/zt++kg8ODn7OXwIE1UVQ==?= Message-ID: <1866677821.20231116200612@gmail.com> Здравствуйте. Между сервером и компьютером настроена сеть с поддержкой MTU 9000. WEB сервер Nginx при запросе отдаёт QUIC пакеты максимум в 1534 байта. Можно ли как-то увеличить размер пакетов? -- С уважением, Izorkin mailto:izorkin на gmail.com From pluknet на nginx.com Thu Nov 16 17:24:25 2023 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 16 Nov 2023 21:24:25 +0400 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0LzQsNC60YHQuNC80LDQu9GM0L3Ri9C5?= =?utf-8?B?INGA0LDQt9C80LXRgCBNVFU=?= In-Reply-To: <1866677821.20231116200612@gmail.com> References: <1866677821.20231116200612@gmail.com> Message-ID: > On 16 Nov 2023, at 21:06, izorkin на gmail.com wrote: > > Здравствуйте. > Между сервером и компьютером настроена сеть с поддержкой MTU 9000. WEB сервер Nginx > при запросе отдаёт QUIC пакеты максимум в 1534 байта. Можно ли как-то увеличить размер > пакетов? > Это происходит автоматически посредством DPLPMTUD начиная с версии 1.25.2. Изменения в nginx 1.25.2 15.08.2023 *) Добавление: path MTU discovery при использовании HTTP/3. -- Sergey Kandaurov From izorkin на gmail.com Thu Nov 16 17:39:51 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 16 Nov 2023 20:39:51 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0LzQsNC60YHQuNC80LDQu9GM0L3Ri9C5INGA0LDQt9C80LXRgCBN?= =?utf-8?B?VFU=?= In-Reply-To: References: <1866677821.20231116200612@gmail.com> Message-ID: <139357001.20231116203951@gmail.com> Здравствуйте, Sergey. Тогда, теоретически размер должен был бы достичь до 9000. А у метода DPLPMTUD есть ограничение на размер пакетов и/или количество успешных и неудачных попыток? Вы писали 16 ноября 2023 г., 20:24:25: > Это происходит автоматически посредством DPLPMTUD начиная с версии 1.25.2. > Изменения в nginx 1.25.2 15.08.2023 > *) Добавление: path MTU discovery при использовании HTTP/3. -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Fri Nov 17 07:01:25 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Fri, 17 Nov 2023 10:01:25 +0300 Subject: =?windows-1251?B?TWltZS10eXBlczog7uHt7uLr5e3o5Q==?= Message-ID: <9610390738.20231117100125@gmail.com> Здравствуйте. Планируется ли обновление и расширенная поддержка mime типов? На данный момент обычно приходится использовать файл mime.types из приложения mailcap, но он в последнее время редко обновляется. Если необходимо, то могу попробовать обновить файл и отправить патч. На данный момент количество mime типов насчитывает около 1000-1200 штук. -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Fri Nov 17 20:22:58 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 17 Nov 2023 23:22:58 +0300 Subject: Mime-types: =?koi8-r?B?z8LOz9fMxc7J?= =?koi8-r?Q?=C5?= In-Reply-To: <9610390738.20231117100125@gmail.com> References: <9610390738.20231117100125@gmail.com> Message-ID: Hello! On Fri, Nov 17, 2023 at 10:01:25AM +0300, izorkin на gmail.com wrote: > Здравствуйте. > Планируется ли обновление и расширенная поддержка mime типов? > На данный момент обычно приходится использовать файл mime.types > из приложения mailcap, но он в последнее время редко обновляется. > Если необходимо, то могу попробовать обновить файл и отправить патч. > На данный момент количество mime типов насчитывает около 1000-1200 > штук. Задачи сделать так, чтобы файл mime.types в поставке содержал все возможные MIME-типы - не ставится. Однако мы стараемся поддерживать его так, чтобы имеющихся в нём MIME-типов хватало для типичных web-сайтов. Если чего-то не хватает - можно предлагать тут или в Trac. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Sat Nov 18 07:22:58 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sat, 18 Nov 2023 10:22:58 +0300 Subject: =?utf-8?B?UmU6IE1pbWUtdHlwZXM6INC+0LHQvdC+0LLQu9C10L3QuNC1?= In-Reply-To: References: <9610390738.20231117100125@gmail.com> Message-ID: <501488104.20231118102258@gmail.com> Здравствуйте, Максим. Попробую сделать минимальный патч, который включает изменения, необходимые для корректной работы gzip/brotli сжатия. Но не думаю, что ментейнеры дистрибутива согласятся использовать минимальное количество mime-типов. Сперва мною был предложен пакет media-types, но не устраивает вариант реализации и сложность обновления. Поэтому и подумал, что может в самом пакете nginx обновить mime типы использую базу IANA и периодически обновлять их. Как вариант добавить расширенный файл extended-mime.types. И, кому понадобится, смогут просто указать ругой файл в конфигурации и не придётся использовать сторонние пакеты, такие как mailcap и т.п. Вы писали 17 ноября 2023 г., 23:22:58: > Hello! > On Fri, Nov 17, 2023 at 10:01:25AM +0300, izorkin на gmail.com wrote: > Задачи сделать так, чтобы файл mime.types в поставке содержал все > возможные MIME-типы - не ставится. Однако мы стараемся > поддерживать его так, чтобы имеющихся в нём MIME-типов хватало для > типичных web-сайтов. Если чего-то не хватает - можно предлагать > тут или в Trac. -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Sat Nov 18 14:56:17 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sat, 18 Nov 2023 17:56:17 +0300 Subject: =?utf-8?B?UmU6IE1pbWUtdHlwZXM6INC+0LHQvdC+0LLQu9C10L3QuNC1?= In-Reply-To: References: <9610390738.20231117100125@gmail.com> Message-ID: <962197451.20231118175617@gmail.com> Здравствуйте, Максим. Сделал минимальный вариант файла mime-types с комментариями, чтобы можно было проще ориентироваться откуда взяты расширения. https://pastebin.com/sig1HARN -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Sun Nov 19 00:15:54 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 19 Nov 2023 03:15:54 +0300 Subject: Mime-types: =?koi8-r?B?z8LOz9fMxc7J?= =?koi8-r?Q?=C5?= In-Reply-To: <962197451.20231118175617@gmail.com> References: <9610390738.20231117100125@gmail.com> <962197451.20231118175617@gmail.com> Message-ID: Hello! On Sat, Nov 18, 2023 at 05:56:17PM +0300, izorkin на gmail.com wrote: > Здравствуйте, Максим. > Сделал минимальный вариант файла mime-types с комментариями, чтобы можно > было проще ориентироваться откуда взяты расширения. > https://pastebin.com/sig1HARN Боюсь, так это не работает. Если хочется что-то добавить к существующему списку типов в mime.types, то стоит по каждому предлагаемому к добавлению MIME-типу расписать, что это, и зачем это нужно в mime.types для типичного web-сайта. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Sun Nov 19 06:20:50 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sun, 19 Nov 2023 09:20:50 +0300 Subject: =?utf-8?B?UmU6IE1pbWUtdHlwZXM6INC+0LHQvdC+0LLQu9C10L3QuNC1?= In-Reply-To: References: <9610390738.20231117100125@gmail.com> <962197451.20231118175617@gmail.com> Message-ID: <197871525.20231119092050@gmail.com> Здравствуйте, Максим. Там достаточно много изменений. У многих расширений изменён MIME-тип. Добавлены MIME-типы которые хорошо поддаются сжатию. Всё это по отдельности будет сложно описать. Может получится обойтись несколькими коммитами? Вы писали 19 ноября 2023 г., 3:15:54: > Hello! > On Sat, Nov 18, 2023 at 05:56:17PM +0300, izorkin на gmail.com wrote: > Боюсь, так это не работает. Если хочется что-то добавить к > существующему списку типов в mime.types, то стоит по каждому > предлагаемому к добавлению MIME-типу расписать, что это, и зачем > это нужно в mime.types для типичного web-сайта. -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Sun Nov 19 13:15:42 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sun, 19 Nov 2023 16:15:42 +0300 Subject: =?windows-1251?Q?=CF=E0=F2=F7_ETags_=E2_NixOS?= Message-ID: <441659217.20231119161542@gmail.com> Здравствуйте. В NixOS используется патч ETags для корректного определения изменения файла, расположенного в папке /nix/store. В этой папке все файлы имеют временную метку установленную в 0. Поэтому без использования этого патча файлы в кэше перестают обновляться. Возможно ли добавить этот патч в Upstream? Подробнее: https://github.com/NixOS/nixpkgs/blob/master/doc/packages/nginx.section.md Либо добавить дополнительный параметр, в котором можно указать папки для которых используется только механизм ETags. -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Mon Nov 20 01:39:44 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2023 04:39:44 +0300 Subject: Mime-types: =?koi8-r?B?z8LOz9fMxc7J?= =?koi8-r?Q?=C5?= In-Reply-To: <197871525.20231119092050@gmail.com> References: <9610390738.20231117100125@gmail.com> <962197451.20231118175617@gmail.com> <197871525.20231119092050@gmail.com> Message-ID: Hello! On Sun, Nov 19, 2023 at 09:20:50AM +0300, izorkin на gmail.com wrote: > Там достаточно много изменений. У многих расширений изменён MIME-тип. > Добавлены MIME-типы которые хорошо поддаются сжатию. Всё это по > отдельности будет сложно описать. Может получится обойтись > несколькими коммитами? Каждое изменение и дополнение подлежит обсуждению, а в случае изменений - это ещё и потенциально проблемы совместимости и необходимость сопутствующих изменений в коде, а равно большие сомнения в их целесообразности. Скажем, про application/javascript vs. text/javascript можно почитать тут и далее по ссылкам: https://trac.nginx.org/nginx/ticket/1407 Там и само изменение сомнительно, и вызовет необходимость изменения конфигов (скажем, если application/javascript используется в gzip_types, то есть это явно нужно будет документировать в CHANGES), и в добавок в коде нужно менять два места, где сейчас выдаётся application/javascript, и в стандарте QPACK для HTTP/3 используется application/javascript. Пытаться подобные изменения протащить "пачкой" - можно, но не имеет смысла, ибо к успеху точно не приведёт. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Nov 20 02:57:08 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2023 05:57:08 +0300 Subject: =?koi8-r?B?8MHU3iBFVGFncyDX?= NixOS In-Reply-To: <441659217.20231119161542@gmail.com> References: <441659217.20231119161542@gmail.com> Message-ID: Hello! On Sun, Nov 19, 2023 at 04:15:42PM +0300, izorkin на gmail.com wrote: > Здравствуйте. > > В NixOS используется патч ETags для корректного определения изменения > файла, расположенного в папке /nix/store. В этой папке все файлы имеют > временную метку установленную в 0. Поэтому без использования этого > патча файлы в кэше перестают обновляться. Возможно ли добавить этот > патч в Upstream? > Подробнее: > https://github.com/NixOS/nixpkgs/blob/master/doc/packages/nginx.section.md > > Либо добавить дополнительный параметр, в котором можно указать папки > для которых используется только механизм ETags. Если я правильно понимаю, речь про вот этот патч: https://github.com/NixOS/nixpkgs/blob/nixos-23.05/pkgs/servers/http/nginx/nix-etag-1.15.4.patch Патч выглядит, скажем так, непригодным для включения куда-либо. Если для задачи достаточно не выдавать пользователю Last-Modified, а выдавать только ETag (этого, вероятно, будет достаточно как минимум если в URI виден полный путь из /nix/store, включающий hash, а также в остальных случаях, если на размер можно полагаться для идентификации файлов), то просто убрать Last-Modified из ответов можно стандартным механизмом add_header (http://nginx.org/r/add_header): add_header Last-Modified ""; Соответственно у ответов будет только ETag, сформированный nginx'ом из даты модификации файла (0 в случае /nix/store) и размера файла. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Mon Nov 20 05:06:33 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Mon, 20 Nov 2023 08:06:33 +0300 Subject: =?utf-8?B?UmU6IE1pbWUtdHlwZXM6INC+0LHQvdC+0LLQu9C10L3QuNC1?= In-Reply-To: References: <9610390738.20231117100125@gmail.com> <962197451.20231118175617@gmail.com> <197871525.20231119092050@gmail.com> Message-ID: <1494609425.20231120080633@gmail.com> Здравствуйте, Максим. Да, сложнее чем я думал... Как минимум, я бы хотел куда-нибудь включить этот минимальный список MIME-типов, чтобы корректно работало GZIP сжатие: https://github.com/NixOS/nixpkgs/blob/3f21a22b5aafefa1845dec6f4a378a8f53d8681c/nixos/modules/services/web-servers/nginx/default.nix#L35-L68 Некоторых из них нету в пакете mailpcap, поэтому иногда возникают проблемы. Засада с javascript... Не явных проблем с заменой application/xml на text/xml случаем нету? Вы писали 20 ноября 2023 г., 4:39:44: > Hello! > On Sun, Nov 19, 2023 at 09:20:50AM +0300, izorkin на gmail.com wrote: > Каждое изменение и дополнение подлежит обсуждению, а в случае > изменений - это ещё и потенциально проблемы совместимости и > необходимость сопутствующих изменений в коде, а равно большие > сомнения в их целесообразности. > Скажем, про application/javascript vs. text/javascript можно > почитать тут и далее по ссылкам: > https://trac.nginx.org/nginx/ticket/1407 > Там и само изменение сомнительно, и вызовет необходимость > изменения конфигов (скажем, если application/javascript > используется в gzip_types, то есть это явно нужно будет > документировать в CHANGES), и в добавок в коде нужно менять два > места, где сейчас выдаётся application/javascript, и в стандарте > QPACK для HTTP/3 используется application/javascript. > Пытаться подобные изменения протащить "пачкой" - можно, но не > имеет смысла, ибо к успеху точно не приведёт. -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Tue Nov 21 18:53:16 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Tue, 21 Nov 2023 21:53:16 +0300 Subject: =?utf-8?B?UmU6INCf0LDRgtGHIEVUYWdzINCyIE5peE9T?= In-Reply-To: References: <441659217.20231119161542@gmail.com> Message-ID: <1053893616.20231121215316@gmail.com> Здравствуйте, Maxim. Да, этот патч, забыл указать ссылку. Проверил без патча и добавлением строки `add_header Last-Modified "";` В ответе генерируется ETag: "1-4e", "1-75" и т.д. Если после изменения содержимого файла без изменения размера, то при запросе отдаётся файл из кеша, т.к. при этом ETag не изменяется. А если размер файла меняется, кеш обновляется. Вариант с использованием хеадера Last-Modified не подходит, может надо как-то учитывать путь к файлу для генерации ETag. Вы писали 20 ноября 2023 г., 5:57:08: > Hello! > On Sun, Nov 19, 2023 at 04:15:42PM +0300, izorkin на gmail.com wrote: > Если я правильно понимаю, речь про вот этот патч: > https://github.com/NixOS/nixpkgs/blob/nixos-23.05/pkgs/servers/http/nginx/nix-etag-1.15.4.patch > Патч выглядит, скажем так, непригодным для включения куда-либо. > Если для задачи достаточно не выдавать пользователю Last-Modified, > а выдавать только ETag (этого, вероятно, будет достаточно как > минимум если в URI виден полный путь из /nix/store, включающий > hash, а также в остальных случаях, если на размер можно полагаться для > идентификации файлов), то просто убрать Last-Modified из ответов > можно стандартным механизмом add_header > (http://nginx.org/r/add_header): > add_header Last-Modified ""; > Соответственно у ответов будет только ETag, сформированный > nginx'ом из даты модификации файла (0 в случае /nix/store) и > размера файла. -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Tue Nov 21 19:43:08 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Nov 2023 22:43:08 +0300 Subject: Mime-types: =?koi8-r?B?z8LOz9fMxc7J?= =?koi8-r?Q?=C5?= In-Reply-To: <1494609425.20231120080633@gmail.com> References: <9610390738.20231117100125@gmail.com> <962197451.20231118175617@gmail.com> <197871525.20231119092050@gmail.com> <1494609425.20231120080633@gmail.com> Message-ID: Hello! On Mon, Nov 20, 2023 at 08:06:33AM +0300, izorkin на gmail.com wrote: > Да, сложнее чем я думал... > Как минимум, я бы хотел куда-нибудь включить этот минимальный список > MIME-типов, чтобы корректно работало GZIP сжатие: > https://github.com/NixOS/nixpkgs/blob/3f21a22b5aafefa1845dec6f4a378a8f53d8681c/nixos/modules/services/web-servers/nginx/default.nix#L35-L68 > Некоторых из них нету в пакете mailpcap, поэтому иногда возникают > проблемы. Gzip-сжатие работает корректно независимо от того, какие именно типы файлов сказано жать. Самое плохо, что может случиться от отсутствия MIME-типов - gzip-сжатие для этих файлов будет выключено, и соответственно общая эффективность сжатия упадёт. Имеет смысл обсуждать ситуации, когда среди ответов есть заметный процент файлов какого-либо типа, который можно (и хотелось бы) жать, и в то же время nginx не умеет распознавать MIME-тип для этих файлов по расширению. То есть типичному web-сайту приходится и конфигурировать gzip_types, и в добавок прописывать MIME-типы через types. На вскидку я в списке по ссылке вижу следующие типы, которых (или аналогов для соответствующих расширений) нет в mime.types nginx'а: application/ld+json application/manifest+json application/rdf+xml application/x-web-app-manifest+json application/xliff+xml font/collection font/otf font/ttf text/cache-manifest text/calendar text/csv text/markdown text/vcard text/vnd.rim.location.xloc В целом кажется, что для типичного web-сайта доля ответов с файлами таких типов должна быть около нуля, и соответственно с точки зрения gzip-сжатия полезность добавления этих типов примерно такая же. Возможно, из этого списка стоит добавить application/manifest+json, text/csv и text/markdown, но скорее из общих соображений. > Засада с javascript... Не явных проблем с заменой application/xml > на text/xml случаем нету? Сейчас в nginx'е используется text/xml, и каких-либо причин менять тип не прослеживается. В то же время, базовые вопросы при изменении, если вдруг его делать, ровно такие же: подобное изменение может потребовать изменения конфигов, и соответственно должно быть явно документировано, а равно соответствующих изменений в коде, если тип где-то используется в коде (text/xml - используется). -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Tue Nov 21 21:55:48 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 22 Nov 2023 00:55:48 +0300 Subject: =?utf-8?B?UmU6IE1pbWUtdHlwZXM6INC+0LHQvdC+0LLQu9C10L3QuNC1?= In-Reply-To: References: <9610390738.20231117100125@gmail.com> <962197451.20231118175617@gmail.com> <197871525.20231119092050@gmail.com> <1494609425.20231120080633@gmail.com> Message-ID: <303377644.20231122005548@gmail.com> Здравствуйте, Максим. Как мне кажется шрифты ttf/otf часто используются, например в Mastodon. В Roundcube много файлов с расширением .less, которые можно отнести text/plain. К этому типу можно также отнести субтитры в формате ass, которые много где используются. С другими типами реже сталкивался. При составлении этого списка ориентировался на популярный сборник конфигураций - https://github.com/h5bp/server-configs-nginx который поддерживается сообществом. Настройки для gzip: https://github.com/h5bp/server-configs-nginx/blob/main/h5bp/web_performance/compression.conf MIME типы: https://github.com/h5bp/server-configs-nginx/blob/main/mime.types Там как раз таки прописаны распространённые варианты. Вы писали 21 ноября 2023 г., 22:43:08: > Hello! > On Mon, Nov 20, 2023 at 08:06:33AM +0300, izorkin на gmail.com wrote: > Gzip-сжатие работает корректно независимо от того, какие именно > типы файлов сказано жать. Самое плохо, что может случиться от > отсутствия MIME-типов - gzip-сжатие для этих файлов будет > выключено, и соответственно общая эффективность сжатия упадёт. > Имеет смысл обсуждать ситуации, когда среди ответов есть заметный > процент файлов какого-либо типа, который можно (и хотелось бы) > жать, и в то же время nginx не умеет распознавать MIME-тип для > этих файлов по расширению. То есть типичному web-сайту приходится > и конфигурировать gzip_types, и в добавок прописывать MIME-типы > через types. > На вскидку я в списке по ссылке вижу следующие типы, которых > (или аналогов для соответствующих расширений) нет в mime.types > nginx'а: > application/ld+json > application/manifest+json > application/rdf+xml > application/x-web-app-manifest+json > application/xliff+xml > font/collection > font/otf > font/ttf > text/cache-manifest > text/calendar > text/csv > text/markdown > text/vcard > text/vnd.rim.location.xloc > В целом кажется, что для типичного web-сайта доля ответов с > файлами таких типов должна быть около нуля, и соответственно с > точки зрения gzip-сжатия полезность добавления этих типов примерно > такая же. > Возможно, из этого списка стоит добавить > application/manifest+json, text/csv и text/markdown, но скорее из > общих соображений. > Сейчас в nginx'е используется text/xml, и каких-либо причин менять > тип не прослеживается. > В то же время, базовые вопросы при изменении, если вдруг его > делать, ровно такие же: подобное изменение может потребовать > изменения конфигов, и соответственно должно быть явно > документировано, а равно соответствующих изменений в коде, если > тип где-то используется в коде (text/xml - используется). -- С уважением, Izorkin mailto:izorkin на gmail.com From nginx на kinetiksoft.com Wed Nov 22 16:19:38 2023 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Wed, 22 Nov 2023 18:19:38 +0200 Subject: Nuxt (Node.JS) + nginx-unit Message-ID: <9ea6d509-f285-4047-80c6-9a60eb5c0df1@kinetiksoft.com> Здравствуйте! Собираемся внедрять в инфраструктуру ПО использующее фреймворк Nuxt (https://nuxt.com/) на Node.JS. На данный момент используем преимущественно unit+PHP . Соответственно не хотели бы отказываться от unit и для Nuxt. Однако разработчики проекта на Nuxt (не самого Nuxt, а ПО для нас) говорят, что с Nuxt доступен только вариант проксирования через unit, так как Nuxt использует unJS Nitro (https://nuxt.com/docs/getting-started/server), что лишает смысла использования unit (для проксирования мы и nginx можем). Вопрос, к местному сообществу: можно ли использовать Nuxt с unit в режиме unit-http (https://unit.nginx.org/howto/samples/#node-js) или nodejs-loader https://unit.nginx.org/configuration/#configuration-nodejs-loader ? С уважением, Иван. From eugene.prokopiev на gmail.com Thu Nov 23 11:31:47 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Thu, 23 Nov 2023 14:31:47 +0300 Subject: =?UTF-8?B?0JrRjdGI0LjRgNC+0LLQsNC90LjQtSDRgNC10L/QvtC30LjRgtC+0YDQuNC10LIgbWF2ZQ==?= =?UTF-8?B?bi9weXBpL25wbSAtIHByb3h5X2NhY2hlINC40LvQuCBwcm94eV9zdG9yZQ==?= Message-ID: Здравствуйте! Есть задача кэширования репозиториев maven/pypi/npm для разработки - и гуглится куча примеров, как это сделать Но смущает, что во всех примерах используются директивы proxy_cache*, а мне более удобным кажется proxy_store - в этом случае кэш раскладываются по файлам аналогично оригиналу, понятно где, что и сколько места занимает, легко вручную удалить часть кэша и т.д. Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или лучше?) proxy_cache*? -- WBR, Eugene Prokopiev From vlad.shabanov на gmail.com Thu Nov 23 12:22:35 2023 From: vlad.shabanov на gmail.com (Vladislav Shabanov) Date: Thu, 23 Nov 2023 15:22:35 +0300 Subject: =?utf-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C4?= =?utf-8?B?0YLQvtGA0LjQtdCyIG1hdmVuL3B5cGkvbnBtIC0gcHJveHlfY2FjaGUg0Lg=?= =?utf-8?B?0LvQuCBwcm94eV9zdG9yZQ==?= In-Reply-To: References: Message-ID: Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать сложнее. Посмотрите: https://verdaccio.org/docs/best https://www.sonatype.com/products/sonatype-nexus-oss-download Владислав > 23 нояб. 2023 г., в 14:31, Eugene Prokopiev написал(а): > > Здравствуйте! > > Есть задача кэширования репозиториев maven/pypi/npm для разработки - и > гуглится куча примеров, как это сделать > > Но смущает, что во всех примерах используются директивы proxy_cache*, > а мне более удобным кажется proxy_store - в этом случае кэш > раскладываются по файлам аналогично оригиналу, понятно где, что и > сколько места занимает, легко вручную удалить часть кэша и т.д. > > Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или > лучше?) proxy_cache*? > > -- > WBR, > Eugene Prokopiev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Nov 23 13:24:35 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 23 Nov 2023 14:24:35 +0100 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: Message-ID: есть же прямо специализированные кеширующие прокси для, какой смысл кулибинствовать на уровне http ? тем более, что там куча POST запросов, которые не могут кешироваться чт, 23 нояб. 2023 г. в 12:29, Eugene Prokopiev : > Здравствуйте! > > Есть задача кэширования репозиториев maven/pypi/npm для разработки - и > гуглится куча примеров, как это сделать > > Но смущает, что во всех примерах используются директивы proxy_cache*, > а мне более удобным кажется proxy_store - в этом случае кэш > раскладываются по файлам аналогично оригиналу, понятно где, что и > сколько места занимает, легко вручную удалить часть кэша и т.д. > > Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или > лучше?) proxy_cache*? > > -- > WBR, > Eugene Prokopiev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mihakot на gmail.com Thu Nov 23 13:27:24 2023 From: mihakot на gmail.com (MihaKot) Date: Thu, 23 Nov 2023 16:27:24 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: Message-ID: Согласен. Зачем использовать nginx для кеширования npm пакетов? Есть вполне рабочее ПО для этого. Мы у себя используем Nexus, которые умеет кешировать и проксировать много чего. чт, 23 нояб. 2023 г. в 16:24, Илья Шипицин : > есть же прямо специализированные кеширующие прокси для, какой смысл > кулибинствовать на уровне http ? > тем более, что там куча POST запросов, которые не могут кешироваться > > чт, 23 нояб. 2023 г. в 12:29, Eugene Prokopiev >: > >> Здравствуйте! >> >> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и >> гуглится куча примеров, как это сделать >> >> Но смущает, что во всех примерах используются директивы proxy_cache*, >> а мне более удобным кажется proxy_store - в этом случае кэш >> раскладываются по файлам аналогично оригиналу, понятно где, что и >> сколько места занимает, легко вручную удалить часть кэша и т.д. >> >> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или >> лучше?) proxy_cache*? >> >> -- >> WBR, >> Eugene Prokopiev >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx-ru >> > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > -- P.S. Сохраняйте переписку в теле письма. ___________________________________ Best regards, Konstantin @MihaKot@ Aksarin. Phone: +7 921 74 66 818 Skype: mihakot E-mail: mihakot на gmail.com ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.prokopiev на gmail.com Thu Nov 23 14:24:51 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Thu, 23 Nov 2023 17:24:51 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: Message-ID: Ну так оглавление, ссылающееся на новые файлы ( а старые при этом остаются доступными) - это кажется фичей, а не багом, разве нет? Другие варианты смотрел, но с монстрами типа artifactory/sonatype связываться не хочется (там еще и куча ограничений в свободных версиях), а с зоопарком reposilite/devpi/verdaccio тоже чт, 23 нояб. 2023 г. в 15:22, Vladislav Shabanov : > > Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать сложнее. > Посмотрите: > > https://verdaccio.org/docs/best > https://www.sonatype.com/products/sonatype-nexus-oss-download > > Владислав > > 23 нояб. 2023 г., в 14:31, Eugene Prokopiev написал(а): > > Здравствуйте! > > Есть задача кэширования репозиториев maven/pypi/npm для разработки - и > гуглится куча примеров, как это сделать > > Но смущает, что во всех примерах используются директивы proxy_cache*, > а мне более удобным кажется proxy_store - в этом случае кэш > раскладываются по файлам аналогично оригиналу, понятно где, что и > сколько места занимает, легко вручную удалить часть кэша и т.д. > > Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или > лучше?) proxy_cache*? > > -- > WBR, > Eugene Prokopiev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- WBR, Eugene Prokopiev From eugene.prokopiev на gmail.com Thu Nov 23 14:27:19 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Thu, 23 Nov 2023 17:27:19 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: Message-ID: Нету там POST - даже у самого замороченного npm, а у maven/pypi и метаданных-то толком нет - это примитивные файлопомойки, которые даже на S3 держать тожно чт, 23 нояб. 2023 г. в 16:24, Илья Шипицин : > > есть же прямо специализированные кеширующие прокси для, какой смысл кулибинствовать на уровне http ? > тем более, что там куча POST запросов, которые не могут кешироваться -- WBR, Eugene Prokopiev From vlad.shabanov на gmail.com Thu Nov 23 14:56:23 2023 From: vlad.shabanov на gmail.com (Vladislav Shabanov) Date: Thu, 23 Nov 2023 17:56:23 +0300 Subject: =?utf-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C4?= =?utf-8?B?0YLQvtGA0LjQtdCyIG1hdmVuL3B5cGkvbnBtIC0gcHJveHlfY2FjaGUg0Lg=?= =?utf-8?B?0LvQuCBwcm94eV9zdG9yZQ==?= In-Reply-To: References: Message-ID: <2C5F6C4D-65EA-4EAE-BB83-51BD2858AB26@gmail.com> Ну, как устроена реальная жизнь: День 1: программисты хотят 10 пакетов, вместе с зависимостями это, допустим, 182 штуки. Во время «вместе с зависимостями» было сколько-то обращений к оглавлению за метаданными. Допустим, они все GET и настолько простые, что их можно закэшировать не вникая. Закэшировали запросы к метаданным и сами 10+182=192 пакета. День N: программисты захотели ещё 1 пакет добавить. Мигрировать на свежие версии предыдущих 10 пакетов (или предыдущих 192, если вместе с зависимостями) не хотят, это отдельное упражнение. Опять пошли GET-запросы к метаданным, наш новый пакет хочет ещё 5 штук новых и 12 штук из тех, предыдущих 182, но в более свежих версиях, хотя старые тоже подошли бы. Если смогли так обмануть исходный репозиторий, чтобы эти запросы выдали 12 старых пакетов именно в закэшированных версиях, то повезло. А если протокол обращения к репозиторию к этому не пригоден, то не повезло, придётся тащить все 12 новых версий пакетов тоже. Начинается субботник. В JS он частично лечится через packages-lock, в питоне надо немного повозиться, в других языках тоже обязательно надо повозиться. День M: захотели ещё пакет, наш кэш усердно обманывает, чтобы при ходьбе по зависимостям выдавать, что более свежих версий наших 182 пакетов нету. Но вот новый пакет активно хочет более свежую версию, у него в метаданных прописана совместимость >= n.m.k. Тут новый вид попадалова, когда кэши надо всё-таки выкинуть и всё скачать заново. Причём в этом «всё скачать» исходный репозиторий вам присунет все 182 обновлённых пакета, и ещё пару десятков новых пакетов. А вы хотели выборочно обновить только то, что действительно нужно, а глобальный субботник снова хотели «на потом». Короче, идея просто кэшировать постепенно превращается в https://www.youtube.com/watch?v=V5RQh5tNcbo Вообще, всё от постановки задачи зависит. Если «хочу чтоб в военное время можно было кэшированными версиями пакетов сервер залить, понимаю, что новых версий после начала войны брать из-за океана не буду», то простого кэширования достаточно. Если «хочу сам, выборочно вбирать в себя новшества, читая диффы, откладывая на потом странные обновления и втаскивая полезные», то не вникая в логику репозитория этого не сделать. Влад > 23 нояб. 2023 г., в 17:24, Eugene Prokopiev написал(а): > > Ну так оглавление, ссылающееся на новые файлы ( а старые при этом > остаются доступными) - это кажется фичей, а не багом, разве нет? > > Другие варианты смотрел, но с монстрами типа artifactory/sonatype > связываться не хочется (там еще и куча ограничений в свободных > версиях), а с зоопарком reposilite/devpi/verdaccio тоже > > чт, 23 нояб. 2023 г. в 15:22, Vladislav Shabanov : >> >> Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать сложнее. >> Посмотрите: >> >> https://verdaccio.org/docs/best >> https://www.sonatype.com/products/sonatype-nexus-oss-download >> >> Владислав >> >> 23 нояб. 2023 г., в 14:31, Eugene Prokopiev написал(а): >> >> Здравствуйте! >> >> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и >> гуглится куча примеров, как это сделать >> >> Но смущает, что во всех примерах используются директивы proxy_cache*, >> а мне более удобным кажется proxy_store - в этом случае кэш >> раскладываются по файлам аналогично оригиналу, понятно где, что и >> сколько места занимает, легко вручную удалить часть кэша и т.д. >> >> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или >> лучше?) proxy_cache*? >> >> -- >> WBR, >> Eugene Prokopiev >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> > > > -- > WBR, > Eugene Prokopiev ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Nov 23 15:35:48 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 23 Nov 2023 16:35:48 +0100 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: Message-ID: я передумал )) выглядит как безобидный способ убить кучу времени. но почему бы и нет чт, 23 нояб. 2023 г. в 15:25, Eugene Prokopiev : > Нету там POST - даже у самого замороченного npm, а у maven/pypi и > метаданных-то толком нет - это примитивные файлопомойки, которые даже > на S3 держать тожно > > чт, 23 нояб. 2023 г. в 16:24, Илья Шипицин : > > > > есть же прямо специализированные кеширующие прокси для, какой смысл > кулибинствовать на уровне http ? > > тем более, что там куча POST запросов, которые не могут кешироваться > > -- > WBR, > Eugene Prokopiev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Sat Nov 25 00:59:57 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 25 Nov 2023 03:59:57 +0300 Subject: =?koi8-r?B?8MHU3iBFVGFncyDX?= NixOS In-Reply-To: <1053893616.20231121215316@gmail.com> References: <441659217.20231119161542@gmail.com> <1053893616.20231121215316@gmail.com> Message-ID: Hello! On Tue, Nov 21, 2023 at 09:53:16PM +0300, izorkin на gmail.com wrote: > Да, этот патч, забыл указать ссылку. > Проверил без патча и добавлением строки `add_header Last-Modified "";` > В ответе генерируется ETag: "1-4e", "1-75" и т.д. Если после изменения > содержимого файла без изменения размера, то при запросе отдаётся файл > из кеша, т.к. при этом ETag не изменяется. А если размер файла меняется, > кеш обновляется. > Вариант с использованием хеадера Last-Modified не подходит, может надо > как-то учитывать путь к файлу для генерации ETag. Если размера для идентификации версии файла недостаточно, то ожидаемо нужны другие идентификаторы. В классических файловых системах таким идентификатором выступает время модификации файла. В /nix/store, как я понимаю, идея состоит в том, что время модификации не нужно, потому что файлы в рамках конкретного пути не меняются. Решением, целиком повторяющим эту идею, будет использование полного пути из /nix/store в URI, тогда всё будет работать так, как ожидают создатели /nix/store. Если же хочется выкинуть из URI полный путь, то наверное имеет смысл думать в сторону возможности установки ETag'а из переменных (сейчас его можно поменять в ответе клиенту, но это происходит после проверок If-Modified-Since / If-None-Match, и выставленное значение не используется самим nginx'ом). Тогда можно будет поставить и использовать произвольный ETag, основываясь, например, на переменной $realpath_root - то есть сделать штатными средствами примерно то же, что пытались накостылить авторы соответствующего патча в NixOS. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Sat Nov 25 09:57:45 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sat, 25 Nov 2023 12:57:45 +0300 Subject: =?utf-8?B?UmU6INCf0LDRgtGHIEVUYWdzINCyIE5peE9T?= In-Reply-To: References: <441659217.20231119161542@gmail.com> <1053893616.20231121215316@gmail.com> Message-ID: <179919879.20231125125745@gmail.com> Здравствуйте, Максим. Вариант использования полного пути в URI выглядит не очень удобно. Второй вариант с использованием `$realpath_root` работает, но как сделать так, чтобы генерировался хэш от значения `$realpath_root`, в противном случае отображается для всех полный путь к файлу, не думаю, что такой вариант не безопасен: add_header ETag $realpath_root; К тому же это надо дополнительно везде прописывать add_header, пользователь легко может упустить в конфигурации места, где надо его изменить. Судя по коду в src/http/ngx_http_core_module.c для генерации ETag используется только время модификации файла и его размер. А вот путь до файл не учитывается. Как можно попробовать добавить возможность учитывать полный путь до файла для проверки? Может подойдёт такой вариант: ETag = путь к файлу + размер файла + время модификации файла. Если подойдёт, тогда всё будет работать автоматически. Вы писали 25 ноября 2023 г., 3:59:57: > Hello! > On Tue, Nov 21, 2023 at 09:53:16PM +0300, izorkin на gmail.com wrote: > Если размера для идентификации версии файла недостаточно, то > ожидаемо нужны другие идентификаторы. В классических файловых > системах таким идентификатором выступает время модификации файла. > В /nix/store, как я понимаю, идея состоит в том, что время > модификации не нужно, потому что файлы в рамках конкретного пути > не меняются. Решением, целиком повторяющим эту идею, будет > использование полного пути из /nix/store в URI, тогда всё будет > работать так, как ожидают создатели /nix/store. > Если же хочется выкинуть из URI полный путь, то наверное имеет > смысл думать в сторону возможности установки ETag'а из переменных > (сейчас его можно поменять в ответе клиенту, но это происходит > после проверок If-Modified-Since / If-None-Match, и выставленное > значение не используется самим nginx'ом). Тогда можно будет > поставить и использовать произвольный ETag, основываясь, например, > на переменной $realpath_root - то есть сделать штатными средствами > примерно то же, что пытались накостылить авторы соответствующего > патча в NixOS. -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Sat Nov 25 13:32:46 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sat, 25 Nov 2023 16:32:46 +0300 Subject: =?utf-8?B?UmU6IE1pbWUtdHlwZXM6INC+0LHQvdC+0LLQu9C10L3QuNC1?= In-Reply-To: References: <9610390738.20231117100125@gmail.com> <962197451.20231118175617@gmail.com> Message-ID: <1718033751.20231125163246@gmail.com> Здравствуйте, Максим. Подойдёт такой вариант изменений? https://pastebin.com/GtuK1Qbn Вы писали 19 ноября 2023 г., 3:15:54: > Hello! > On Sat, Nov 18, 2023 at 05:56:17PM +0300, izorkin на gmail.com wrote: > Боюсь, так это не работает. Если хочется что-то добавить к > существующему списку типов в mime.types, то стоит по каждому > предлагаемому к добавлению MIME-типу расписать, что это, и зачем > это нужно в mime.types для типичного web-сайта. -- С уважением, Izorkin mailto:izorkin на gmail.com From eugene.prokopiev на gmail.com Sun Nov 26 06:53:54 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Sun, 26 Nov 2023 09:53:54 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: <2C5F6C4D-65EA-4EAE-BB83-51BD2858AB26@gmail.com> References: <2C5F6C4D-65EA-4EAE-BB83-51BD2858AB26@gmail.com> Message-ID: чт, 23 нояб. 2023 г. в 17:56, Vladislav Shabanov : > > Ну, как устроена реальная жизнь: Спасибо за интересный логрид :) Но вот как устроена наша жизнь на примере maven: День 1 - Все так, да День N - А зачем обманывать исходный репозиторий? Если версии прибиты гвоздями - выдадим то, что просили. Если что-нибудь в духе 'm.n.+' - сначала вытянем оглавление (в случае maven это файл maven-metadata.xml), в нем найдем требуемую версию и ее уже отдадим. Если в итоге в CLASSPATH попли несколько версий одной и той же библиотеки - ну значит таков путь, разработчики сами себе буратины (хотя, возможно, именно этого они и хотели - и разные класслоадеры им в помощь) День М - И снова врать нехорошо, отдадим что просят - и непонятно зачем что-то выкидывать и скачивать заново У PyPI оглавление генерится на лету в виде HTML, но если мы знаем точные версии пакетов (хотя python-разработчики прописывают их в requirements.txt довольно редко) - они будут выкачиваться сразу А вот мире NPM packages-lock.json в дополнение к packages.json используют почти всегда - т.е. мы снова можем выкачивать явно указанные версии, в противном случае нужно сначала GET-запросами к API-серверу их узнать Одним словом, операции "скачать пакет какой-нибудь (наверное последней) версии" ни в одном из этих трех случаев нет - и описанные безобразия в день N и день М происходить не должны - т.е. репозитории Maven/PyPI/NPM выглядят вполне пригодными для кэширования именно на уровне HTTP Тут беда приходит откуда не ждали (и к логике репозиториев отношения не имеет): location /clojars { proxy_pass https://repo.clojars.org; } curl -v http://localhost/clojars/ * Trying 127.0.0.1:80... * Connected to localhost (127.0.0.1) port 80 > GET /clojars/ HTTP/1.1 > Host: localhost > User-Agent: curl/8.4.0 > Accept: */* > < HTTP/1.1 421 Misdirected Request < Server: nginx/1.25.3 < Date: Sun, 26 Nov 2023 06:49:03 GMT < Content-Type: text/plain; charset=utf-8 < Content-Length: 297 < Connection: keep-alive < x-served-by: cache-fra-eddf8230058 < Requested host does not match any Subject Alternative Names (SANs) on TLS certificate [f38588ca7dc3f37ec048583198230295986084302bfd4d5c2d944911bd377a95] in use with this connection. Visit https://docs.fastly.com/en/guides/common-400-errors#error-421-misdirected-request for more information. * Connection #0 to host localhost left intact И что-то я не могу подобрать комбинацию из proxy_ssl_*, чтоб repo.clojars.org отдал через pass_proxy что-нибудь более вразумительное - подскажете? Да, первоначальный вопрос про proxy_store vs proxy_cache* по-прежнему актуален :) -- WBR, Eugene Prokopiev From eugene.prokopiev на gmail.com Sun Nov 26 07:03:45 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Sun, 26 Nov 2023 10:03:45 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: Message-ID: чт, 23 нояб. 2023 г. в 18:36, Илья Шипицин : > > я передумал )) > > выглядит как безобидный способ убить кучу времени. но почему бы и нет А сколько лет мы убили на JFrog Artifactory ... Начали с плагина на groovy для неподдерживаемого типа репозитория, но в итоге перевезли эту логику в OpenResty на lua, а для собственных пакетов maven/pypi/npm внезапно GitLab вполне подошел Вот теперь до кэша maven/pypi/npm руки вроде бы дошли И вы нам аналогичных граблей с Sonatype Nexus пойти пособирать предлагаете? :) -- WBR, Eugene Prokopiev From eugene.prokopiev на gmail.com Sun Nov 26 07:34:34 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Sun, 26 Nov 2023 10:34:34 +0300 Subject: 421 Misdirected Request via pass_proxy Message-ID: Здравствуйте! Не получается спроксировать repo.clojars.org: location /clojars { proxy_pass https://repo.clojars.org; } curl -v http://localhost/clojars/ ... < HTTP/1.1 421 Misdirected Request ... < Requested host does not match any Subject Alternative Names (SANs) on TLS certificate [f38588ca7dc3f37ec048583198230295986084302bfd4d5c2d944911bd377a95] in use with this connection. Visit https://docs.fastly.com/en/guides/common-400-errors#error-421-misdirected-request for more information. * Connection #0 to host localhost left intact Нагуглил в этой же рассылке волшебную директиву proxy_ssl_server_name on - но получается совсем странная вещь - на localhost/clojars/ мне уже отдают 200, но в теле совсем не тот html, что на оригинальном repo.clojars.org Как это может быть и чего еще может не хватать? -- WBR, Eugene Prokopiev From bgx на protva.ru Sun Nov 26 07:33:11 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sun, 26 Nov 2023 10:33:11 +0300 Subject: =?utf-8?B?0JrRjdGI0LjRgNC+0LLQsNC90Lg=?= =?utf-8?B?0LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIG1hdmVuL3B5cGkvbnBtIC0g?= =?utf-8?B?cHJveHlfY2FjaGUg0LjQu9C4?= proxy_store In-Reply-To: References: <2C5F6C4D-65EA-4EAE-BB83-51BD2858AB26@gmail.com> Message-ID: On Sun, Nov 26, 2023 at 09:53:54AM +0300, Eugene Prokopiev wrote: > Requested host does not match any Subject Alternative Names (SANs) on > TLS certificate > [f38588ca7dc3f37ec048583198230295986084302bfd4d5c2d944911bd377a95] in > use with this connection. > > Visit https://docs.fastly.com/en/guides/common-400-errors#error-421-misdirected-request > for more information. > * Connection #0 to host localhost left intact > > И что-то я не могу подобрать комбинацию из proxy_ssl_*, чтоб > repo.clojars.org отдал через pass_proxy что-нибудь более > вразумительное - подскажете? Прочесть текст по ссылке? Там речь не про параметры ssl, однако. -- Eugene Berdnikov From eugene.prokopiev на gmail.com Sun Nov 26 07:43:13 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Sun, 26 Nov 2023 10:43:13 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: <2C5F6C4D-65EA-4EAE-BB83-51BD2858AB26@gmail.com> Message-ID: вс, 26 нояб. 2023 г. в 10:33, Evgeniy Berdnikov : > Прочесть текст по ссылке? Там речь не про параметры ssl, однако. Если я правильно читаю этот текст, то там про: proxy_set_header Host repo.clojars.org и возможно про: proxy_ssl_name repo.clojars.org; но с этими параметрами я по-прежнему получаю 421 и уже с proxy_ssl_server_name on наконец 200 - но с совершенно неожиданным http body (см. новую ветку - т.к. это уже явно не про репозитории) -- WBR, Eugene Prokopiev From bgx на protva.ru Sun Nov 26 07:58:23 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sun, 26 Nov 2023 10:58:23 +0300 Subject: =?utf-8?B?0JrRjdGI0LjRgNC+0LLQsNC90Lg=?= =?utf-8?B?0LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIG1hdmVuL3B5cGkvbnBtIC0g?= =?utf-8?B?cHJveHlfY2FjaGUg0LjQu9C4?= proxy_store In-Reply-To: References: <2C5F6C4D-65EA-4EAE-BB83-51BD2858AB26@gmail.com> Message-ID: On Sun, Nov 26, 2023 at 10:43:13AM +0300, Eugene Prokopiev wrote: > и уже с proxy_ssl_server_name on наконец 200 - но с совершенно > неожиданным http body (см. новую ветку - т.к. это уже явно не про > репозитории) Навскидку: удалить Via:, X-Forwarded-For:, X-Real-IP: и прочие свитедельства проксирования, если они есть. Что именно отправляется, можно найти в debug log'е, если я правильно помню... Ну и кроме того могут быть засады с User-Agent:, т.к. желающие убить всех ботов частенько превращаются в настоящих маньяков. -- Eugene Berdnikov From mdounin на mdounin.ru Mon Nov 27 03:54:41 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 27 Nov 2023 06:54:41 +0300 Subject: 421 Misdirected Request via pass_proxy In-Reply-To: References: Message-ID: Hello! On Sun, Nov 26, 2023 at 10:34:34AM +0300, Eugene Prokopiev wrote: > Здравствуйте! > > Не получается спроксировать repo.clojars.org: > > location /clojars { > proxy_pass https://repo.clojars.org; > } > > curl -v http://localhost/clojars/ > ... > < HTTP/1.1 421 Misdirected Request > ... > < > Requested host does not match any Subject Alternative Names (SANs) on > TLS certificate > [f38588ca7dc3f37ec048583198230295986084302bfd4d5c2d944911bd377a95] in > use with this connection. > > Visit https://docs.fastly.com/en/guides/common-400-errors#error-421-misdirected-request > for more information. > * Connection #0 to host localhost left intact > > Нагуглил в этой же рассылке волшебную директиву proxy_ssl_server_name > on - но получается совсем странная вещь - на localhost/clojars/ мне > уже отдают 200, но в теле совсем не тот html, что на оригинальном > repo.clojars.org > > Как это может быть и чего еще может не хватать? У вас в конфиге написано: proxy_pass https://repo.clojars.org; То есть проксирование без изменения URI (note: после имени хоста в proxy_pass ничего нет). Соответственно запрос к http://localhost/clojars/ будет возвращать то, что в норме возвращают по адресу https://repo.clojars.org/clojars/. Вероятно, вы вместо этого хотели получить то, что в корне repo.clojars.org. Правильная конфигурация для этого будет какая-то такая: location /clojars/ { proxy_pass https://repo.clojars.org/; proxy_ssl_server_name on; } То есть: - proxy_ssl_server_name, так как Fastly, судя по всему, всегда хочет SNI, в то время как nginx по умолчанию SNI не посылает (см. http://nginx.org/r/proxy_ssl_server_name/ru); - "location /clojars/" (note: "/" в конце), чтобы в него не попадали запросы вроде /clojars-foobar, а только запросы к /clojars/<что-то> (а запросы к /clojars перенаправлялись на /clojars/, подробнее см. http://nginx.org/r/location/ru); - и "proxy_pass https://repo.clojars.org/;" (note: "/" в конце), чтобы nginx при проксировании менял URI запроса, заменяя "/clojars/" на "/" (см. http://nginx.org/r/proxy_pass/ru). -- Maxim Dounin http://mdounin.ru/ From eugene.prokopiev на gmail.com Mon Nov 27 06:32:23 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Mon, 27 Nov 2023 09:32:23 +0300 Subject: 421 Misdirected Request via pass_proxy In-Reply-To: References: Message-ID: Максим, большое спасибо за подробный ответ - у меня все заработало, как и требовалось пн, 27 нояб. 2023 г. в 06:54, Maxim Dounin : > > Hello! -- WBR, Eugene Prokopiev From eugene.prokopiev на gmail.com Wed Nov 29 09:33:10 2023 From: eugene.prokopiev на gmail.com (Eugene Prokopiev) Date: Wed, 29 Nov 2023 12:33:10 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0LjQtdCyIA==?= =?UTF-8?B?bWF2ZW4vcHlwaS9ucG0gLSBwcm94eV9jYWNoZSDQuNC70LggcHJveHlfc3RvcmU=?= In-Reply-To: References: <2C5F6C4D-65EA-4EAE-BB83-51BD2858AB26@gmail.com> Message-ID: вс, 26 нояб. 2023 г. в 09:53, Eugene Prokopiev : > > чт, 23 нояб. 2023 г. в 17:56, Vladislav Shabanov : > > > > Ну, как устроена реальная жизнь: > > Спасибо за интересный логрид :) Но вот как устроена наша жизнь на примере maven: И все же не совсем так ... Небольшой итог для истории: Есть примеры как сделать кэш для maven/pypi/npm с помощью proxy_cache_*: * https://weblog.lkiesow.de/20170413-nginx-as-fast-maven-repository-proxy.html) * https://github.com/hauntsaninja/nginx_pypi_cache/blob/master/nginx.conf * https://gist.github.com/dctrwatson/5785675 Все они более-менее рабочие (для npm не очень, не хватает sub_filter*, но его можно утащить из примера для pypi) Все они используют proxy_cache* с гибкими настройками параметров кэширования - но мне это не очень удобно, т.к. кэш получается вещью в себе, его нельзя использовать как репозиторий непосредственно А хочется чего-то в духе https://www.altlinux.org/APT_%D0%B2_ALT_Linux/NginxAsCache - т.е. возможности использовать кэш как обычный репозиторий (с помощью proxy_store) Это аналогичным образом работает для maven/pypi/npm - могу показать конфиги, но там ничего сверхестественного Однако возникает проблема с оглавлением - proxy_store просто не скачает его еще раз, если оно уже есть - и значит о последних версиях пакетов мы ничего не узнаем Эта проблема лечится двумя способами: * Удаляем (или откладываем в сторону на всякий случай) оглавление по расписанию (например, каждую ночь) * Не кэшируем оглавление вообще и собираем его в тот момент, когда нам потребовалось использовать кэш как обычный репозиторий Проще всего собрать оглавление для pypi - https://packaging.python.org/en/latest/guides/hosting-your-own-index/#manual-repository Сгенерировать maven-metadata.xml для maven и правильно ответить на GET /{package_name} для npm тоже можно - но мороки уже больше Так что artifactory/nexus не совсем уж зря едят свой хлеб - для кэширования репозиториев maven/pypi/npm требуется хотя бы минимальное понимание логики их работы -- WBR, Eugene Prokopiev