<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13.333333015441895px">Вся магия сводится к добавлению:</span><br style="font-family:arial,sans-serif;font-size:13.333333015441895px">
<br style="font-family:arial,sans-serif;font-size:13.333333015441895px"><span style="font-family:arial,sans-serif;font-size:13.333333015441895px"> location = /webapp {</span><br style="font-family:arial,sans-serif;font-size:13.333333015441895px">
<span style="font-family:arial,sans-serif;font-size:13.333333015441895px"> return 301 /webapp/;</span><br style="font-family:arial,sans-serif;font-size:13.333333015441895px"><span style="font-family:arial,sans-serif;font-size:13.333333015441895px"> }</span></blockquote>
<div> </div>
<div>Спасибо, Валентин! Чет как-то об этой "магии" я не подумал.) Обязательно попробуем.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:13.333333015441895px">мы вот так делаем</span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif">root /var/www/webapps/nginx-static;</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif">location /webapp/ {</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif"><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">try_files $uri $uri/ @application-handle;</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif">}</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif">location @application-handle {</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif"><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"> include my-site/proxy_pass_params.</span><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">conf;</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif"> proxy_pass </span><a href="http://app_upstream/" style="font-size:13.333333015441895px;font-family:arial,sans-serif" target="_blank">http://app_upstream</a><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">;</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif">}</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<br style="font-size:13.333333015441895px;font-family:arial,sans-serif"><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">1) в try_files пишем $uri и $uri/</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif">2) root-у нечего делать в location-е</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif"><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">3) include лучше делать в самую первую очередь, чтобы переопределенные</span><br style="font-size:13.333333015441895px;font-family:arial,sans-serif">
<span style="font-size:13.333333015441895px;font-family:arial,sans-serif">параметры (если они будут) не перетерлись include-овыми</span></blockquote><div><br></div><div>и Вам, Илья, Спасибо. Но - увы: если в try_files указать $uri и $uri/, то на запрос /webapp/ будет прилетать 403. Пробовали..</div>
<div>По поводу root'a в location'е - тоже не тот случай: локейшн не один, равно как и приложение не единственное, и прописывать рут на уровне server'a нет возможности. А делать отдельную секцию server'a для каждого приложения.. ну не знаю, не знаю - что-то меня тут коробит:)</div>
<div>Что же касается инклюдов - учту, спасибо. Хотя у меня есть некоторые сомнения, что эти параметры унаследуются при проксировании, если определить их до.. впрочем, это легко проверить.</div><div><br></div><div>Всем спасибо за помощь!</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">9 января 2014 г., 21:35 пользователь <span dir="ltr"><<a href="mailto:nginx-ru-request@nginx.org" target="_blank">nginx-ru-request@nginx.org</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Сообщения, предназначенные для списка рассылки nginx-ru, необходимо<br>
отправлять по адресу<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<br>
Для изменения параметров подписки вы можеже использовать веб-страницу<br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
<br>
Для получения информации о том, как пользовать почтовым интерфейсом,<br>
отправьте письмо, в теле или теме которого будет слово 'help', по<br>
адресу:<br>
<a href="mailto:nginx-ru-request@nginx.org" target="_blank">nginx-ru-request@nginx.org</a><br>
<br>
Адрес человека, ответственного за этот список рассылки:<br>
<a href="mailto:nginx-ru-owner@nginx.org" target="_blank">nginx-ru-owner@nginx.org</a><br>
<br>
При ответе, пожалуйста, измение тему письма так, чтобы она была более<br>
содержательной чем "Re: Содержание дайджеста списка рассылки<br>
nginx-ru..."<br>
<br>Today's Topics:<br>
<br>
1. Re: 301 redirect на URI без слэша на конце (Валентин Бартенев)<br>
2. Re: 301 redirect на URI без слэша на конце (Илья Шипицин)<br>
3. Re: Bug ? 304 status - Cache-Control (Ilya Pirogov)<br>
4. Slowloris attack (Михаил Монашёв)<br>
5. Re: Bug ? 304 status - Cache-Control (S.A.N)<br>
6. Re: Slowloris attack (Sergey Smitienko)<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "Валентин Бартенев" <<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>><br>To: <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Thu, 09 Jan 2014 19:09:55 +0400<br>Subject: Re: 301 redirect на URI без слэша на конце<br>On Thursday 09 January 2014 17:55:57 Андрей Середенко wrote:<br>
> Здравия, друзья! Всех с прошедшими праздниками!<br>
><br>
> В процессе приведения конфигурации своих веб-серверов в более лицеприятный<br>
> столкнулся с таким моментом: автоматическое добавление слэша не происходит<br>
> после отрабатывания директивы try_files. Было неожиданно. Немного примеров,<br>
> чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и<br>
> "после"):<br>
><br>
> location /webapp/ {<br>
> proxy_pass <a href="http://app_upstream" target="_blank">http://app_upstream</a>;<br>
> include my-site/proxy_pass_params.conf;<br>
> }<br>
><br>
> Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать<br>
> и без того кривое приложение:) В итоге, location принял следующий облик:<br>
><br>
> location /webapp/ {<br>
> root /var/www/webapps/nginx-static;<br>
> try_files $uri @application-handle;<br>
> }<br>
><br>
> location @application-handle {<br>
> proxy_pass <a href="http://app_upstream" target="_blank">http://app_upstream</a>;<br>
> include my-site/proxy_pass_params.conf;<br>
> }<br>
><br>
> В результате, в принципе, получил то, что хотел: запрашиваемые файлы<br>
> сначала ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, -<br>
> проксируем на приложение. Но - перестали обрабатываться запросы вида<br>
> <a href="http://my.site.com/webapp" target="_blank">http://my.site.com/webapp</a>, хотя запросы <a href="http://my.site.com/webapp/" target="_blank">http://my.site.com/webapp/</a> (со<br>
> слэшем на конце) обрабатываются корректно.<br>
> Оно то, в общем-то, и правильно: в документации сказано:<br>
><br>
> Если location задан префиксной строкой со слэшом в конце и запросы<br>
><br>
> > обрабатываются при помощи<br>
> > proxy_pass<<a href="http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy" target="_blank">http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy</a><br>
> > _pass><br>
,<br>
> > fastcgi_pass<<a href="http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#f" target="_blank">http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#f</a><br>
> > astcgi_pass> ,<br>
> > scgi_pass<<a href="http://nginx.org/ru/docs/http/ngx_http_scgi_module.html#scgi_pa" target="_blank">http://nginx.org/ru/docs/http/ngx_http_scgi_module.html#scgi_pa</a><br>
> > ss> ,<br>
> > uwsgi_pass<<a href="http://nginx.org/ru/docs/http/ngx_http_uwsgi_module.html#uwsgi" target="_blank">http://nginx.org/ru/docs/http/ngx_http_uwsgi_module.html#uwsgi</a><br>
> > _pass>><br>
> > или<br>
> > memcached_pass<<a href="http://nginx.org/ru/docs/http/ngx_http_memcached_module.h" target="_blank">http://nginx.org/ru/docs/http/ngx_http_memcached_module.h</a><br>
> > tml#memcached_pass>,<br>
><br>
> > а в ответ на запрос с URI равным этой строке, но без завершающего слэша,<br>
> > будет возвращено постоянное перенаправление с кодом 301 на URI с<br>
> > добавленным в конец слэшом. Если такое поведение нежелательно, можно<br>
> > задать точное совпадение URI и location, например:<br>
> ><br>
> ><br>
> ><br>
> > location /user/ {<br>
> ><br>
> > proxy_pass <a href="http://user.example.com" target="_blank">http://user.example.com</a>;<br>
> ><br>
> > }<br>
> ><br>
> ><br>
> ><br>
> > location = /user {<br>
> ><br>
> > proxy_pass <a href="http://login.example.com" target="_blank">http://login.example.com</a>;<br>
> ><br>
> > }<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как<br>
><br>
> вернуть прежнее поведение? можно ли сделать это "красиво"? или придется<br>
> городить магию с реврайтами? а если писать реврайты - куда их пихать.. в<br>
> общем, как-то так. Как-то сходу не получилось самому ответить на эти<br>
> вопросы, решил поделиться с сообществом. Буду признателен за любые<br>
> предложения выхода из ситуации.<br>
><br>
[...]<br>
<br>
Вся магия сводится к добавлению:<br>
<br>
location = /webapp {<br>
return 301 /webapp/;<br>
}<br>
<br>
--<br>
Валентин Бартенев<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "Илья Шипицин" <<a href="mailto:chipitsine@gmail.com" target="_blank">chipitsine@gmail.com</a>><br>To: "<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a>" <<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a>><br>
Cc: <br>Date: Thu, 9 Jan 2014 21:41:05 +0600<br>Subject: Re: 301 redirect на URI без слэша на конце<br>мы вот так делаем<br>
<br>
<br>
root /var/www/webapps/nginx-static;<br>
<br>
location /webapp/ {<br>
try_files $uri $uri/ @application-handle;<br>
}<br>
<br>
location @application-handle {<br>
include my-site/proxy_pass_params.conf;<br>
proxy_pass <a href="http://app_upstream" target="_blank">http://app_upstream</a>;<br>
}<br>
<br>
<br>
1) в try_files пишем $uri и $uri/<br>
2) root-у нечего делать в location-е<br>
3) include лучше делать в самую первую очередь, чтобы переопределенные<br>
параметры (если они будут) не перетерлись include-овыми<br>
<br>
<br>
9 января 2014 г., 20:55 пользователь Андрей Середенко<br>
<<a href="mailto:andrei.seredenko@gmail.com" target="_blank">andrei.seredenko@gmail.com</a>> написал:<br>
> Здравия, друзья! Всех с прошедшими праздниками!<br>
><br>
> В процессе приведения конфигурации своих веб-серверов в более лицеприятный<br>
> столкнулся с таким моментом: автоматическое добавление слэша не происходит<br>
> после отрабатывания директивы try_files. Было неожиданно. Немного примеров,<br>
> чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и<br>
> "после"):<br>
><br>
> location /webapp/ {<br>
> proxy_pass <a href="http://app_upstream" target="_blank">http://app_upstream</a>;<br>
> include my-site/proxy_pass_params.conf;<br>
> }<br>
><br>
> Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать и<br>
> без того кривое приложение:) В итоге, location принял следующий облик:<br>
><br>
> location /webapp/ {<br>
> root /var/www/webapps/nginx-static;<br>
> try_files $uri @application-handle;<br>
> }<br>
><br>
> location @application-handle {<br>
> proxy_pass <a href="http://app_upstream" target="_blank">http://app_upstream</a>;<br>
> include my-site/proxy_pass_params.conf;<br>
> }<br>
><br>
> В результате, в принципе, получил то, что хотел: запрашиваемые файлы сначала<br>
> ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, -<br>
> проксируем на приложение. Но - перестали обрабатываться запросы вида<br>
> <a href="http://my.site.com/webapp" target="_blank">http://my.site.com/webapp</a>, хотя запросы <a href="http://my.site.com/webapp/" target="_blank">http://my.site.com/webapp/</a> (со<br>
> слэшем на конце) обрабатываются корректно.<br>
> Оно то, в общем-то, и правильно: в документации сказано:<br>
><br>
>> Если location задан префиксной строкой со слэшом в конце и запросы<br>
>> обрабатываются при помощи proxy_pass, fastcgi_pass, scgi_pass, uwsgi_pass<br>
>> или memcached_pass, а в ответ на запрос с URI равным этой строке, но без<br>
>> завершающего слэша, будет возвращено постоянное перенаправление с кодом 301<br>
>> на URI с добавленным в конец слэшом. Если такое поведение нежелательно,<br>
>> можно задать точное совпадение URI и location, например:<br>
>><br>
>> location /user/ {<br>
>> proxy_pass <a href="http://user.example.com" target="_blank">http://user.example.com</a>;<br>
>> }<br>
>><br>
>> location = /user {<br>
>> proxy_pass <a href="http://login.example.com" target="_blank">http://login.example.com</a>;<br>
>> }<br>
>><br>
>><br>
> Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как<br>
> вернуть прежнее поведение? можно ли сделать это "красиво"? или придется<br>
> городить магию с реврайтами? а если писать реврайты - куда их пихать.. в<br>
> общем, как-то так. Как-то сходу не получилось самому ответить на эти<br>
> вопросы, решил поделиться с сообществом. Буду признателен за любые<br>
> предложения выхода из ситуации.<br>
><br>
> Немного информации, которая может быть полезной:<br>
><br>
>> [ root@app1 ~]# nginx -V<br>
>> nginx version: nginx/1.0.15<br>
>> built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)<br>
>> TLS SNI support enabled<br>
>> configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx<br>
>> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log<br>
>> --http-log-path=/var/log/nginx/access.log<br>
>> --http-client-body-temp-path=/var/lib/nginx/tmp/client_body<br>
>> --http-proxy-temp-path=/var/lib/nginx/tmp/proxy<br>
>> --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi<br>
>> --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi<br>
>> --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid<br>
>> --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx<br>
>> --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_realip_module<br>
>> --with-http_addition_module --with-http_xslt_module<br>
>> --with-http_image_filter_module --with-http_geoip_module<br>
>> --with-http_sub_module --with-http_dav_module --with-http_flv_module<br>
>> --with-http_mp4_module --with-http_gzip_static_module<br>
>> --with-http_random_index_module --with-http_secure_link_module<br>
>> --with-http_degradation_module --with-http_stub_status_module<br>
>> --with-http_perl_module --with-mail --with-mail_ssl_module<br>
>> --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions<br>
>> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'<br>
>> --with-ld-opt=-Wl,-E<br>
>><br>
>> [ root@app1 ~]# lsb_release -a<br>
>> LSB Version:<br>
>> :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch<br>
>> Distributor ID: CentOS<br>
>> Description: CentOS release 6.2 (Final)<br>
>> Release: 6.2<br>
>> Codename: Final<br>
>><br>
>> [ root@app1 ~]# uname -a<br>
>> Linux app1 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012<br>
>> x86_64 x86_64 x86_64 GNU/Linux<br>
><br>
><br>
> Содержимое my-site/proxy_pass_params.conf (роли наверняка не играет, но для<br>
> полноты картины - надо):<br>
><br>
>> proxy_redirect off;<br>
>><br>
>> proxy_set_header Host $host;<br>
>> proxy_set_header Remote-Addr $remote_addr;<br>
>> proxy_set_header X-Real-IP $remote_addr;<br>
>> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br>
>> proxy_set_header X-Public-Url http://$host$request_uri;<br>
>><br>
>> client_max_body_size 40m;<br>
>> client_body_buffer_size 128k;<br>
>><br>
>> proxy_connect_timeout 90;<br>
>> proxy_send_timeout 90;<br>
>> proxy_read_timeout 2600;<br>
>><br>
>> proxy_buffer_size 4k;<br>
>> proxy_buffers 4 32k;<br>
>> proxy_busy_buffers_size 64k;<br>
>> proxy_temp_file_write_size 64k;<br>
><br>
><br>
> awaiting..<br>
><br>
> _______________________________________________<br>
> nginx-ru mailing list<br>
> <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: Ilya Pirogov <<a href="mailto:ilya@pirogov.me" target="_blank">ilya@pirogov.me</a>><br>To: <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Thu, 9 Jan 2014 19:43:42 +0400<br>
Subject: Re: Bug – 304 status - Cache-Control<br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014/1/8 S.A.N <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>> Кстати, похоже, что есть вариант еще проще, используя директиву<br>
> fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match<br>
> и выставляя в ответе заголовок X-Accel-Expires: 0<br>
> если статус ответа backend`а будет 304.<br>
<br>
</div>Да, у меня крутился в голове вариант, использовать куки для<br>
fastcgi_no_cache.<br></blockquote><div><br></div><div>А зачем использовать куку? Почему нельзя просто прописать:</div><div><br></div><div><font face="courier new, monospace">fastcgi_no_cache $upstream_http_etag;<br></font></div>
<div><font face="courier new, monospace">fastcgi_cache_bypass $http_if_none_match;<br></font></div><div><br></div><div>Ведь для public кеша, насколько я понял, ETag не отдается.</div>
</div></div></div>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "Михаил Монашёв" <<a href="mailto:postmaster@softsearch.ru" target="_blank">postmaster@softsearch.ru</a>><br>To: <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Thu, 9 Jan 2014 21:28:49 +0400<br>Subject: Slowloris attack<br>Здравствуйте.<br>
<br>
Хотел спросить, а как с Slowloris attack справляется nginx? Он просто<br>
тупо держит все соединения и старается при этом выделять минимум<br>
памяти? Или ещё что-то делается?<br>
<br>
--<br>
С уважением,<br>
Михаил mailto:<a href="mailto:postmaster@softsearch.ru" target="_blank">postmaster@softsearch.ru</a><br>
<br>
<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "S.A.N" <<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>><br>To: <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Thu, 09 Jan 2014 13:15:34 -0500<br>Subject: Re: Bug – 304 status - Cache-Control<br>> А зачем использовать куку? Почему нельзя просто прописать:<br>
><br>
> fastcgi_no_cache $upstream_http_etag;<br>
> fastcgi_cache_bypass $http_if_none_match;<br>
><br>
> Ведь для public кеша, насколько я понял, ETag не отдается.<br>
<br>
Для public кеш, ETag отдается.<br>
Это сделано на перспективу, в будущем Nginx будет поддерживать ревалидацию<br>
своего кеша по If-None-Match (ETag)<br>
<br>
Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?21,245951,246192#msg-246192" target="_blank">http://forum.nginx.org/read.php?21,245951,246192#msg-246192</a><br>
<br>
<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: Sergey Smitienko <<a href="mailto:hunter@comsys.com.ua" target="_blank">hunter@comsys.com.ua</a>><br>To: <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
Cc: <br>
Date: Thu, 09 Jan 2014 20:35:13 +0200<br>Subject: Re: Slowloris attack<br>
<div bgcolor="#FFFFFF" text="#000000">
<div>
<pre>Здравствуйте.
</pre>
Поставьте маленьки<strong></strong><strong></strong><strong style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:start;font-style:normal;background-color:rgb(238,238,238);line-height:normal;text-transform:none;font-size:medium;white-space:normal;font-family:monospace;word-spacing:0px"></strong>й client_header_timeout, client_body_timeout и
лимит на число<br>
подключений с одного IP.<br>
<br>
Теоретически частично во FreeBSD может помочь httpready accept
filter, но сам не пробовал.<br>
<br>
В последний раз у меня было открыто порядка 30K подключений, особо
жить не мешало.<br>
А дальше по логу строился firewall и весь ботнет посылается в
/dev/null.<br>
<br>
Кстати, была бы интересна возможность повесить свой perl
обработчик на различные ошибки,<br>
чтобы банить IP прямо из nginx'a ???<br>
<br>
<br>
1/9/14 7:28 PM, Михаил Монашёв пишет:<br>
</div>
<blockquote type="cite">
<pre>Здравствуйте.
Хотел спросить, а как с Slowloris attack справляется nginx? Он просто
тупо держит все соединения и старается при этом выделять минимум
памяти? Или ещё что-то делается?
</pre>
</blockquote>
</div>
<br>_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br></blockquote></div><br></div></div>