Re: lock in nginx/njs
ср, 13 мар. 2024 г. в 11:02, Andrey A. Kopeyko : > > Нужная вам функциональность есть в mod_accel. > > Но придётся через промежуточный apache проксировать. Ого, ну при таком раскладе проще взять openresty (тем более, что у меня запросы, которые нужно блокировать, не совсем идентичные) -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: lock in nginx/njs
ср, 13 мар. 2024 г. в 09:11, Dmitry Volyntsev : > А чем вас > https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock > не устраивает? > Или более подробно опишите свою задачу Мне не нужно кэшировать результаты запросов Но если запросы POST /one/0.txt и POST /two/1.txt можно выполнять параллельно, то запросы POST /one/0.txt и POST /one/1.txt нужно ставить в очередь (на основании "каталога" в $uri) и выполнять один за другим, т.к. бакенд за proxy_pass не может корректно выполнять их одновременно -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
lock in nginx/njs
Здравствуйте! Скажите, нет ли чего-нибудь похожего на https://github.com/openresty/lua-resty-lock/ в nginx/njs? Или может есть другой способ разрешить выполнять запросы с одинаковым $uri строго по очереди (один выполняется, остальные ждут)? -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store
вс, 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
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 421 Misdirected Request via pass_proxy
Максим, большое спасибо за подробный ответ - у меня все заработало, как и требовалось пн, 27 нояб. 2023 г. в 06:54, Maxim Dounin : > > Hello! -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store
вс, 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 ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
421 Misdirected Request via pass_proxy
Здравствуйте!
Не получается спроксировать 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
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store
чт, 23 нояб. 2023 г. в 18:36, Илья Шипицин : > > я передумал )) > > выглядит как безобидный способ убить кучу времени. но почему бы и нет А сколько лет мы убили на JFrog Artifactory ... Начали с плагина на groovy для неподдерживаемого типа репозитория, но в итоге перевезли эту логику в OpenResty на lua, а для собственных пакетов maven/pypi/npm внезапно GitLab вполне подошел Вот теперь до кэша maven/pypi/npm руки вроде бы дошли И вы нам аналогичных граблей с Sonatype Nexus пойти пособирать предлагаете? :) -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store
чт, 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
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store
Нету там 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
Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store
Ну так оглавление, ссылающееся на новые файлы ( а старые при этом остаются доступными) - это кажется фичей, а не багом, разве нет? Другие варианты смотрел, но с монстрами типа 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 ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store
Здравствуйте! Есть задача кэширования репозиториев 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
Re: Route by request method
Понятно, спасибо!
вт, 9 февр. 2021 г. в 17:12, Maxim Dounin :
>
> Hello!
>
> On Tue, Feb 09, 2021 at 04:40:02PM +0300, Eugene Prokopiev wrote:
>
> > Но я вот задумался: а нельзя ли прямо внутри if использовать
> > pass_proxy? Тут -
> > https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
> > указан
> > сontext: if in location - значит можно? Я попробовал - не работает. Почему?
>
> Теоретически - можно. На практике - это чревато проблемами.
> Подробный ответ на вопрос "почему" есть в статье "if is evil", она
> ещё сохранилась в остатках wiki:
>
> https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
>
> Скажем, вот такая конфигурация работает без проблем:
>
> location / {
> if ($request_method != GET) {
> proxy_pass http://127.0.0.1:8081;
> }
>
> # static
> }
>
> Но уже вот такая сделает совсем не то, что хотелось бы:
>
> location / {
> if ($request_method != GET) {
> proxy_pass http://127.0.0.1:8081;
> }
>
> set $true 1;
> if ($true) {
> # nothing
> }
>
> # static
> }
>
> Конкретно для исходной задачи наиболее простым и органичным
> решением будет, IMHO, использование limit_except, как-то так:
>
> location / {
> limit_except GET {
> proxy_pass http://127.0.0.1:8081;
> }
>
> # static
> }
>
> Но и тут есть свои нюансы: скажем, если в location'е есть
> директивы модуля rewrite, в часности - те же if'ы, то они просто
> не будут работать для запросов, попавших в блок limit_except.
>
> Ну а наиболее универсальное решение из всех возможных уже привёл
> Олег - сделать rewrite по нужному условию в другой location и там
> уже делать что угодно.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Спасибо!
Но я вот задумался: а нельзя ли прямо внутри if использовать
pass_proxy? Тут -
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
указан
сontext: if in location - значит можно? Я попробовал - не работает. Почему?
вт, 9 февр. 2021 г. в 15:52, Oleg A. Mamontov :
>
> On Tue, Feb 09, 2021 at 03:36:49PM +0300, Eugene Prokopiev wrote:
> >Всем спасибо!
> >
> >А нет ли чего-то среднего: передать запрос с помощью rewrite (это
> >выглядит чище использования фиктивного статуса, хотя явный goto был бы
> >еще чище) в именованный @location вместо internal (тогда переменная
> >request_filename будет содержать правильное значение)?
>
> Если вам хочется возвращать $uri в исходное значение, то это также
> достигается посредством rewrite, заодно тогда и trailing slash не нужен:
> ---
> location / {
> if ($request_method != 'GET') {
> rewrite ^/(.*) /proxy/$1 last;
> }
> root /data;
> }
> location /proxy/ {
> internal;
> rewrite ^/proxy/(.*) /$1 break;
> proxy_pass http://127.0.0.1:8080;
> }
> ---
>
> >вт, 9 февр. 2021 г. в 11:20, Илья Шипицин :
> >>
> >> можно на limit_except разрешить только GET. остальное попадет в запрет и
> >> навешать на него кастомную страницу ошибки
> >>
> >> вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
> >>>
> >>> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
> >>> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
> >>> >
> >>> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
> >>> >>обработку запроса в другой location. Обратите внимание - trailing slash
> >>> >>в proxy_pass в данном случае имеет значение.
> >>> >>---
> >>> >>location / {
> >>> >> if ($request_method != 'GET') {
> >>> >> rewrite ^/(.*) /proxy/$1 last;
> >>> >> }
> >>> >> root /data;
> >>> >>}
> >>> >>location /proxy/ {
> >>> >> internal;
> >>> >> proxy_pass http://127.0.0.1:8080/;
> >>> >>}
> >>> >
> >>> >Возможно переход в именованный location с помощью директив
> >>> >"error_page 418 = @location; return 418;" будет лучше
> >>> >с точки зрения читабельности, чем rewrite директивы,
> >>> >делающие конфиг nginx похожим на конфиг sendmail?
> >>>
> >>> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
> >>> с error_page лучше для решения поставленной задачи.
> >>>
> >>> Что вижу: нецелевое использование директивы / фиктивного статуса,
> >>> появление лишней строки в конфиге и необходимость включать
> >>> recursive_error_pages при использовании реальной обработки последующих
> >>> ошибок проксирования.
> >>>
> >>> Но согласен - так делать тоже можно, TMTOWTDI
> >>>
> >>> >location / {
> >>> >if ($request_method != 'GET') {
> >>> >error_page 418 = @proxy;
> >>> >return 418;
> >>> >}
> >>> >root /data;
> >>> >}
> >>> >location @proxy {
> >>> >proxy_pass http://127.0.0.1:8080;
> >>> >}
> >>> >
> >>> >По-сути вот этот набор из двух директив:
> >>> >"error_page 418 = @location; return 418;"
> >>> >означает простое действие "goto @location;"
> >>> >
> >>> >--
> >>> >Best regards,
> >>> > Gena
> >>> >
> >>> >___
> >>> >nginx-ru mailing list
> >>> >nginx-ru@nginx.org
> >>> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>>
> >>> --
> >>> Cheers,
> >>> Oleg A. Mamontov
> >>>
> >>> mailto: o...@mamontov.net
> >>>
> >>> skype: lonerr11
> >>> cell: +7 (903) 798-1352
> >>> ___
> >>> nginx-ru mailing list
> >>> nginx-ru@nginx.org
> >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >> ___
> >> nginx-ru mailing list
> >> nginx-ru@nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> >--
> >WBR,
> >Eugene Prokopiev
> >___
> >nginx-ru mailing list
> >nginx-ru@nginx.org
> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Cheers,
> Oleg A. Mamontov
>
> mailto: o...@mamontov.net
>
> skype: lonerr11
> cell: +7 (903) 798-1352
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Оказывается, это известный (и неудовлетворенный) фичреквест -
http://mailman.nginx.org/pipermail/nginx-ru/2011-October/043596.html
вт, 9 февр. 2021 г. в 15:36, Eugene Prokopiev :
>
> Всем спасибо!
>
> А нет ли чего-то среднего: передать запрос с помощью rewrite (это
> выглядит чище использования фиктивного статуса, хотя явный goto был бы
> еще чище) в именованный @location вместо internal (тогда переменная
> request_filename будет содержать правильное значение)?
>
> вт, 9 февр. 2021 г. в 11:20, Илья Шипицин :
> >
> > можно на limit_except разрешить только GET. остальное попадет в запрет и
> > навешать на него кастомную страницу ошибки
> >
> > вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
> >>
> >> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
> >> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
> >> >
> >> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
> >> >>обработку запроса в другой location. Обратите внимание - trailing slash
> >> >>в proxy_pass в данном случае имеет значение.
> >> >>---
> >> >>location / {
> >> >> if ($request_method != 'GET') {
> >> >> rewrite ^/(.*) /proxy/$1 last;
> >> >> }
> >> >> root /data;
> >> >>}
> >> >>location /proxy/ {
> >> >> internal;
> >> >> proxy_pass http://127.0.0.1:8080/;
> >> >>}
> >> >
> >> >Возможно переход в именованный location с помощью директив
> >> >"error_page 418 = @location; return 418;" будет лучше
> >> >с точки зрения читабельности, чем rewrite директивы,
> >> >делающие конфиг nginx похожим на конфиг sendmail?
> >>
> >> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
> >> с error_page лучше для решения поставленной задачи.
> >>
> >> Что вижу: нецелевое использование директивы / фиктивного статуса,
> >> появление лишней строки в конфиге и необходимость включать
> >> recursive_error_pages при использовании реальной обработки последующих
> >> ошибок проксирования.
> >>
> >> Но согласен - так делать тоже можно, TMTOWTDI
> >>
> >> >location / {
> >> >if ($request_method != 'GET') {
> >> >error_page 418 = @proxy;
> >> >return 418;
> >> >}
> >> >root /data;
> >> >}
> >> >location @proxy {
> >> >proxy_pass http://127.0.0.1:8080;
> >> >}
> >> >
> >> >По-сути вот этот набор из двух директив:
> >> >"error_page 418 = @location; return 418;"
> >> >означает простое действие "goto @location;"
> >> >
> >> >--
> >> >Best regards,
> >> > Gena
> >> >
> >> >___
> >> >nginx-ru mailing list
> >> >nginx-ru@nginx.org
> >> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >> --
> >> Cheers,
> >> Oleg A. Mamontov
> >>
> >> mailto: o...@mamontov.net
> >>
> >> skype: lonerr11
> >> cell: +7 (903) 798-1352
> >> ___
> >> nginx-ru mailing list
> >> nginx-ru@nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> WBR,
> Eugene Prokopiev
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Всем спасибо!
А нет ли чего-то среднего: передать запрос с помощью rewrite (это
выглядит чище использования фиктивного статуса, хотя явный goto был бы
еще чище) в именованный @location вместо internal (тогда переменная
request_filename будет содержать правильное значение)?
вт, 9 февр. 2021 г. в 11:20, Илья Шипицин :
>
> можно на limit_except разрешить только GET. остальное попадет в запрет и
> навешать на него кастомную страницу ошибки
>
> вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
>>
>> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
>> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
>> >
>> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
>> >>обработку запроса в другой location. Обратите внимание - trailing slash
>> >>в proxy_pass в данном случае имеет значение.
>> >>---
>> >>location / {
>> >> if ($request_method != 'GET') {
>> >> rewrite ^/(.*) /proxy/$1 last;
>> >> }
>> >> root /data;
>> >>}
>> >>location /proxy/ {
>> >> internal;
>> >> proxy_pass http://127.0.0.1:8080/;
>> >>}
>> >
>> >Возможно переход в именованный location с помощью директив
>> >"error_page 418 = @location; return 418;" будет лучше
>> >с точки зрения читабельности, чем rewrite директивы,
>> >делающие конфиг nginx похожим на конфиг sendmail?
>>
>> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
>> с error_page лучше для решения поставленной задачи.
>>
>> Что вижу: нецелевое использование директивы / фиктивного статуса,
>> появление лишней строки в конфиге и необходимость включать
>> recursive_error_pages при использовании реальной обработки последующих
>> ошибок проксирования.
>>
>> Но согласен - так делать тоже можно, TMTOWTDI
>>
>> >location / {
>> >if ($request_method != 'GET') {
>> >error_page 418 = @proxy;
>> >return 418;
>> >}
>> >root /data;
>> >}
>> >location @proxy {
>> >proxy_pass http://127.0.0.1:8080;
>> >}
>> >
>> >По-сути вот этот набор из двух директив:
>> >"error_page 418 = @location; return 418;"
>> >означает простое действие "goto @location;"
>> >
>> >--
>> >Best regards,
>> > Gena
>> >
>> >_______
>> >nginx-ru mailing list
>> >nginx-ru@nginx.org
>> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> --
>> Cheers,
>> Oleg A. Mamontov
>>
>> mailto: o...@mamontov.net
>>
>> skype: lonerr11
>> cell: +7 (903) 798-1352
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Route by request method
Здравствуйте!
Требуется по GET /data.txt отдавать самый файл как есть, а по
POST/PUT/DELETE /data.txt передавать запрос в какой-то бакенд через
proxy_pass - по идее не самый редкий кейс, но никакого пример
нагуглить не могу. Попробовал сделать так:
location / {
if ($request_method = 'GET') {
root /data;
}
proxy_pass http://127.0.0.1:8080;
}
Но в if ничего не попадает. Я что-то делаю не неправильно? Или это
вообще принято делать иначе?
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 415 Unsupported Media Type with image_filter
5 августа 2016 г., 15:26 пользователь Валентин Бартенев написал: > Очевидно разница в заголовках, которые посылает curl и Chrome. > > В итоге для браузера Chrome ваш бекенд перекодирует картинку > в webp, о чем и сообщает в ответе: > > Content-Type: image/webp > > Отключите эту функцию на бекенде или перезаписывайте заголовки. Да, proxy_pass_request_headers off решает проблему, спасибо! -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 415 Unsupported Media Type with image_filter
5 августа 2016 г., 13:02 пользователь Eugene Prokopiev написал: > Признаю свою ошибку и прикладываю два лога ... Вот теперь точно прикладываю, в прошлый раз забыл. -- WBR, Eugene Prokopiev 2016/08/05 12:33:24 [debug] 8642#8642: accept on 0.0.0.0:80, ready: 0 2016/08/05 12:33:24 [debug] 8642#8642: posix_memalign: 00E9F050:512 @16 2016/08/05 12:33:24 [debug] 8642#8642: *130 accept: 127.0.0.1:43842 fd:3 2016/08/05 12:33:24 [debug] 8642#8642: *130 event timer add: 3: 6:1470389664740 2016/08/05 12:33:24 [debug] 8642#8642: *130 reusable connection: 1 2016/08/05 12:33:24 [debug] 8642#8642: *130 epoll add event: fd:3 op:1 ev:80002001 2016/08/05 12:33:24 [debug] 8642#8642: accept on 0.0.0.0:80, ready: 0 2016/08/05 12:33:24 [debug] 8642#8642: posix_memalign: 00F1C140:512 @16 2016/08/05 12:33:24 [debug] 8642#8642: *131 accept: 127.0.0.1:43844 fd:11 2016/08/05 12:33:24 [debug] 8642#8642: *131 event timer add: 11: 6:1470389664740 2016/08/05 12:33:24 [debug] 8642#8642: *131 reusable connection: 1 2016/08/05 12:33:24 [debug] 8642#8642: *131 epoll add event: fd:11 op:1 ev:80002001 2016/08/05 12:33:24 [debug] 8642#8642: accept on 0.0.0.0:80, ready: 0 2016/08/05 12:33:24 [debug] 8642#8642: posix_memalign: 00F1C350:512 @16 2016/08/05 12:33:24 [debug] 8642#8642: *132 accept: 127.0.0.1:43846 fd:12 2016/08/05 12:33:24 [debug] 8642#8642: *132 event timer add: 12: 6:1470389664740 2016/08/05 12:33:24 [debug] 8642#8642: *132 reusable connection: 1 2016/08/05 12:33:24 [debug] 8642#8642: *132 epoll add event: fd:12 op:1 ev:80002001 2016/08/05 12:33:24 [debug] 8642#8642: *130 http wait request handler 2016/08/05 12:33:24 [debug] 8642#8642: *130 malloc: 00F12BC0:1024 2016/08/05 12:33:24 [debug] 8642#8642: *130 recv: fd:3 452 of 1024 2016/08/05 12:33:24 [debug] 8642#8642: *130 reusable connection: 0 2016/08/05 12:33:24 [debug] 8642#8642: *130 posix_memalign: 00F130F0:4096 @16 2016/08/05 12:33:24 [debug] 8642#8642: *130 http process request line 2016/08/05 12:33:24 [debug] 8642#8642: *130 http request line: "GET /im/pictures/21520448/2006a3c5_original.jpg HTTP/1.1" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http uri: "/im/pictures/21520448/2006a3c5_original.jpg" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http args: "" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http exten: "jpg" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http process request header line 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "Host: localhost" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "Connection: keep-alive" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "Cache-Control: max-age=0" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "Upgrade-Insecure-Requests: 1" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.108 Safari/537.36" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "Accept-Encoding: gzip, deflate, sdch" 2016/08/05 12:33:24 [debug] 8642#8642: *130 posix_memalign: 00EB9830:4096 @16 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http header done 2016/08/05 12:33:24 [debug] 8642#8642: *130 event timer del: 3: 1470389664740 2016/08/05 12:33:24 [debug] 8642#8642: *130 generic phase: 0 2016/08/05 12:33:24 [debug] 8642#8642: *130 rewrite phase: 1 2016/08/05 12:33:24 [debug] 8642#8642: *130 test location: "/" 2016/08/05 12:33:24 [debug] 8642#8642: *130 using configuration "/" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http cl:-1 max:1048576 2016/08/05 12:33:24 [debug] 8642#8642: *130 rewrite phase: 3 2016/08/05 12:33:24 [debug] 8642#8642: *130 post rewrite phase: 4 2016/08/05 12:33:24 [debug] 8642#8642: *130 generic phase: 5 2016/08/05 12:33:24 [debug] 8642#8642: *130 generic phase: 6 2016/08/05 12:33:24 [debug] 8642#8642: *130 generic phase: 7 2016/08/05 12:33:24 [debug] 8642#8642: *130 generic phase: 8 2016/08/05 12:33:24 [debug] 8642#8642: *130 access phase: 9 2016/08/05 12:33:24 [debug] 8642#8642: *130 access phase: 10 2016/08/05 12:33:24 [debug] 8642#8642: *130 access phase: 11 2016/08/05 12:33:24 [debug] 8642#8642: *130 post access phase: 12 2016/08/05 12:33:24 [debug] 8642#8642: *130 http init upstream, client timer: 0 2016/08/05 12:33:24 [debug] 8642#8642: *130 epoll add event: fd:3 op:3 ev:80002005 2016/08/05 12:33:24 [debug] 8642#8642: *130 http script copy: "Host: " 2016/08/05 12:33:24 [debug] 8642#8642: *130 http script var: "a2.muscache.com" 2016/08/05 12:33:24 [debug] 8642#8642: *130 http script copy: " " 2
Re: 415 Unsupported Media Type with image_filter
5 августа 2016 г., 8:48 пользователь Vadim A. Misbakh-Soloviov написал: >> $ curl -I -X HEAD > > А можно небольшой оффтопичный вопрос? Зачем вы так (процитировнао выше) > делаете? Это же ведь одно и то же > >> -I, --head Show document info only Перекочевало от -X GET (там уже есть разница) и зря, на HEAD и оригинальный сервер часто отвечает 422 Unprocessable Entity, так что лучше с GET проверять. -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 415 Unsupported Media Type with image_filter
2016-08-04 17:32 GMT+03:00 Konstantin Tokarev : > Такая ошибка обычно возникает, если nginx не может открыть исходный файл Вы правы, однако см. ответ выше: с разными HTTP-агентами поведение разное и оно воспроизводится -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 415 Unsupported Media Type with image_filter
4 августа 2016 г., 17:31 пользователь Валентин Бартенев написал: > On Thursday 04 August 2016 17:26:09 Eugene Prokopiev wrote: > [..] >> В error.log вообще ничего даже с debug (и на собранном с --debug nginx >> соответственно). Вообще nginx собран так: >> > [..] > > Так может быть только если вы не в тот error_log смотрите или не там > его сконфигурировали. Признаю свою ошибку и прикладываю два лога: 1) nginx.ok.log записан при выполнении curl -O -X GET http://localhost/im/pictures/21520448/2006a3c5_original.jpg 2) nginx.fail.log записан при попытке открыть тот же урл в Chromium (результат с Firefox похож скорее на (1)) Где-то в течении часа проблема воспроизводится практически с гарантией, потом урл открывается всеми, но не открывается еще что-нибудь. В nginx.fail.log смущает: 2016/08/05 12:33:24 [debug] 8642#8642: *130 input buf #0 2016/08/05 12:33:24 [debug] 8642#8642: *130 malloc: 00F054C0:4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 SSL_read: 4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 pipe recv chain: 4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 input buf #1 2016/08/05 12:33:24 [debug] 8642#8642: *130 malloc: 00F1C8A0:4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 SSL_read: 4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 pipe recv chain: 4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 input buf #2 2016/08/05 12:33:24 [debug] 8642#8642: *130 malloc: 00F1D8B0:4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 SSL_read: 4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 pipe recv chain: 4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 input buf #3 2016/08/05 12:33:24 [debug] 8642#8642: *130 malloc: 00F1E8C0:4096 2016/08/05 12:33:24 [debug] 8642#8642: *130 SSL_read: -1 2016/08/05 12:33:24 [debug] 8642#8642: *130 SSL_get_error: 2 2016/08/05 12:33:24 [debug] 8642#8642: *130 pipe recv chain: -2 Т.е. выглядит это как проблема на стороне a2.muscache.com, однако почему другой HTTP-агент нормально получает тот же самый файл? -- WBR, Eugene Prokopiev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
415 Unsupported Media Type with image_filter
Здравствуйте!
Требуется проксировать и обрезать картинки, пытаюсь делать так:
server {
listen 80;
server_name localhost;
location / {
proxy_pass https://a2.muscache.com;
image_filter crop 600 600;
image_filter_buffer 1000M;
}
}
Не получается:
$ curl -I -X HEAD http://localhost/im/pictures/85355503/64baa390_original.jpg
HTTP/1.1 415 Unsupported Media Type
Server: nginx
Date: Thu, 04 Aug 2016 14:13:25 GMT
Content-Type: text/html
Content-Length: 188
Connection: keep-alive
$ curl -I -X HEAD
https://a2.muscache.com/im/pictures/85355503/64baa390_original.jpg
HTTP/1.1 200 OK
Content-Type: image/jpeg
Access-Control-Expose-Headers: Content-Length
Last-Modified: Wed, 03 Aug 2016 20:10:22 UTC
X-IM2G-Akamai-Auth-Sign: QrDvx1Ja1CBCCDSGijz9Bvfccnivnuz1SYwAlbFdRaw=
X-IM2G-Akamai-Auth-Data: salt=2197993113278415406 parse=1 adapted=1
Server: Akamai Image Manager
Content-Length: 44548
Cache-Control: private, max-age=43200
Expires: Fri, 05 Aug 2016 02:15:35 GMT
Date: Thu, 04 Aug 2016 14:15:35 GMT
Connection: keep-alive
access-control-allow-methods: GET
access-control-allow-origin: *
Однако не получается не всегда, одна и та же картинка может нормально
проксироваться - и как правило так и происходит.
В error.log вообще ничего даже с debug (и на собранном с --debug nginx
соответственно). Вообще nginx собран так:
# nginx -V
nginx version: nginx/1.10.1
built with OpenSSL 1.0.2h 3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/ --conf-path=/etc/nginx/nginx.conf
--sbin-path=/usr/sbin --modules-path=/usr/lib64/nginx
--error-log-path=/var/log/nginx/nginx.error.log
--http-log-path=/var/log/nginx/nginx.log
--http-client-body-temp-path=/var/spool/nginx/tmp/client
--http-proxy-temp-path=/var/spool/nginx/tmp/proxy
--http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi
--http-uwsgi-temp-path=/var/spool/nginx/tmp/uwsgi
--http-scgi-temp-path=/var/spool/nginx/tmp/scgi
--pid-path=/var/run/nginx.pid --user=_nginx --group=_nginx
--with-cc-opt='-I /usr/include/pcre/' --with-http_ssl_module
--with-select_module --with-poll_module --with-threads --with-file-aio
--with-ipv6 --with-http_ssl_module --with-http_v2_module
--with-http_realip_module --with-http_addition_module
--with-http_xslt_module=dynamic
--with-http_image_filter_module=dynamic
--with-http_geoip_module=dynamic --with-http_sub_module
--with-http_dav_module --with-http_flv_module --with-http_mp4_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_auth_request_module --with-http_random_index_module
--with-http_secure_link_module --with-http_degradation_module
--with-http_slice_module --with-http_stub_status_module
--with-http_perl_module=dynamic --with-mail=dynamic
--with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module
--add-module=cache_purge --add-module=nginx-rtmp-module --with-debug
--with-google_perftools_module --with-md5=/usr/lib64
--with-sha1=/usr/lib64
Как диагностировать и лечить?
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
