Re: PUT access_by_lua_file
В письме от Пт, 17 апреля 2015 02:07:33 пользователь itcod написал: Илья добрый день! вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его фейлите. прикиньте, как клиент расстраивается от такого расклада )) Это спорный вопрос расстраивается или просто некоректна логика обработки ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на PUT ответил 405 (Method Not Allowed), то все некорректности по обработке кода ответа можно было бы свалить на клиента, и оповестить их разработчика. Дело в том, что, на сколько я понил проблему при описании с ваших слов, со стороны NginX всё корректно. На PUT он отвечает нельзя сразу по получении (т.е. по окончании) *запроса*. А отвечать нельзя по получении одного лишь заголовка, не дожидаясь тела — неправильно. -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
PS: У меня дежавю. прецедент вспомнился подобная тема обсуждалась в годах 1995 в fido-конференции по ifcico. Актуальность подобных холостых передач там была очень высокая, из за ограниченного кол-ва каналов передачи, их низких скоростей и высокой стоимости.. как результат реализовали обрыв подобных сессий для предотвращения излишних затрат и освобождения линий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258137#msg-258137 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как настроить редирект www, http, https между разными доменами
Предположу, что надо сделать вот так:
это
server {
listen 80;
server_name www.club.site.com club.site.com clubsite.com
www.clubsite.com;
return 301 https://$server_name$request_uri;
}
надо заменить на
server {
listen 80;
server_name www.club.site.com club.site.com clubsite.com
www.clubsite.com;
return 301 https://club.site.com$request_uri;
}
16 апреля 2015 г., 18:52 пользователь RavilK nginx-fo...@nginx.us написал:
Добрый день уважаемые формучане!
С nginx, apache ранее не приходилось сталкиваться. Поэтому учту все
замечания)))
Имеетя связка nginx + apache. nginx в качестве проски для апача.
Домен второго уровня site.com
Уже имеются рабочие 2 vhost'а - site.som, web.site.com
Все хосты привязаны к https, ssl сертификат соответственно используется
один
на домен *site.com
Запросы с www,http на site.com и web.site.com упешно перенаправлются на
https://site.com и https://web.site.com соответсвенно.
Два хоста site.com b web.site.com ранее были настроены специалистом
компаний
интегратора
Все крутится на одном сервере
Несколько дней назад была поставлена задача развернуть новый vhost который
будет именоваться далее - club.site.com
Вот теперь самое интересное:
Руководство купило доменное имя clubsite.com, именно clubsite.com
))объяснив
это тем, что, если клиент по ошибке набирает в браузере www.clubsite.com
или
просто clubsite.com,
запрос должен быть перенаправлен на https://club.site.com
Я по аналогий рабочих конфигов site.com и web.site com настроил vhost в
апач и nginx.
Для проверки посал запросы в виде www.club.site.com, http://club.site.com
,
редирект на https://club.site.com отработал нормально.
А как настроить такой же редирект с домена clubsite.com в nginx:
www.clubsite.com club.site.com
http://clubsite.com - club.site.com
Однако, я заметил одну непонятную вещь, все запросы с домена clubsite.com
уже перенаправляются, только совсем на другой хост:
www.clubsite.kg --- web.site.com
clubsite.com --- web.clubsite
Вот конфиг файлы vhost в apache и конфиг файла в nginx --
1) /apache/sites-available/club.site.conf
VirtualHost *:8083
ServerName club.site.com
ServerAlias www.club.site.com
DocumentRoot /var/www/club.site.com/
Directory /var/www/club.site.com /
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
/Directory
ErrorLog ${APACHE_LOG_DIR}/error.log
RewriteEngine on
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
/VirtualHost
2) /nginx/sites-enables/club.site.conf
server {
listen 80;
server_name www.club.site.com club.site.com clubsite.com
www.clubsite.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443;
server_name www.club.site.com www.clubsite.com clubsite.com
club.site.com;
ssl on;
ssl_certificate /etc/nginx/ssl/certs/site.com.crt;
ssl_certificate_key /etc/nginx/ssl/private/site.com.key;
location / {
proxy_temp_path /tmp/nginx_proxy/;
proxy_pass http://127.0.0.1:8083;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|txt|pdf|zip)$ {
root /var/www/club.site.com/;
}
Теперь сам вопрос господа
Как настроить такое вот перенаправление с www.clubsite.com и
http://clubsite.com на https://club.site.com
Заранее спасибо!
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258108,258108#msg-258108
___
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: PUT access_by_lua_file
Илья добрый день! вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его фейлите. прикиньте, как клиент расстраивается от такого расклада )) Это спорный вопрос расстраивается или просто некоректна логика обработки ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на PUT ответил 405 (Method Not Allowed), то все некорректности по обработке кода ответа можно было бы свалить на клиента, и оповестить их разработчика. В данном случае я вижу выше этой ошибки BitKinex по обработке кодов, некорректную с моей точки зрения обработку команды PUT у nginx. И именно по ней я пытаюсь выяснить жук это или фича такая. Если жук - то понятно, что проясняем сознание и в очередь на лечение. Если фича - то хотелось бы понять, в чём прелесть перевешивающая недостатки. Запросы методом OPTIONS при PUT: BitKinex - не использует FAR-NetDrive - использует Даже тут чехарда. Да я буду пытаться сказать клиентам, что использовать можно, а что нельзя... Только это imho косметический костыль. Так как тот кто специально решит проигнорировать рекомендации сервера (я имею в виду если кому захочется положить сервер), он всегда сможет выполнить, то что я обнаружил. А это imho с точки зрения надёжности nginx большой минус. Да и я сам делая самописный WebDAV клиент ориентировался бы больше на обаботку ответов и уже во втором эшелоне на рекомендации сервера. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258134#msg-258134 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
mva добрый день! На PUT он отвечает нельзя сразу по получении (т.е. по окончании) *запроса*. Да. вы описываете ситуацию верно... как я её вижу. 1. получение nginx'ом заголовка сообщения 2. получение тела сообщения [... lua ...] - 405 А отвечать нельзя по получении одного лишь заголовка, не дожидаясь тела — неправильно. Если не затруднит обоснуйте плиззз свою точку зрения. Моя такова: Если метод запрещён внутри (и не важно знает об этом клиент или нет), то можно и даже нужно обрывать соединение и вернуть код 405!. Зачем нам получать огромное тело сообщения, если мы не обрабатываем этот метод и не будем обрабатывать тело. Пример: Инициирую 1000-1 сессий, игнорирую рекомендации nginx в OPTION и Origin, и каждая сессия инициирует PUT video.mp4 размером скажем 4G. С большой долей вероятности положу атакуемый сервер. А даже если не положу, то заспамлю и загружу холостой работой. Следовательно при обработке PUT если сервер оборвал получение и вернул код ошибки 405 то передавать тело клиенту уже не предоставляется возможности. imho это логично и устраняет описанную в первом сообщении проблему. И отсуда вытекает вопрос к разработчикам о внутренностях nginx. существует ли возможность реализовать запуск выполнения авторизатора на lua между двумя этапами обработки. 1. получение nginx'ом заголовка сообщения [... lua ...] -405 2. УЖЕ НЕ! получаем тела сообщения Или существуют ещё какие либо более простые методы решения. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258136#msg-258136 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
limit conn счетчик переполнение
Добрый день.
Была задача ограничить кол-во запросов к бэкенду. Например, чтобы
одновременно не поступало более 1 запроса. Остальные запросы, пока работает
бэкенд, могли отваливаться по ошибке, это не страшно.
С помощью Perl я устанавливал переменную, которая показывала идет ли запрос
для проксирования на бэкенд или нет. И эту переменную использовал в качестве
ключа для
http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn_zone
perl_set $service_hit '
sub {
my $r = shift;
if($r-uri =~ m|^/services/post|){
return services;
} else {
return ;
}
}
';
limit_conn_zone $service_hit zone=perservice:10m;
Потом перед проксированием на бэкенд (в location) использовал ограничениие
http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn
limit_conn perservice 1;
Все отлично работает, но только первые 30-60 минут, потом nginx для всех
запросов возвращает 503 ошибку, т.е. счетчик не сбрасывается. Если
остановить-запустить nginx, то опять какое-то время все работает корректно.
В чем может быть проблема?
Спасибо.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258140,258140#msg-258140
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как настроить редирект www, http, https между разными доменами
Михаил спасибо за ваш ответ. Но к сожалению ничего не изменилось( Как последний вариант убрать редирект через nginx и настроить его через htaccess Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258108,258139#msg-258139 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
В письме от Пт, 17 апреля 2015 08:36:39 пользователь itcod написал: Нескромный вопрос так и оставим существовать эту PUT дырку? пока кого нибудь не заклюеет жареный петух Ну, у меня на сервере с отключенным PUT, например, 405+400 выбрасывается сразу, не получая содержимое файла. Другое же дело, когда метод фигурирует в разрешённых у сервера на более низком уровне (module_http_dav) и рулится уже в access-модуле (да ещё и в ngx_lua, что ещё дальше) ;) Т.е. ситуация такая: DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT. Сервер, следовательно, считает PUT валидным запросом. Следовательно, когда приходит PUT — он получает запрос целиком (до этого момента он валиден) и только потом, получив запрос, целиком отдаёт его дальше по цепочке в модули. Поэтому в руках ngx_lua (в access-директиве) оказывается запрос целиком. Да и в обычном, емнип, access-модуле, тоже обработка происходит ПОСЛЕ получения запроса, а не на этапе заголовков :) -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: limit conn счетчик переполнение
Hello!
On Fri, Apr 17, 2015 at 06:06:49AM -0400, dwow wrote:
Добрый день.
Была задача ограничить кол-во запросов к бэкенду. Например, чтобы
одновременно не поступало более 1 запроса. Остальные запросы, пока работает
бэкенд, могли отваливаться по ошибке, это не страшно.
С помощью Perl я устанавливал переменную, которая показывала идет ли запрос
для проксирования на бэкенд или нет. И эту переменную использовал в качестве
ключа для
http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn_zone
perl_set $service_hit '
sub {
my $r = shift;
if($r-uri =~ m|^/services/post|){
return services;
} else {
return ;
}
}
';
limit_conn_zone $service_hit zone=perservice:10m;
Just a side note: не надо делать так, вместо этого правильно
написать отдельный location, в котором и задать ограничение.
Потом перед проксированием на бэкенд (в location) использовал ограничениие
http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn
limit_conn perservice 1;
Все отлично работает, но только первые 30-60 минут, потом nginx для всех
запросов возвращает 503 ошибку, т.е. счетчик не сбрасывается. Если
остановить-запустить nginx, то опять какое-то время все работает корректно.
В чем может быть проблема?
Скорее всего проблема в том, что limit_conn органичивает не
соединения на бекенду, а активные соединения. Соответственно,
если кто-то сходил на бекенд, получил оттуда достаточно большой
ответ и неспеша забирает его у nginx'а - ограничение будет
продолжать срабатывать. Например, если клиент сделал запрос
(ответ на который не помещается в буфер сокета), после чего пропал
и на пакеты не отвечает - ограничение будет срабатывать, пока не
случится send_timeout.
--
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
mva добрый день ещё раз:) Ну, у меня на сервере с отключенным PUT, например, 405+400 выбрасывается сразу, не получая содержимое файла. А у вас это в динамике или статично прописана блокировка? если динамично поделитесь идеей плиззз... Другое же дело, когда метод фигурирует в разрешённых у сервера на более низком уровне (module_http_dav) Я пытался решить задачку на этом уровне... мня предложили порешать её в этой точке :))) http://forum.nginx.org/read.php?21,258024,258045#msg-258045 и рулится уже в access-модуле (да ещё и в ngx_lua, что ещё дальше) ;) А куда деваться я пробовал решить её на иных уровнях... а там переменные конфг не поддерживает и потому динамику не организовать Т.е. ситуация такая: DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT. Сервер, следовательно, считает PUT валидным запросом. mva можно подробнее!!! Вы хотите сказать, что если я в хидерах укажу что PUT запрещён - то nginx откажется принимать тело если поймает на входе PUT? И это произойдёт вне зависимости, будет клиент послушным мальчиком, или будет пихать пальцы во все дырки... не обращая вниание на анонсы nginx??? ВЫ В ЭТОМ УВЕРЕНЫ? Разработчика бы услышать. по этому вопросу правда ли блокирнёт или опять день на тесты выкидывать чтобы понять текущую логику поведения. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258151#msg-258151 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
ЗЫ Т.е. ситуация такая: DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT. Сервер, следовательно, считает PUT валидным запросом. а ваш коментарий про OPTIONS и PUT а если я из lua попытаюсь изменить OPTIONS то PUT для DAV-модуля будет инвалидным. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258152#msg-258152 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
если клиент говорит Expect: 100-Continue, то в этом случае вы можете ему сказать 405 сразу (или ответить 100-м кодом). без этого хедера - да, ответить можно, только получив запрос полностью 17 апреля 2015 г., 11:13 пользователь Vadim A. Misbakh-Soloviov m...@mva.name написал: В письме от Пт, 17 апреля 2015 02:07:33 пользователь itcod написал: Илья добрый день! вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его фейлите. прикиньте, как клиент расстраивается от такого расклада )) Это спорный вопрос расстраивается или просто некоректна логика обработки ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на PUT ответил 405 (Method Not Allowed), то все некорректности по обработке кода ответа можно было бы свалить на клиента, и оповестить их разработчика. Дело в том, что, на сколько я понил проблему при описании с ваших слов, со стороны NginX всё корректно. На PUT он отвечает нельзя сразу по получении (т.е. по окончании) *запроса*. А отвечать нельзя по получении одного лишь заголовка, не дожидаясь тела — неправильно. -- Best regards, mva ___ 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: PUT access_by_lua_file
А вы, всё-таки, ответьте, пожалуйста, на вопрос, почему вы не хотите убрать PUT из OPTIONS? ;) -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как настроить редирект www, http, https между разными доменами
Прошу прощения Иван!
Спасибо ща помощь!
Я пробовал уже и такое:
server {
listen 80;
server_name www.club.site.com clubsite.com www.clubsite.com;
return 301 https://club.site.com$request_uri;
}
и в .htaccess
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
и такое
RewriteCond %{HTTP_HOST} ^www.clubsite.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^clubsite.com$ [NC]
RewriteRule (.*) https://club.site.com/$1 [R=301,L]
Еще раз просмотрел все конфиг файлы и не нашел где наcтроенно
перенаправление c www.clubsite.com и www.club.site.com на web.site.com
Где может быть еще трабл?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258108,258145#msg-258145
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: limit conn счетчик переполнение
Hello!
On Fri, Apr 17, 2015 at 09:15:21AM -0400, dwow wrote:
Maxim Dounin Wrote:
---
Just a side note: не надо делать так, вместо этого правильно
написать отдельный location, в котором и задать ограничение.
вот это я не понял.
у меня так
location /services/post/ {
limit_conn perservice 1;
proxy_pass bakcend;
}
Тогда зачем у вас используется perl_set?
Если limit_conn в других location'ах не включён, то для
ограничения всех соединений в конкретном location'е - достаточно
любого константного значения.
Скорее всего проблема в том, что limit_conn органичивает не
соединения на бекенду, а активные соединения. Соответственно,
если кто-то сходил на бекенд, получил оттуда достаточно большой
ответ и неспеша забирает его у nginx'а - ограничение будет
продолжать срабатывать. Например, если клиент сделал запрос
(ответ на который не помещается в буфер сокета), после чего пропал
и на пакеты не отвечает - ограничение будет срабатывать, пока не
случится send_timeout.
Ага, и тогда через send_timeout (default: 60s), счетчик должен
декрементироваться и следующий запрос пойти на бекенд, так? Но этого не
происходит(
Если send_timeout случится - то да. Если же вдруг какой-то клиент
очерь медленно качает что-то большое - то процесс может занять
бесконечное время.
Ну и да, безусловно имеет смысл заглянуть в error log, и убедится,
что рабочие процессы не завершаются аварийно.
--
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
добавил в location конструкцию
if ($request_method = PUT) {
return 403;
}
по прежнему PUT прокачивает холостые гигобайты трафика! :(
Буду рад мыслям сообщества!
какими ещё существующими средствами nginx, можно всё таки прекратить такое
сверхлояльное поведение nginx с настырными PUT'анами:)))
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258069,258163#msg-258163
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
хотите совет? поставьте CEPH в качестве упражнения, ваши манипуляции с DAV выглядят вполне симпатично. для продакшена распределенный кластер CEPH/S3 (по сути тот же http-доступ) более крут. клиентов S3 не меньше, чем DAV документации полно, она хорошего качества, http://habrahabr.ru/company/performix/blog/218065/ 17 апреля 2015 г., 17:36 пользователь itcod nginx-fo...@nginx.us написал: Илья добрый день. если клиент говорит Expect: 100-Continue, то в этом случае вы можете ему сказать 405 сразу (или ответить 100-м кодом). Спасибо Илья. Понял принцип. без этого хедера - да, ответить можно, только получив запрос полностью Нескромный вопрос так и оставим существовать эту PUT дырку? пока кого нибудь не заклюеет жареный петух Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258148#msg-258148 ___ 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: PUT access_by_lua_file
Упростил схему.
1. из dav_methods изъял PUT
2. отключил луа авторизатор
тестил BitKinex'ом
Результат: метод PUT не блокирует nginx, хотя он запрещён в модуле DAV.
то есть всё как было. сначало принимаем большой файл, а потом говорим, что
нам этого нельзя.
server {
listen 80;
server_name dav.example.com;
server_name_in_redirect off;
access_log /var/log/nginx/dav-access.log main;
location / {
access_by_lua_file /etc/nginx/lua/auth-dav1.lua;
dav_methods DELETE COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
create_full_put_path on;
dav_access user:rw group:rw;
client_body_temp_path /opt/itcod-dav.tmp/;
client_max_body_size 0;
autoindex on;
root /opt/home/;
}
location ~/\.ht {
deny all;
}
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258069,258162#msg-258162
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: limit conn счетчик переполнение
On 17.04.2015 19:28, dwow wrote: Была задача ограничить кол-во запросов к бэкенду. Например, чтобы одновременно не поступало более 1 запроса. Если же вдруг какой-то клиент очерь медленно качает что-то большое - то процесс может занять бесконечное время. и как от таких избавляться? 1) купить платную версию NGINX Plus, там есть max_conns=number http://nginx.org/en/docs/http/ngx_http_upstream_module.html 2) поставить между клиентом [или nginx] и бэкендом haproxy - haproxy умеет это делать прямо из коробки: https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-maxconn -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: limit conn счетчик переполнение
Hello!
On Fri, Apr 17, 2015 at 12:28:03PM -0400, dwow wrote:
Maxim Dounin Wrote:
---
Если limit_conn в других location'ах не включён, то для
ограничения всех соединений в конкретном location'е - достаточно
любого константного значения.
Если не используется в др. локейшенах, то можно сделать вот так:
limit_conn_zone service zone=perservice:10m;
location /services/post/ {
limit_conn perservice 1;
proxy_pass bakcend;
}
и будет работать?
Да. В старых версиях (до nginx 1.7.6), возможно, потребуется
какая-нибудь константная переменная (например, $nginx_version), а
не просто строка.
Если send_timeout случится - то да. Если же вдруг какой-то клиент
очерь медленно качает что-то большое - то процесс может занять
бесконечное время.
и как от таких избавляться?
В общем случае - никак, это обычные клиенты, которые просто
получают ответ. Собственно, как раз одно из преимуществ nginx'а
состоит в том, что он умеет таких клиентов эффективно
обслуживать, тратя на это минимум ресурсов. Ну и ограничивать с
помощью директивы limit_conn, не давая захватить слишком много
ресурсов сервера.
В вашем случае - проблема в том, что вы пытаетесь limit_conn
применить не по назначению, и такое использование приводит к тому,
что один медленный пользователь может легко заблокировать доступ
всем остальным.
--
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
Yesterday Apr 17, 2015 at 11:12 itcod wrote: Resolving host name dav.example.com ... Connecting ( home.itcod.com = ip: 10.1.1.1, port: 80 ) Connected (10.1.1.1:80) PROPFIND / HTTP/1.1 Host: home.itcod.com HTTP/1.1 207 Multi-Status Server: nginx/0.8.54 Заметил древнюю версию и сделал аналогичный запрос, а в теле ответа другая: centerh1401 Authorization Required/h1/center hrcenternginx/1.7.11/center У Вас один nginx за другим nginx? Если да, то первый полностью принимает запрос и лишь после этого отправляет его второму, а тот возвращает 405. -- WNGS-RIPE ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PUT access_by_lua_file
Добрый день Александр! Да там получается пара друг за дугом. Фронт старичёк Ура!!! Вы совершенно правы!!! Обратился BitKinex к внутреннему Он обрывает PUT сразу!!! PUT /IMG_20150414_184225.jpg HTTP/1.1 Host: home.virtual.ko:7070 User-Agent: BitKinex/3.2.3 Accept: */* Pragma: no-cache Cache-Control: no-cache Content-Length: 696983 Content-Type: application/octet-stream Translate: f Authorization: Basic блаблабла== HTTP/1.1 405 Not Allowed Server: nginx/1.7.11 Date: Sat, 18 Apr 2015 05:25:34 GMT Content-Type: text/html Content-Length: 173 Connection: keep-alive Connection closed Спасибо огромное Надо покурить эту инфу... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258178#msg-258178 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
