Re: nginx-ru Digest, Vol 51, Issue 18

[Андрей Середенко <andrei.seredenko@xxxxxxxxx>]

Вся магия сводится к добавлению:

  location = /webapp {
      return 301 /webapp/;
  }

 

Спасибо, Валентин! Чет как-то об этой "магии" я не подумал.) Обязательно попробуем.

 мы вот так делаем

root /var/www/webapps/nginx-static;

location /webapp/ {
try_files $uri $uri/ @application-handle;
}

location @application-handle {
       include my-site/proxy_pass_params.conf;
       proxy_pass         http://app_upstream;
}


1) в try_files пишем $uri и $uri/
2) root-у нечего делать в location-е
3) include лучше делать в самую первую очередь, чтобы переопределенные
параметры (если они будут) не перетерлись include-овыми

и Вам, Илья, Спасибо. Но - увы: если в try_files указать $uri и $uri/, то на запрос /webapp/ будет прилетать 403. Пробовали..

По поводу root'a в location'е - тоже не тот случай: локейшн не один, равно как и приложение не единственное, и прописывать рут на уровне server'a нет возможности. А делать отдельную секцию server'a для каждого приложения.. ну не знаю, не знаю - что-то меня тут коробит:)

Что же касается инклюдов - учту, спасибо. Хотя у меня есть некоторые сомнения, что эти параметры унаследуются при проксировании, если определить их до.. впрочем, это легко проверить.

Всем спасибо за помощь!

9 января 2014 г., 21:35 пользователь <nginx-ru-request@xxxxxxxxx> написал:

Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
отправлять по адресу
        nginx-ru@xxxxxxxxx

Для изменения параметров подписки вы можеже использовать веб-страницу
        http://mailman.nginx.org/mailman/listinfo/nginx-ru

Для получения информации о том, как пользовать почтовым интерфейсом,
отправьте письмо, в теле или теме которого будет слово 'help', по
адресу:
        nginx-ru-request@xxxxxxxxx

Адрес человека, ответственного за этот список рассылки:
        nginx-ru-owner@xxxxxxxxx

При ответе, пожалуйста, измение тему письма так, чтобы она была более
содержательной чем "Re: Содержание дайджеста списка рассылки
nginx-ru..."

Today's Topics:

   1. Re: 301 redirect на URI без слэша на конце (Валентин Бартенев)
   2. Re: 301 redirect на URI без слэша на конце (Илья Шипицин)
   3. Re: Bug ? 304 status - Cache-Control (Ilya Pirogov)
   4. Slowloris attack (Михаил Монашёв)
   5. Re: Bug ? 304 status - Cache-Control (S.A.N)
   6. Re: Slowloris attack (Sergey Smitienko)


---------- Пересылаемое сообщение ----------
From: "Валентин Бартенев" <vbart@xxxxxxxxx>
To: nginx-ru@xxxxxxxxx
Cc: 
Date: Thu, 09 Jan 2014 19:09:55 +0400
Subject: Re: 301 redirect на URI без слэша на конце
On Thursday 09 January 2014 17:55:57 Андрей Середенко wrote:
> Здравия, друзья! Всех с прошедшими праздниками!
>
> В процессе приведения конфигурации своих веб-серверов в более лицеприятный
> столкнулся с таким моментом: автоматическое добавление слэша не происходит
> после отрабатывания директивы try_files. Было неожиданно. Немного примеров,
> чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и
> "после"):
>
> location /webapp/ {
>         proxy_pass         http://app_upstream;
>  include my-site/proxy_pass_params.conf;
> }
>
> Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать
> и без того кривое приложение:) В итоге, location принял следующий облик:
>
> location /webapp/ {
> root /var/www/webapps/nginx-static;
>  try_files $uri @application-handle;
> }
>
> location @application-handle {
>         proxy_pass         http://app_upstream;
>  include my-site/proxy_pass_params.conf;
> }
>
> В результате, в принципе, получил то, что хотел: запрашиваемые файлы
> сначала ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, -
> проксируем на приложение. Но - перестали обрабатываться запросы вида
> http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со
> слэшем на конце) обрабатываются корректно.
> Оно то, в общем-то, и правильно: в документации сказано:
>
> Если location задан префиксной строкой со слэшом в конце и запросы
>
> > обрабатываются при помощи
> > proxy_pass<http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy
> > _pass>
 ,
