Re: nginx error_page 200
Можно делать "предзапрос" в томкат с помощью auth_request По результатам запроса менять бэкенд в который пойдёт запрос: либо в томкат, либо в "заглушку". Вероятно, можно даже кэшировать ответы, чтобы не насиловать томкат двойной нагрузкой. On 14.08.2019 19:48, Alexander Titaev wrote: Здравствуйте, Nginx-ru. у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с явой, сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот никак не соображу как этот перехват сделать. Возможно-ли это в принципе? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как сделать бессрочный кеш большого объема?
Я бы посмотрел на proxy_store. В одном локейшене try_files, в другом - proxy_store. Запросы во второй попадают если try_files не нашёл нужный файл или если нужно обновить контент принудительно. On 04.03.2019 15:09, tolyan wrote: Упс, прошу прощения, нашел ошибку, сейчас кеширует норм. Буду дальше разбираться с очиской кеша. К сожалению не нашел тут кнопки удалить или отредактировать пост. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283261,283262#msg-283262 ___ 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
Re: FreeBSD 11.1-RELEASE-p4 - nginx/1.15.6 accept4() ERR#35 'Resource temporarily unavailable'
Добрый день.
Отдельно любопытно, зачем вы решили проверить процесс, если всё работает.
Насколько я понимаю, сокет в неблокирующем режиме, процесс пытается
принять соединение и не успевает этого сделать (принимает другой
процесс). Процесс получает "ошибку", которая говорит процессу, что он
опоздал. Всё хорошо, можно ничего не трогать.
On 09.11.2018 20:40, actionmanager wrote:
Здравствуйте,
FreeBSD 11.1-RELEASE-p4
Связка nginx + phpfpm
nginx version: nginx/1.15.6
built by clang 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
built with OpenSSL 1.0.2k-freebsd 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_addition_module
--with-http_auth_request_module --with-http_dav_module
--with-http_flv_module --with-http_gzip_static_module
--with-http_gunzip_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module
--with-http_secure_link_module --with-http_slice_module
--with-http_stub_status_module --with-http_sub_module --with-pcre
--with-http_v2_module --with-stream=dynamic --with-stream_ssl_module
--with-stream_ssl_preread_module --with-threads --with-mail=dynamic
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --with-http_ssl_module
--with-http_geoip_module=dynamic --add-module=/root/ngx_brotli
решил проверить процесс nginx через truss
truss -p PID
Наблюдаю множество записей:
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 1.02100
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 1.01300
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.98700
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.98000
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.97300
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.96200
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.93300
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.87500
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.87100
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.80500
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 203,EVFILT_READ,EV_CLEAR|EV_EOF,0x0,0x0,0x84ec02be0
},512,{ 0.71100 }) = 1 (0x1)
close(203) = 0 (0x0)
kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.70300
}) = 1 (0x1)
accept4(0x10,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec0 },512,{ 0.68700
}) = 1 (0x1)
accept4(0xf,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec0 },512,{ 0.65300
}) = 1 (0x1)
accept4(0xf,0x7fffe7c0,0x7fffe854,0x2000) ERR#35 'Resource
temporarily unavailable'
kevent(80,{ },0,{ 213,EVFILT_READ,EV_CLEAR,0x0,0x23e,0x84ec02f20 },512,{
0.64500 }) = 1 (0x1)
read(213,"\^V\^C\^C\^B\^F\^P\0\^B\^B\^B\0{"...,33093) = 574 (0x23e)
getpid() = 76503 (0x12ad7)
write(213,"\^T\^C\^C\0\^A\^A\^V\^C\^C\0("...,51) = 51 (0x33)
read(213,0x8049e84c3,33093) ERR#35 'Resource temporarily
Re: proxy_cache_purge
Юрий,
Если нужно заместить элемент, то даже отдельный location не потребуется:
geo $bypass {
192.168.0.0/24 1;
default 0;
}
И потом:
location / {
proxy_cache zone1;
proxy_pass $upstream;
proxy_cache_bypass $bypass;
}
В таком варианте, при обращении из 192.168.0.0/24 обращение в upstream
будет мимо кэша. Но при этом, контент будет обновлён, если ответ в
принципе может быть кэширован.
Добавить в условие заголовки так же несложно. А вот аутентификация
потребует дополнительных усилий.
Так же можно сделать отдельный server{}, в котором использовать ту же
зону, с теми же location'ами и задать там любые правила доступа.
On 01.08.2018 16:48, Yury Lyakh wrote:
Звучит как-то необычно, есть пример рабочего конфига? хотя бы этого
самого специального локейшна?…
что-то не придумывается конфиг который позволит внутри nginx
принудительно обновить элемент в кеше
On 31 Jul 2018, at 13:54, Igor A. Ippolitov <mailto:iippoli...@nginx.com>> wrote:
On 31.07.2018 00:24,j...@jdwuzhere.ru <mailto:j...@jdwuzhere.ru>wrote:
On 30 Jul 2018, at 19:59, Igor A. Ippolitov <mailto:iippoli...@nginx.com>> wrote:
On 30.07.2018 14:29, Gena Makhomed wrote:
On 30.07.2018 14:06, Igor A. Ippolitov wrote:
Мне кажется, что proxy_cache_bypass легко позволяет замещать
контент в кэше (что и делает purge, в широком смысле).
Замещать существующий контент или добавлять новый - да.
Но удалять не позволяет, в этом и состоит (небольшое) отличие.
Но ведь какой-то ответ на запрос "пурженного" контента всё равно
придёт клиенту? Почему бы не закэшить сразу его.
Или условную болванку с max-age:0, которая будет обновлена по
первому же запросу от клиента
Погодите, я что-то потерялся. Есть профиль игрока, который не
меняется неделями. Nginx всю неделю (TTL кэша) радостно отдаёт
страницу профиля из этого кэша. Но однажды, игрок начинает играть в
новое и профиль необходимо обновить. Как без purge сообщить nginx,
что информация обновилась и надо сходить в backend за новой
страницей, чтобы положить её в кэш до следующего прихода?
Как бы вы делали PURGE для профиля игрока? URL профиля вы знаете.
Для PURGE вы бы "дёрнули" запрос, который удалит ненужный элемент и в
следующий раз nginx перезапросит контент с апстрима.
Этот запрос, обычно, приходит в отдельный location с нужными
настройками: ключ кэша, права доступа, всякое такое.
В моём подходе вы "дёргаете" такой же запрос в специальный location,
который ходит в апстрим мимо кэша (proxy_cache_bypass).
В разных вариациях, апстримом будет:
либо сам nginx, который отдаёт HTTP 200 и Cache-Control: max-age=0;
либо реальный апстрим, который отдаст актуальную копию данных
В первом случае контент сразу "протухает" и его актуализируют на
первом же запросе.
Во-втором - сразу актуальный.
В следущий раз, когда запросят профиль пользователя, nginx либо
пойдёт в апстрим, либо отдаст актуальную кэшированную версию.
На первый взгляд, PURGE не кажется необходимым средством. Хотя,
вероятно. может упростить жизнь в каких-то конфигурациях.
Вот поэтому и не понятно, почему нельзя сделать директиву
proxy_cache_purge доступной в open source версии nginx?
Могу ошибаться, но коммерческую версию nginx покупают скорее всего
не из-за директивы proxy_cache_purge, а ради других возможностей.
Если не прояснится - попробовать воспроизвести как минимум без
"--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди
отваживаются использовать эту поделку, она при любых внутренних
изменениях в nginx'е разносит всё же)
Если не использовать этот кривой сторонний модуль ngx_cache_purge,
то какие у пользователей open source версии nginx есть альтернативы?
Директиву proxy_cache_purge
можете сделать доступной в open source версии nginx?
P.S.
Please do not top-post.
Answer: Because it turns the discussion up-side-down.
Question: Why should I not top-post?
___
nginx-ru mailing list
nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org <mailto: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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_cache_purge
On 31.07.2018 00:24, j...@jdwuzhere.ru wrote: On 30 Jul 2018, at 19:59, Igor A. Ippolitov wrote: On 30.07.2018 14:29, Gena Makhomed wrote: On 30.07.2018 14:06, Igor A. Ippolitov wrote: Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в кэше (что и делает purge, в широком смысле). Замещать существующий контент или добавлять новый - да. Но удалять не позволяет, в этом и состоит (небольшое) отличие. Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт клиенту? Почему бы не закэшить сразу его. Или условную болванку с max-age:0, которая будет обновлена по первому же запросу от клиента Погодите, я что-то потерялся. Есть профиль игрока, который не меняется неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо обновить. Как без purge сообщить nginx, что информация обновилась и надо сходить в backend за новой страницей, чтобы положить её в кэш до следующего прихода? Как бы вы делали PURGE для профиля игрока? URL профиля вы знаете. Для PURGE вы бы "дёрнули" запрос, который удалит ненужный элемент и в следующий раз nginx перезапросит контент с апстрима. Этот запрос, обычно, приходит в отдельный location с нужными настройками: ключ кэша, права доступа, всякое такое. В моём подходе вы "дёргаете" такой же запрос в специальный location, который ходит в апстрим мимо кэша (proxy_cache_bypass). В разных вариациях, апстримом будет: либо сам nginx, который отдаёт HTTP 200 и Cache-Control: max-age=0; либо реальный апстрим, который отдаст актуальную копию данных В первом случае контент сразу "протухает" и его актуализируют на первом же запросе. Во-втором - сразу актуальный. В следущий раз, когда запросят профиль пользователя, nginx либо пойдёт в апстрим, либо отдаст актуальную кэшированную версию. На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. Вот поэтому и не понятно, почему нельзя сделать директиву proxy_cache_purge доступной в open source версии nginx? Могу ошибаться, но коммерческую версию nginx покупают скорее всего не из-за директивы proxy_cache_purge, а ради других возможностей. Если не прояснится - попробовать воспроизвести как минимум без "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди отваживаются использовать эту поделку, она при любых внутренних изменениях в nginx'е разносит всё же) Если не использовать этот кривой сторонний модуль ngx_cache_purge, то какие у пользователей open source версии nginx есть альтернативы? Директиву proxy_cache_purge можете сделать доступной в open source версии nginx? P.S. Please do not top-post. Answer: Because it turns the discussion up-side-down. Question: Why should I not top-post? ___ 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_cache_purge
On 30.07.2018 14:29, Gena Makhomed wrote: On 30.07.2018 14:06, Igor A. Ippolitov wrote: Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в кэше (что и делает purge, в широком смысле). Замещать существующий контент или добавлять новый - да. Но удалять не позволяет, в этом и состоит (небольшое) отличие. Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт клиенту? Почему бы не закэшить сразу его. Или условную болванку с max-age:0, которая будет обновлена по первому же запросу от клиента На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. Вот поэтому и не понятно, почему нельзя сделать директиву proxy_cache_purge доступной в open source версии nginx? Могу ошибаться, но коммерческую версию nginx покупают скорее всего не из-за директивы proxy_cache_purge, а ради других возможностей. Если не прояснится - попробовать воспроизвести как минимум без "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди отваживаются использовать эту поделку, она при любых внутренних изменениях в nginx'е разносит всё же) Если не использовать этот кривой сторонний модуль ngx_cache_purge, то какие у пользователей open source версии nginx есть альтернативы? Директиву proxy_cache_purge можете сделать доступной в open source версии nginx? P.S. Please do not top-post. Answer: Because it turns the discussion up-side-down. Question: Why should I not top-post? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Хотел бы сделать такие правила для SSL:
Сергей,
Если очень нужно, есть вариант использовать stream модуль для
определения протокола, который хочет/может клиент.
И в зависимости от клиента уже проксировать в разные бэкенды, где
терминировать SSL.
Вариантов как это сделать два:
1) можно запатчить ssl preread, чтобы он экспортил переменные с
протоколом. Теоретически, патч будет несложным (client hello уже
разбирается для получения SNI)
2) с помощью nsj попарсить поступающие данные, чтобы установить
переменную, по которой определить бэкенд (
http://nginx.org/ru/docs/stream/ngx_stream_js_module.html#js_preread )
Оба вариант, скажем, далеки от идеала, но результата достичь позволяют.
On 28.03.2018 19:06, Дугин Сергей wrote:
Здравствуйте, Maxim.
У того же яндекса, видно что есть свой порядок
https://www.ssllabs.com/ssltest/analyze.html?d=m.market.yandex.ru=87.250.250.22
для SSL3 у них
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_SHA
для для других протоколов другие совсем шифры.
Вот цитата сотрудников яндекса
"Наконец, для несчастных с Internet Explorer 6 на XP мы сохраняем
шифры RC4 — других вариантов на этой платформе просто нет. При этом мы
осознаем вероятность того, что этот шифр уязвим, поэтому доступен он
только в случае хендшейка по протоколу SSLv3. Если клиент подключается
с более современным протоколом — TLS 1.0, TLS 1.1 или TLS 1.2 —
ciphersuite на основе RC4 не предлагается."
Очень хотелось бы сделать похожее, но как ?
В nginx+ есть такая возможность?
и 28 марта 2018 г., 15:58:03:
Hello!
On Wed, Mar 28, 2018 at 03:38:57AM +0300, Дугин Сергей wrote:
Хотел бы сделать такие правила для SSL:
ssl_session_cache shared:TLS:10m;
ssl_session_timeout 10m;
ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.1;
ssl_prefer_server_ciphers on;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
if ($ssl_protocol ~* 'TLSv1.2')
{
ssl_ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES256-SHA384:RC4-MD5:AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA;
}
if ($ssl_protocol ~* 'TLSv1.1')
{
ssl_ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES256-SHA384:RC4-MD5:AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA;
}
if ($ssl_protocol ~* 'TLSv1')
{
ssl_ciphers
ECDHE-RSA-AES256-SHA:RC4-MD5:AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:DES-CBC3-SHA:RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA;
}
if ($ssl_protocol ~* 'SSLv3')
{
ssl_ciphers ECDHE-RSA-AES256-SHA:RC4-MD5:AES256-SHA:AES128-SHA:RC4-SHA;
}
Основная мысль на свой протокол выдавать свой список шифров, но
ssl_ciphers нельзя использовать в if условии получаю такую ошибку:
nginx: [emerg] "ssl_ciphers" directive is not allowed here in
/etc/nginx/nginx.conf:77
Подскажите как можно сделать свой порядок шифров на свой протокол?
Никак.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Proxy pass изменить ответ
Не проще ли сразу передавать запросы в CGI? Выглядеть схема будет так:
client -> nginx -> cgi -> nginx -> upstream
В этом случае, в cgi нет какой-то сверх логики кроме изменений ответов,
а выбором апстримов и работой с клиентами занимает nginx.
В схеме выше оба nginx вполне могут быть двумя server{} блоками одной
конфигурации.
On 15.04.2017 16:18, AndreyZP wrote:
Здравствуйте.
Подскажите, есть ли возможность nginx использовать как прокси и изменять
ответ.
Поясню подробнее.
На сервер пришёл запрос. При помощи proxy_pass получили ответ с другого
web-сервера.
Дальше, я хочу изменить этот ответ. Изменение может быть более сложное, чем
по регулярному выражению.
Идеально — дальше запрос переправить на мой fastcgi-скрипт, в который придут
все параметры запроса (GET например), и ответ, который дал вышестоящий
сервер (html код).
Далее, мой fastcgi скрипт (например, php через php-fpm, но не обязательно)
обрабатывает эти данные и на выходе формирует новый изменённый html, который
возвращает клиенту.
Так же, если вышестоящий сервер по какой-то причине не работает, чтобы
запрос тоже пришёл на мой fastcgi-скрипт с пометкой «ответа от вышестоящего
сервера нет, надо сформировать собственный ответ».
Возможно ли такое сделать средствами nginx?
Как-то для одного запроса последовательно исполнить директивы:
proxy_pass
потом
fastcgi_pass
чтобы на fastcgi помимо стандартных параметров, ещё и передался ответ от
proxy_pass ?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,273662,273662#msg-273662
___
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
Re: Перенаправление запроса в зависимости от ответа бекенда
http://nginx.org/ru/docs/http/ngx_http_core_module.html#error_page Не дочитал документацию: если перенаправлять в именованный location, то и метод сохранится. А адрес можно будет поменять с помощь rewrite ... break; On 13.04.2017 11:50, Igor A. Ippolitov wrote: Если вы уточните, что клиенты будут только GET'ить второй location, то можно использовать proxy_intercept_errors и error_page. А вот если вы собрались, например, POST'ить по таким же условиям, то задача приобретает вид костыля. On 13.04.2017 09:58, trace wrote: По второму пункту не нашел идей, просьба помочь. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273587,273589#msg-273589 ___ 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Перенаправление запроса в зависимости от ответа бекенда
Если вы уточните, что клиенты будут только GET'ить второй location, то можно использовать proxy_intercept_errors и error_page. А вот если вы собрались, например, POST'ить по таким же условиям, то задача приобретает вид костыля. On 13.04.2017 09:58, trace wrote: По второму пункту не нашел идей, просьба помочь. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273587,273589#msg-273589 ___ 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
Re: health_check for dynamic upstream
Попробуйте сделать апстримы в явном виде и реврайты в локейшены использующие их Реврайтить можно на основе того же map'a On 20.02.2017 17:49, Kira_Belka wrote: * I have cookies :) Вообще проблема в том что похоже что директива health_check подставляет в качестве параметра апстрима только явно подставленную апстрим группу. Есть ли варианты решения подобной траблы? разруливать на бэкенды по юзерагенту и прото и кастомному хидеру необходимо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272525,272528#msg-272528 ___ 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
