Можно делать "предзапрос" в томкат с помощью auth_request
По результатам запроса менять бэкенд в который пойдёт запрос: либо в
томкат, либо в "заглушку".
Вероятно, можно даже кэшировать ответы, чтобы не насиловать томкат
двойной нагрузкой.
On 14.08.2019 19:48, Alexander Titaev wrote:
Я бы посмотрел на proxy_store.
В одном локейшене try_files, в другом - proxy_store.
Запросы во второй попадают если try_files не нашёл нужный файл или если
нужно обновить контент принудительно.
On 04.03.2019 15:09, tolyan wrote:
Упс, прошу прощения, нашел ошибку, сейчас кеширует норм. Буду
Добрый день.
Отдельно любопытно, зачем вы решили проверить процесс, если всё работает.
Насколько я понимаю, сокет в неблокирующем режиме, процесс пытается
принять соединение и не успевает этого сделать (принимает другой
процесс). Процесс получает "ошибку", которая говорит процессу, что он
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
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, в
On 30.07.2018 14:29, Gena Makhomed wrote:
On 30.07.2018 14:06, Igor A. Ippolitov wrote:
Мне кажется, что proxy_cache_bypass легко позволяет замещать контент
в кэше (что и делает purge, в широком смысле).
Замещать существующий контент или добавлять новый - да.
Но удалять не позволяет, в этом
Сергей,
Если очень нужно, есть вариант использовать stream модуль для
определения протокола, который хочет/может клиент.
И в зависимости от клиента уже проксировать в разные бэкенды, где
терминировать SSL.
Вариантов как это сделать два:
1) можно запатчить ssl preread, чтобы он экспортил
Не проще ли сразу передавать запросы в CGI? Выглядеть схема будет так:
client -> nginx -> cgi -> nginx -> upstream
В этом случае, в cgi нет какой-то сверх логики кроме изменений ответов,
а выбором апстримов и работой с клиентами занимает nginx.
В схеме выше оба nginx вполне могут быть двумя
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:
По второму пункту не нашел идей,
Попробуйте сделать апстримы в явном виде и реврайты в локейшены
использующие их
Реврайтить можно на основе того же map'a
On 20.02.2017 17:49, Kira_Belka wrote:
* I have cookies :)
Вообще проблема в том что похоже что директива health_check подставляет в
качестве параметра апстрима только явно
11 matches
Mail list logo