> > fastcgi_pass<http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#f
> > astcgi_pass> ,
> > scgi_pass<http://nginx.org/ru/docs/http/ngx_http_scgi_module.html#scgi_pa
> > ss> ,
> > uwsgi_pass<http://nginx.org/ru/docs/http/ngx_http_uwsgi_module.html#uwsgi
> > _pass>>
> >  или
> >  memcached_pass<http://nginx.org/ru/docs/http/ngx_http_memcached_module.h
> >  tml#memcached_pass>,
>
> > а в ответ на запрос с URI равным этой строке, но без завершающего слэша,
> > будет возвращено постоянное перенаправление с кодом 301 на URI с
> > добавленным в конец слэшом. Если такое поведение нежелательно, можно
> > задать точное совпадение URI и location, например:
> >
> >
> >
> > location /user/ {
> >
> >     proxy_pass http://user.example.com;
> >
> > }
> >
> >
> >
> > location = /user {
> >
> >     proxy_pass http://login.example.com;
> >
> > }
> >
> >
> >
> >
> > Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как
>
> вернуть прежнее поведение? можно ли сделать это "красиво"? или придется
> городить магию с реврайтами? а если писать реврайты - куда их пихать.. в
> общем, как-то так. Как-то сходу не получилось самому ответить на эти
> вопросы, решил поделиться с сообществом. Буду признателен за любые
> предложения выхода из ситуации.
>
[...]

Вся магия сводится к добавлению:

  location = /webapp {
      return 301 /webapp/;
  }

--
Валентин Бартенев


---------- Пересылаемое сообщение ----------
From: "Илья Шипицин" <chipitsine@xxxxxxxxx>
To: "nginx-ru@xxxxxxxxx" <nginx-ru@xxxxxxxxx>
Cc: 
Date: Thu, 9 Jan 2014 21:41:05 +0600
Subject: Re: 301 redirect на URI без слэша на конце
мы вот так делаем


root /var/www/webapps/nginx-static;

location /webapp/ {
try_files $uri $uri/ @application-handle;
}

location @application-handle {
       include my-site/proxy_pass_params.conf;
       proxy_pass         http://app_upstream;
}


1) в try_files пишем $uri и $uri/
2) root-у нечего делать в location-е
3) include лучше делать в самую первую очередь, чтобы переопределенные
параметры (если они будут) не перетерлись include-овыми


9 января 2014 г., 20:55 пользователь Андрей Середенко
<andrei.seredenko@xxxxxxxxx> написал:
> Здравия, друзья! Всех с прошедшими праздниками!
>
> В процессе приведения конфигурации своих веб-серверов в более лицеприятный
> столкнулся с таким моментом: автоматическое добавление слэша не происходит
> после отрабатывания директивы try_files. Было неожиданно. Немного примеров,
> чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и
> "после"):
>
> location /webapp/ {
>        proxy_pass         http://app_upstream;
> include my-site/proxy_pass_params.conf;
> }
>
> Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать и
> без того кривое приложение:) В итоге, location принял следующий облик:
>
> location /webapp/ {
> root /var/www/webapps/nginx-static;
> try_files $uri @application-handle;
> }
>
> location @application-handle {
>        proxy_pass         http://app_upstream;
> include my-site/proxy_pass_params.conf;
> }
>
> В результате, в принципе, получил то, что хотел: запрашиваемые файлы сначала
> ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, -
> проксируем на приложение. Но - перестали обрабатываться запросы вида
> http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со
> слэшем на конце) обрабатываются корректно.
> Оно то, в общем-то, и правильно: в документации сказано:
>
>> Если location задан префиксной строкой со слэшом в конце и запросы
>> обрабатываются при помощи proxy_pass, fastcgi_pass, scgi_pass, uwsgi_pass
>> или memcached_pass, а в ответ на запрос с URI равным этой строке, но без
>> завершающего слэша, будет возвращено постоянное перенаправление с кодом 301
>> на URI с добавленным в конец слэшом. Если такое поведение нежелательно,
>> можно задать точное совпадение URI и location, например:
>>
>> location /user/ {
>>     proxy_pass http://user.example.com;
>> }
>>
>> location = /user {
>>     proxy_pass http://login.example.com;
>> }
>>
>>
> Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как
> вернуть прежнее поведение? можно ли сделать это "красиво"? или придется
> городить магию с реврайтами? а если писать реврайты - куда их пихать.. в
> общем, как-то так. Как-то сходу не получилось самому ответить на эти
> вопросы, решил поделиться с сообществом. Буду признателен за любые
> предложения выхода из ситуации.
>
> Немного информации, которая может быть полезной:
>
>> [ root@app1 ~]# nginx -V
>> nginx version: nginx/1.0.15
>> built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
>> TLS SNI support enabled
>> configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
>> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
>> --http-log-path=/var/log/nginx/access.log
>> --http-client-body-temp-path=/var/lib/nginx/tmp/client_body
>> --http-proxy-temp-path=/var/lib/nginx/tmp/proxy
>> --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi
>> --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
>> --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid
>> --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx
>> --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_realip_module
>> --with-http_addition_module --with-http_xslt_module
>> --with-http_image_filter_module --with-http_geoip_module
>> --with-http_sub_module --with-http_dav_module --with-http_flv_module
>> --with-http_mp4_module --with-http_gzip_static_module
>> --with-http_random_index_module --with-http_secure_link_module
>> --with-http_degradation_module --with-http_stub_status_module
>> --with-http_perl_module --with-mail --with-mail_ssl_module
>> --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
>> --with-ld-opt=-Wl,-E
>>
>> [ root@app1 ~]# lsb_release -a
>> LSB Version:
>> :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
>> Distributor ID: CentOS
>> Description: CentOS release 6.2 (Final)
>> Release: 6.2
>> Codename: Final
>>
>> [ root@app1 ~]# uname -a
>> Linux app1 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012
>> x86_64 x86_64 x86_64 GNU/Linux
>
>
> Содержимое my-site/proxy_pass_params.conf (роли наверняка не играет, но для
> полноты картины - надо):
>
>> proxy_redirect     off;
>>
>> proxy_set_header   Host                   $host;
>> proxy_set_header   Remote-Addr       $remote_addr;
>> proxy_set_header   X-Real-IP            $remote_addr;
>> proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
>> proxy_set_header   X-Public-Url         http://$host$request_uri;
>>
>> client_max_body_size                      40m;
>> client_body_buffer_size                    128k;
>>
>> proxy_connect_timeout                    90;
>> proxy_send_timeout                        90;
>> proxy_read_timeout                         2600;
>>
>> proxy_buffer_size                           4k;
>> proxy_buffers                                 4 32k;
>> proxy_busy_buffers_size                 64k;
>> proxy_temp_file_write_size              64k;
>
>
> awaiting..
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


