Добрый день!
Пытаюсь запустить правило:
rewrite ^([^.\?]*[^/])$ $1/ permanent;
Оно должно добавлять / в конец запроса в случае, если в нем не содержится
. или ? и оно не оканчивается на /
Nginx отрабатывает только . и /:
* qwerty - qwerty/
* qwe.rty - qwe.rty
* qwe?rty - qwe/?rty !!!
В
Все верно оно делает. В запросе НЕТ знаков вопроса. Ибо это разделитель
между строкой запроса и аргументами.
2014-01-27 foboss nginx-fo...@nginx.us
Добрый день!
Пытаюсь запустить правило:
rewrite ^([^.\?]*[^/])$ $1/ permanent;
Оно должно добавлять / в конец запроса в случае, если в нем
Спасибо!
Подскажите, как правильно поступить в данном случае?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246849,246852#msg-246852
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Есть переменная $is_args. Но как это правильнее к вашей задаче
прикрутить... Я бы в лоб сделал - через if.
2014-01-27 foboss nginx-fo...@nginx.us
Спасибо!
Подскажите, как правильно поступить в данном случае?
Posted at Nginx Forum:
Здравствуйте, Михаил.
UP
--
С уважением,
Михаил mailto:postmas...@softsearch.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Да, все получилось. Итог таков:
if ($is_args = ) {
rewrite ^([^.]*[^/])$ $1/ permanent;
}
Спасибо еще раз!
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246849,246855#msg-246855
___
nginx-ru mailing list
nginx-ru@nginx.org
Вот такое редко проскакивает в логах. Что это может значить? Нашёл на одном
ресурсе описание ошибки 71. Привожу цитату:
Очень частый случай это когда веб-сервер вместо ответа просто посылает FIN,
потому что на его стороне воркер упал или что еще нехорошее
Posted at Nginx Forum:
Hello!
On Mon, Jan 27, 2014 at 04:54:39AM -0500, skeletor wrote:
Вот такое редко проскакивает в логах. Что это может значить? Нашёл на одном
ресурсе описание ошибки 71. Привожу цитату:
Очень частый случай это когда веб-сервер вместо ответа просто посылает FIN,
потому что на его стороне
Спасибо за ответ, Максим. ОС - Solaris 11
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246857,246865#msg-246865
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Hello!
On Mon, Jan 27, 2014 at 08:20:03AM -0500, skeletor wrote:
Спасибо за ответ, Максим. ОС - Solaris 11
О, операционная система для сильных духом. Узнаете, почему
Solaris делает так - расскажете. :)
--
Maxim Dounin
http://nginx.org/
___
Hello!
On Mon, Jan 27, 2014 at 01:03:24PM +0400, Михаил Монашёв wrote:
Здравствуйте, Михаил.
UP
Миша, проблемы вида у меня в подполе раздаётся подземный стук -
они малопригодны для анализа.
Умозрительно - скорее всего в тех кешах, что начали уменьшаться,
по каким-то причинам оказалось
Здравствуйте, Maxim.
Умозрительно - скорее всего в тех кешах, что начали уменьшаться, по
каким-то причинам оказалось много неактивных элементов, и cache
manager был занят их чисткой (и посему не следил за размером того
кеша, что начал в результате расти). Такого можно добиться,
Добрый день. Столкнулся с проблемой, когда срабатывает proxy_read_timeout
еще до получения какого-либо ответа от бакэнда.
Ситуация такая: есть скрипт, который отправляет POST данные на локальный
nginx, который проксирует запрос на upstream backend и получает ответ.
Сначала причиной таймаута
Hello!
On Mon, Jan 27, 2014 at 03:36:30AM -0500, misha_shar53 wrote:
Не могу переслать ответ браузеру.
NGINX настроен на передачу сообщений в прокси программу.
server {
listen 4330;
location / {root html; index index.html index.htm;}
location /exo {
proxy_pass
Hello!
On Mon, Jan 27, 2014 at 10:58:31AM -0500, nginx_problem wrote:
Добрый день. Столкнулся с проблемой, когда срабатывает proxy_read_timeout
еще до получения какого-либо ответа от бакэнда.
[...]
Подскажите, нормальная ли это работа proxy_read_timeout и он действительно
включается даже
Hello!
On Mon, Jan 27, 2014 at 07:49:30PM +0400, Михаил Монашёв wrote:
Здравствуйте, Maxim.
Умозрительно - скорее всего в тех кешах, что начали уменьшаться, по
каким-то причинам оказалось много неактивных элементов, и cache
manager был занят их чисткой (и посему не следил за
В таком случае proxy_read_timeout нужно устанавливать по максимальному
времени выполнения задачи на бекенде?
Дело в том, что мы столкнулись с проблемой, когда один из бекендов принимал
соединение, но не выполнял задачу (или выполнял ее неверно) и никогда не
отвечал обратно, в итоге часть задач
Hello!
On Mon, Jan 27, 2014 at 02:17:27AM -0500, paulstrong wrote:
Спасибо за ответ! Если есть возможность, ответьте тогда, исходя из вашего
опыта. Встречались ли вам подобные решения? Получается, при добавлении
нового server_name, необходимо делать reload? Как себя поведет nginx под
On Monday 27 January 2014 12:05:13 nginx_problem wrote:
[..]
Небольшой процент запросов требует большого (от 5 до 10 минут) времени
выполнения задачи на бекенде, поэтому, выставляя proxy_read_timeout по
минимуму, чтобы отсеять соединения с нерабочим бекендом, мы потеряем часть
легитимных
26.01.2014 9:55, Vadim A. Misbakh-Soloviov пишет:
Подскажите пожалуйста, в каких направлениях искать причину проблемы.
На сколько могу судить я, не будучи разработчиком NginX, никакой проблемы
здесь нет. Если тестировать ТОЛЬКО выполнение PHP-скриптов с проксированием и
без, то логически
20 matches
Mail list logo
