>
> Вся магия сводится к добавлению:
>
> 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-requ...@nginx.org> написал:
> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
> nginx-ru@nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
> nginx-ru-requ...@nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
> nginx-ru-ow...@nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "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: "Валентин Бартенев" <vb...@nginx.com>
> To: nginx-ru@nginx.org
> 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: "Илья Шипицин" <chipits...@gmail.com>
> To: "nginx-ru@nginx.org" <nginx-ru@nginx.org>
> 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.serede...@gmail.com> написал:
> > Здравия, друзья! Всех с прошедшими праздниками!
> >
> > В процессе приведения конфигурации своих веб-серверов в более
> лицеприятный
> > столкнулся с таким моментом: автоматическое добавление слэша не
> происходит
> > после отрабатывания директивы 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@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ---------- Пересылаемое сообщение ----------
> From: Ilya Pirogov <i...@pirogov.me>
> To: nginx-ru@nginx.org
> Cc:
> Date: Thu, 9 Jan 2014 19:43:42 +0400
> Subject: Re: Bug - 304 status - Cache-Control
> 2014/1/8 S.A.N <nginx-fo...@nginx.us>
>
>> > Кстати, похоже, что есть вариант еще проще, используя директиву
>> > 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: "Михаил Монашёв" <postmas...@softsearch.ru>
> To: nginx-ru@nginx.org
> Cc:
> Date: Thu, 9 Jan 2014 21:28:49 +0400
> Subject: Slowloris attack
> Здравствуйте.
>
> Хотел спросить, а как с Slowloris attack справляется nginx? Он просто
> тупо держит все соединения и старается при этом выделять минимум
> памяти? Или ещё что-то делается?
>
> --
> С уважением,
> Михаил mailto:postmas...@softsearch.ru
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: "S.A.N" <nginx-fo...@nginx.us>
> To: nginx-ru@nginx.org
> 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 <hun...@comsys.com.ua>
> To: nginx-ru@nginx.org
> 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@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