---------- Пересылаемое сообщение ----------
From: Ilya Pirogov <ilya@xxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
Cc: 
Date: Thu, 9 Jan 2014 19:43:42 +0400
Subject: Re: Bug – 304 status - Cache-Control

2014/1/8 S.A.N <nginx-forum@xxxxxxxx>

> Кстати, похоже, что есть вариант еще проще, используя директиву
> fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match
> и выставляя в ответе заголовок X-Accel-Expires: 0
> если статус ответа backend`а будет 304.

Да, у меня крутился в голове вариант, использовать куки для
fastcgi_no_cache.

А зачем использовать куку? Почему нельзя просто прописать:

fastcgi_no_cache $upstream_http_etag;

fastcgi_cache_bypass $http_if_none_match;

Ведь для public кеша, насколько я понял, ETag не отдается.

---------- Пересылаемое сообщение ----------
From: "Михаил Монашёв" <postmaster@xxxxxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
Cc: 
Date: Thu, 9 Jan 2014 21:28:49 +0400
Subject: Slowloris attack
Здравствуйте.

Хотел спросить, а как с Slowloris attack справляется nginx? Он просто
тупо держит все соединения и старается при этом выделять минимум
памяти? Или ещё что-то делается?

--
С уважением,
 Михаил                          mailto:postmaster@xxxxxxxxxxxxx




---------- Пересылаемое сообщение ----------
From: "S.A.N" <nginx-forum@xxxxxxxx>
To: nginx-ru@xxxxxxxxx
Cc: 
Date: Thu, 09 Jan 2014 13:15:34 -0500
Subject: Re: Bug – 304 status - Cache-Control
> А зачем использовать куку? Почему нельзя просто прописать:
>
> fastcgi_no_cache $upstream_http_etag;
> fastcgi_cache_bypass $http_if_none_match;
>
> Ведь для public кеша, насколько я понял, ETag не отдается.

Для public кеш, ETag отдается.
Это сделано на перспективу, в будущем Nginx будет поддерживать ревалидацию
своего кеша по If-None-Match (ETag)

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246192#msg-246192




---------- Пересылаемое сообщение ----------
From: Sergey Smitienko <hunter@xxxxxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
Cc: 
Date: Thu, 09 Jan 2014 20:35:13 +0200
Subject: Re: Slowloris attack

Здравствуйте.

Поставьте маленький client_header_timeout, client_body_timeout и лимит на число
подключений с одного IP.

Теоретически частично во FreeBSD может помочь httpready accept filter, но сам не пробовал.

В последний раз у меня было открыто порядка 30K подключений, особо жить не мешало.
А дальше по логу строился firewall и весь ботнет посылается в /dev/null.

Кстати, была бы интересна возможность повесить свой perl обработчик на различные ошибки,
чтобы банить IP прямо из nginx'a ???


1/9/14 7:28 PM, Михаил Монашёв пишет:

Здравствуйте.

Хотел спросить, а как с Slowloris attack справляется nginx? Он просто
тупо держит все соединения и старается при этом выделять минимум
памяти? Или ещё что-то делается?

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru