Re: как передать cache-control заголовок от апстрима в браузер
> Убрать конфигурацию, которая прячет исходный заголовок > Cache-Control (proxy_hide_header?) и добавляет вместо него > "no-cache,no-store"? > > По умолчанию nginx отдаёт клиенту ровно тот заголовок > Cache-Control, какой получил от бэкенда. Чтобы вернуть что-то > другое - нужно это явно сконфигурировать. Причём получить "no-store" с > помощью простых стандартных механизмов, как то директива expires, > не получится. То есть либо у вас это должно быть явно в конфиге > nginx'а, либо такой заголовок всё-таки возвращает бэкенд. спасибо большое за быстрый ответ, он всё расставил по своим местам, будем проверять всю конфигурацию целиком, возможно ошибка в логике работы генератора конфигов ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
как передать cache-control заголовок от апстрима в браузер
Добрый день, nginx используется как кеширующий реверс-прокси, апстрим с Апачем выставляет заголовок: Cache-Control: public, max-age=0, must-revalidate Nginx руководствуется этим заголовком для того, чтобы определить каким образом кешировать ответ апстрима, но посетителю Nginx отдаёт ответ с заголовком: Cache-Control: no-cache,no-store Необходимо сделать так, чтобы заголовок "Cache-Control: public, max-age=0, must-revalidate" получал посетитель (браузер). Как лучше всего этого добиться? ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: кешировать только ответы где есть определённый Set-Cookie
Добрый день,
> У вас map выполняется в proxy_cache_bypass, то есть до отправки
> запроса на бэкенд, и запоминает результат (некорректный, так как
> он основан на ещё не полученных от бэкенда заголовках ответа).
Спасибо большое за быстрый ответ, - помогло!
Результирующая конфигурация для моих целей получилась такая:
map $upstream_http_set_cookie $bypass_cache {
"~*pll" 0;
"~*=" 1;
}
proxy_ignore_headers "Set-cookie";
proxy_no_cache $bypass_cache;
Ответы содержащие заголовок Set-cookie могут кешироваться. Если в
заголовке Set-cookie встречается pll - такой ответ кешируется. Если в
заголовке Set-cookie встречается любое другое установленное значение
(есть символ "="), то такой ответ кешироваться не будет. Если же
заголовок Set-cookie пустой, то такой ответ будет кешироваться.
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
кешировать только ответы где есть определённый Set-Cookie
Добрый день,
нужно избирательно кешировать ответы бэкэнда в nginx. Некоторые ответы
содержат Set-Cookie заголовки.По-умолчанию их кешировать не нужно, но
если встречается определённая куки, то такой ответ нужно кешировать.
пример:
кешируем ответ с заголовком:
Set-Cookie: pll_language=en; expires=Fri, 07-Jul-2023 11:37:39 GMT;
Max-Age=31536000; path=/; secure; SameSite=Lax
не кешируем ответ с сессией пользователя с заголовком:
Set-Cookie: login=i324iuhkj324; expires=Fri, 10-Jul-2023 11:37:39 GMT;
Max-Age=31536000; path=/; secure
пытаюсь делать так:
map $upstream_http_set_cookie $bypass_cache {
"~*.pll" 0;
default1;
}
server {
[..]
location @granted {
[..]
proxy_ignore_headers Set-cookie;
proxy_no_cache $bypass_cache;
proxy_cache_bypass $bypass_cache;
add_header X-Bypass $bypass_cache;
add_header X-upstream-set-cookie "aaa $upstream_http_set_cookie";
[..]
}
[..]
}
в ответе получаю:
X-Bypass: 1
X-upstream-set-cookie: aaa pll_language=en; expires=Fri, 07-Jul-2023
11:37:39 GMT; Max-Age=31536000; path=/; secure; SameSite=Lax
такое впечатление, что директива add_header корректно видит содержимое
заголовка ответа апстрима, а вот map (и if тоже пытался) - не видят
содержимого ни $upstream_http_set_cookie ни
$upstream_cookie_pll_language.
Может быть есть какие-то мысли как такое лучше реализовать и возможно
ли это вообще?
nginx -v
nginx version: nginx/1.19.2
nginx -V
nginx version: nginx/1.19.2
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1d 10 Sep 2019
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx
--group=nginx --with-compat --with-file-aio --with-threads
--with-http_addition_module --with-http_auth_request_module
--with-http_dav_module --with-http_flv_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_mp4_module --with-http_random_index_module
--with-http_realip_module --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_module
--with-http_stub_status_module --with-http_sub_module
--with-http_v2_module --with-mail --with-mail_ssl_module --with-stream
--with-stream_realip_module --with-stream_ssl_module
--with-stream_ssl_preread_module --with-cc-opt='-g -O2
-fdebug-prefix-map=/data/builder/debuild/nginx-1.19.2/debian/debuild-base/nginx-1.19.2=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed -pie'
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: Варнинги после перехода на PHP 8
> Скрипт сайта, в ответ на запрос с заголовком > "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не > нулевые данные. Скрипт делает все верно почему верно? в RFC 2616 написано, что: 14.13 Content-Length The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. https://tools.ietf.org/html/rfc2616#page-119 если Вы объявляете, что "Content-Length: 0" , то никакого тела в ответе быть не должно. Если тело есть, то в "Content-Length: ХХ" нужно указать его размер. Также допускается опустить этот заголовок, если конкретный размер тела неизвестен на момент начала передачи, насколько я понимаю. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
Добрый день, > Кроме того, соединение не будет закрыто, если используется > кэширование или fastcgi_store, так как в этих случаях ответ > бэкенда полезен вне зависимости от того, будет ли он отправлен > конкретному клиенту. вот это уточнение прямо очень интересное, спасибо за него, Максим! ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.15.7
Добрый вечер, > *) Добавление: параметр "delay" директивы "limit_req". >Спасибо Владиславу Шабанову и Петру Щучкину. прочитал документацию несколько раз, но мне кажется я так и не понял как именно работает delay: > Если же избыточные запросы в пределах лимита всплесков > задерживать не требуется, то следует использовать параметр nodelay: > limit_req zone=one burst=5 nodelay; > Параметр delay (1.15.7) задаёт лимит, по достижении которого > избыточные запросы задерживаются. > Значение по умолчанию равно нулю и означает, > что задерживаются все избыточные запросы. Не могли бы Вы привести пример и объяснить это подробнее? Правильно ли я понимаю, что при limit_req zone=one burst=5 delay=5; пять первых запросов отправленные в ту же секунду к серверу будут обслужены сразу же, а шестой и последующие уже будут завершены с ошибкой, если скорость поступления запросов превышает описанную в зоне? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ошибка при отправке письма из PHP
добрый вечер, > Поскольку сайт работает через chroot, то его sendmail лежит здесь > /home/rima/www/usr/sbin/ > Даже через него напрямую из консоли ./sendmail можно спокойно отправить > тестовое письмо, но из самого php скрипта не не удается. Всему каталогу с > сайтом, директориями и файлам заданы полные права (777). а как Вы проверяете? chroot /home/rima/www/ а потом sendmail ? мне кажется у Вас sendmail статически не слинкован и ему чего-то не хватает, посмотрите через ldd sendmail также для всякой крипты (отправка через TLS) внутри чрута должны быть /dev/random /dev/urandom и прочие устройства, но такие ошибки можно отловить интерактивно в консоли ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginScript чтобы посчитать количество запросов с ip
Добрый день, нужно посчитать количество запросов для каждого IP адреса. сейчас мы это делаем логгируя в файл IP адрес клиента для каждого запроса и потом считая уникальные вхождения, но это какой-то странный способ получения этой метрики. возможно ли использовать nginScript для этой цели создав ассоциативный массив (kv) из айпишников и количеств запросов к ним, отдавая потом его в каком-то локейшне? или может быть есть более правильные способы собирать кастумные метрики без нагромождений сторонних модулей разного качества? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: PID file
Добрый день, читайте этот тред: http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060604.html https://forum.nginx.org/read.php?21,277438 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Что делает nginx
> Вот налетело пользователей 2.5 к чего то делают там на сайте. > Все работает проблемм нет. При этом nginx в top на первых местах по > нагрузке, за ним php-fpm, это при том, что сайт на скрипте. > Как понять, почему nginx грузит проц, чем он занят ? Ведь основная логика на > php, он и должен поедать все, как мне кажется. а у Вас HTTPS есть? если есть, то, видимо, шифрует. особенно, если не настроено кеширование https сессий http://nginx.org/ru/docs/http/configuring_https_servers.html#optimization ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx и queue в upstream (Windows)
Добрый день, > Валентин Бартенев, несомненно всё так. Вы правы во всём, но мы же говорим не > о продакшене. а о разработчиках > Многим просто удобно работать на Windows. а WSL не решит Ваших проблем? https://msdn.microsoft.com/en-us/commandline/wsl/about ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ngx_http_auth_request и fastcgi
а, кажется разобрался. так работает:
location = /test.php {
auth_request /is_proxy.php;
fastcgi_pass fcgi_pool;
}
location = /is_proxy.php {
fastcgi_pass_request_body off;
fastcgi_intercept_errors off;
fastcgi_pass fcgi_pool;
}
cat is_proxy.php
http://someservice.com/check.php?ip=$ip;;
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_URL,$url);
$result=curl_exec($ch);
curl_close($ch);
echo($ip);
if ($result === 'Y') {
http_response_code(403);
} else {
http_response_code(200);
}
} else {
//failsafe
http_response_code(200);
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: naxsi как dynamic module
> Да модуль версия зависим это понятно. но планируется ли (и возможно ли) сделать такую архитектуру подключения модулей, которая бы обеспечила возможность собрать один раз модуль как dll для программы под windows, а затем обновлять только по мере необходимости, а не при каждом выходе новой версии nginx? прошу прощения, если вопрос дурацкий, я не силён в системном программировании под linux ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: когда лучше использовать multi_accept on
> [..] > Если поступающих соединений очень много, то второй вариант работы может > оказаться чуть оптимальнее, за счет того, что рабочий процесс для получения > каждого соединение не ходит за событием в ядро. > [..] теперь понятно! Валентин, большое спасибо за подробное разъяснение ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: когда лучше использовать multi_accept on
> Если директива выключена , то есть установлено > значение off, то один процесс будет принимать одно соединение. > Если вы включаете multi accept, nginx попытается обработать максимальное > количество входящий соединений. Если значение worker_connections мало то > быстро исчерпается лимит. а какой смысл в том, что один процесс (worker) принимает сразу несколько соединений? ведь воркер однопоточен и будет обрабатывать их по-очереди. почему это иногда может быть лучше, чем поведение по-умолчанию "принять одно соединение, выполнить необходимую работу, принять следующее соединение"? почему иногда может быть эффективным принимать несколько соединений воркером за один вызов event loop? https://assets.wp.nginx.com/wp-content/uploads/2015/06/NGINX-Event-Loop2-e1434744201287.png ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
когда лучше использовать multi_accept on
Добрый вечер, подскажите пожалуйста, в каких случаях нужно включать multi_accept on и как именно он работает? документацию читал http://nginx.org/r/multi_accept/ru из того, что мне удалось нагуглить, ничто не проясняет ситуацию для меня: http://mailman.nginx.org/pipermail/nginx-ru/2009-October/028973.html : При "multi_accept on" nginx пытается accept()нуть все соединения при получении сообщения о новых соединениях http://mailman.nginx.org/pipermail/nginx-ru/2015-May/056041.html : С multi_accept не пересекается никак - в зависимости от workload'а и желаемых результатов может иметь или не иметь смысл включать multi_accept. Проблема всё та же: multi_accept позволяет принять сразу несколько соединений за одну итерацию event loop'а, но ценой одного лишнего вызова accept(). Есть небольшой положительный эффект - при использовании reuseport из-за multi_accept'а не будут возникать перекосы в распределении соединений между рабочими процессами при microbenchmark'ах. http://mailman.nginx.org/pipermail/nginx-ru/2014-June/054012.html : По умолчанию nginx старается работать так, чтобы "пробуждалось" минимальное количество рабочих процессов - это позволяет экономить затраты на переключение контекстов и "лишние" пробуждения процессов. При реальной работе - в результате используется столько процессов, сколько на самом деле нужно для обработки той нагрузки, которая есть. Если хочется получить более ровное распределение в тестах - то имеет смысл: - accept_mutex выключить; - multi_accept, если вдруг включён, выключить; - убедиться, что тесты не используют постоянные соединения и/или количество устанавливаемых соединений так или иначе велико. Я не понимаю что мы выигрываем от принятия сразу нескольких соединений за одну итерацию event loop'а. Валентин, может быть Вы сможете проиллюстрировать ситуацию со включенным и отключенным multi_accept на примере с бомжами и мусорными баками? https://habrahabr.ru/post/188114/#comment_6549442 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ревалидация кеша fastcgi
> Вы изначально в ответе отдавали заголовки валидаторы (ETag и/ил > Last-Modified)? > Посмотрите на содержимое в папке кеша Nginx, есть ли там заголовки ETag и/ил > Last-Modified, без них ревалидация кеша невозможно. да, спасибо огромное дело оказалось именно в этом! заголовки-то мы отдавали, и у разработчика на машине nginx 1.8.0 и php 5.6 они ставятся нормально, а вот на конфигурации, которая дублирует продакшн nginx 1.9.15 и php 5.4 (fpm, chroot) что-то в приложении эти заголовки упорно снимало. приложение на основе wordpress и там какой-то ад и израиль. пока нашли воркэраунд - заголовки начали ставится и ревалидация заработала. Максим, S.A.N спасибо большое за помощь ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ревалидация кеша fastcgi
>> fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
>> fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since
>> if_not_empty;
>
> У вас в конфиге написано: установить заголовки If-None-Match и
> If-Modified-Since в запросах к бекенду в полученные от клиента
> значения. Ревалидация кеша в таких условиях работать не может по
> очевидным причинам.
убрал эти строки. удалил кеш. ристартанул nginx
первая загрузка X-My-Cache: MISS (страницы нет в кеше)
вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную версию)
жду 10 секунд
третья загрузка X-My-Cache: EXPIRED
(а я ожидаю X-My-Cache: REVALIDATED )
заголовки запроса браузера:
GET /product/name HTTP/1.1
Host: site.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112
Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
на всякий случай сделал то же самое через curl:
curl -i "https://site.com/product/name;
и получил точно такой же результат:
первая загрузка X-My-Cache: MISS (страницы нет в кеше)
вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную версию)
жду 10 секунд
третья загрузка X-My-Cache: EXPIRED
> На бекенде в РНР, отвечайте http_response_code(304); вместо header('HTTP/1.0
304 Not Modified'); так быстрей и правильней.
поправил
> Судя по конфигу, у вас проблема с куками, если браузер присылает куки
сессии, кеш не работает, curl куки не присылает, ответ отдается из кеша.
вроде нет, см выше описание поведения curl при стандартном GET
бэкэнд сейчас, к слову, выглядит примерно так:
http://mailman.nginx.org/mailman/listinfo/nginx-ru
ревалидация кеша fastcgi
Добрый день,
пытаюсь настроить ревалидацию страниц сайта в кеше директивой
fastcgi_cache_revalidate on;
ожидаю, что если элемент кеша устарел, то nginx сам сделает запрос к
бекэнду с заголовком If-Modified-Since (как это описано тут
http://whitequark.org/blog/2014/04/05/page-caching-with-nginx/ ), но
этого не происходит.
при устаревании элемента кеша $upstream_cache_status == EXPIRED и на
бэкэнд уходит стандартный GET без заголовков на ревалидацию при
включённом fastcgi_cache_revalidate on.
я попробовал задавать fastcgi_cache_revalidate на разных уровнях, на
случай если есть особенности наследования, но всё равно безуспешно.
если же я делаю
curl -i --header 'If-Modified-Since: Tue, 11 Dec 2015 10:10:24 GMT'
https://site.com
то получаю X-My-Cache: REVALIDATED - потому что клиентский заголовок
был корректно передан на бэкэнд, который ответил header('HTTP/1.0 304
Not Modified');
вопрос: я не понимаю как должна работать директива и хочу странного
или всё же задачу можно как-то решить? подскажите, пожалуйста.
конфиг:
fastcgi_cache_path /tmp/MAIN levels=1:2 keys_zone=MAIN:64m
max_size=768m inactive=24h;
server {
listen ***:443 ssl;
server_name site.com;
ssl on;
ssl_certificate /etc/nginx/ssl/certs-mcg/site_co_uk.pem;
ssl_certificate_key /etc/nginx/ssl/certs-mcg/site_co_uk.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
error_log /home/site/logs/site-ssl.error.log error;
access_log /home/site/logs/site-ssl.access.log wtimes;
root /www/site/domains/site.com/public_html/;
set $sock 127.0.0.1:9001;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_intercept_errors on;
fastcgi_param DOCUMENT_ROOT /public_html;
fastcgi_param SCRIPT_FILENAME /public_html$fastcgi_script_name;
fastcgi_no_cache $cookie_login $cookie_authautologin $cookie_PHPSESSID;
fastcgi_cache_bypass $cookie_login $cookie_authautologin $cookie_PHPSESSID;
fastcgi_cache_revalidate on;
fastcgi_temp_path /tmp/fcgi 1 2;
fastcgi_cache MAIN;
fastcgi_cache_key "$scheme|$request_method|$host|$request_uri";
fastcgi_cache_lock on;
fastcgi_cache_methods GET HEAD;
fastcgi_ignore_headers "Cache-Control" "Expires";
fastcgi_cache_valid 10s;
add_header X-My-Cache $upstream_cache_status;
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty;
index index.html index.php;
location / {
fastcgi_cache_revalidate on;
try_files $uri $uri/ /index.php$is_args$args;
}
location ~* "^/wp-admin(/.*$|/$|$)" {
fastcgi_cache off;
try_files $fastcgi_script_name =404;
fastcgi_pass $sock;
add_header X-My-Cache-admin $upstream_cache_status;
}
location ~* "^/cart(/.*$|/$|$)" {
fastcgi_cache off;
try_files $fastcgi_script_name =404;
fastcgi_pass $sock;
add_header X-My-Cache-cart $upstream_cache_status;
}
location ~* \.php$ {
fastcgi_cache_revalidate on;
try_files $fastcgi_script_name =404;
fastcgi_pass $sock;
}
# Static files location
location ~*
^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$
{
expires 60d;
access_log off;
}
}
версии софта:
nginx version: nginx/1.9.15 (из официального репозитория)
PHP 5.4.45-1~dotdeb+7.1
Debian GNU/Linux 7
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: location для уникального uri
Добрый день,
попробуйте так:
location = /js/data/city_base.js {
include /etc/nginx/am_proxy.conf;
}
подробнее: http://nginx.org/ru/docs/http/request_processing.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как сделать правильный rewrite
Есть url domain.ru/sub/ нужно сделать так чтобы при переходе на
domain.ru/sub/sub1 открывался domain.ru/sub
Сделал так но ни чего не получается
location ^/sub/* { rewrite ^/sub/(.*)$ /sub/ break; }
Подскажите пожалуйста как грамотно сделать location и rewrite
location ~* ^/sub/(.*)$ {
rewrite ^ /sub;
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
как уменьшить размер кеша nginx?
Добрый день, есть старый, но довольно большой https legacy-сайт на php и у владельцев нет ресурсов его переделывать. сайт состоит из нескольких миллионов страниц в районе 60 кб каждая (14 кб после gzip на nginx). основной трафик на сайт - поисковый по низкочастотным запросам и если распарсить логи, получается что за сутки загружается порядка сотен тысяч уникальных страниц (как поисковыми роботами и пауками, так и клиентами) и редко какая страница загружается больше чем 2 раза за сутки. для обеспечения хотя бы минимальной отказоустойчивости, есть идея кешировать ответы backend'а, чтобы в случае его падения (задумчивости) была возможность отдать хоть что-то через fastcgi_cache_use_stale. но размер кеша всех целевых страниц сайта превысит все разумные пределы (60кб х 1 000 000 страниц ≈ 58 гб) каким образом можно сжимать кеш nginx, кроме доработки приложения, так, чтобы оно сразу отдавало сжатый ответ? ( здесь я читал: http://forum.nginx.org/read.php?21,256725,256739#msg-256739 ) как один из вариантов вижу использование какой-нибудь файловой системы, которая умеет сжимать файлы на лету, но тут много вопросов к скорости работы fuse (по крайней мере раньше она работала медленно, изменилась ли ситуация?) в принципе, cloudflare мог бы решить задачу, если купить бизнес план и закачать туда свои сертификаты, но интересно рассмотреть вариант с nginx, потому как у cloudflare есть ещё косяки с доступностью для некоторых клиентов и роботов. может быть у кого-либо есть похожий опыт? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Свои настройки php для разных location
Можно ли задавать разные настройки php для разных location но с одним пулом? если это настройки php.ini, то можно так fastcgi_param PHP_VALUE sessions.save_path=/home/www/sessions/ fastcgi_param PHP_ADMIN_VALUE open_basedir=/home/www/docs ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Свои настройки php для разных location
конфиг:
server {
listen 80;
server_nametest.com;
error_log /home/user/logs/test.com.error.log error;
access_log /home/user/logs/test.com.access.log wtimes buffer=16k flush=1m;
root /www/user/domains/test.com/public_html/;
set $sock unix:/home/user/domains/test.com/socket.sock;
index index.html index.php;
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
location = /z.php {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param DOCUMENT_ROOT /public_html;
fastcgi_param SCRIPT_FILENAME /public_html$fastcgi_script_name;
fastcgi_param PHP_ADMIN_VALUE memory_limit=64M;
fastcgi_param PHP_ADMIN_VALUE memory_limit=512M;
try_files $fastcgi_script_name =404;
fastcgi_pass $sock;
}
location ~* \.php$ {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param DOCUMENT_ROOT /public_html;
fastcgi_param SCRIPT_FILENAME /public_html$fastcgi_script_name;
fastcgi_param PHP_ADMIN_VALUE memory_limit=64M;
try_files $fastcgi_script_name =404;
fastcgi_pass $sock;
}
}
проверяем через print_r(ini_get_all(null, false));
делаем запрос к http://test.com - показывает [memory_limit] = 512M
делаем запрос к http://test.com/z.php - показывает [memory_limit] = 64M
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Свои настройки php для разных location
прошу прощения за допущенные в предыдущем письме неточности проверяем через print_r(ini_get_all(null, false)); делаем запрос к http://test.com - показывает [memory_limit] = 512M делаем запрос к http://test.com/z.php - показывает [memory_limit] = 64M конечно же, наоборот: делаем запрос к http://test.com - показывает [memory_limit] = 64M делаем запрос к http://test.com/z.php - показывает [memory_limit] = 512M ну и формат access лога закрался кастомный. а также для локейшна /z.php два раза выставляется memory_limit, но применяется последнее значение. А покажите конфиг fpm, который слушает socket.sock? [test.com] prefix = /www/user user = www-data group = www-data listen = /home/user/domains/test.com/socket.sock; listen.owner = www-data listen.group = www-data listen.mode = 0666 pm = ondemand pm.max_children = 10 pm.process_idle_timeout = 5m; pm.max_requests = 500 slowlog = logs/php5-test.com-slow.log request_slowlog_timeout = 2s rlimit_files = 4096 chroot = domains/test.com env[HOSTNAME] = $HOSTNAME env[PATH] = /usr/local/bin:/usr/bin:/bin env[TMP] = /tmp env[TMPDIR] = /tmp env[TEMP] = /tmp catch_workers_output = yes php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f i...@test.com php_flag[display_errors] = off php_admin_value[error_log] = log/php5-test.com-error.log php_admin_value[error_reporting] = E_ALL ~E_DEPRECATED ~E_STRICT ~E_NOTICE ~E_WARNING php_admin_flag[log_errors] = on php_admin_value[memory_limit] = 128M php_admin_value[max_execution_time] = 60 php_admin_flag[allow_url_fopen] = Off php_admin_flag[allow_url_include] = Off php_admin_value[disable_functions] = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: referer https-http
А можете подсказать как это реализовать?
а Вы не могли бы ещё раз подробно рассказать как сейчас у Вас всё
настроено и как оно работает?
чтобы лучше понять проблему, я поднял тестовые конфигурации вида:
srv1:443 - он перенаправляет только специальный ури на http с кодом 301
server {
listen 443 ssl spdy;
[...]
location = /x.php {
return 301 http://srv1/x.php;
}
}
srv1:80 - генерирует php файл, который показывает переменные массива
$_SERVER (нас интересует HTTP_REFERER):
server {
listen 80;
server_name srv1;
root /www/srv1/public_html/;
set $sock unix:/www/srv1/socket.sock;
[...]
location = /x.php {
try_files $fastcgi_script_name =404;
fastcgi_pass $sock;
}
}
cat x.php
pre?php print_r($_SERVER); ?/pre
srv2:80 - здесь лежит тестовая ссылка в фале test.html вида a
href=https://srv1/x.php;x.php/a
теперь я открываю http://srv2/test.html и нажимаю на ссылку https://srv1/x.php
srv1 отвечает кодом 301 с заголовком Location: http://srv1/x.php
браузер делает туда запрос всё с тем же оригинальным Referer:
http://srv2/test.html
и мне показывают страницу вывода моего скрипта, который содержит строчку:
[HTTP_REFERER] = http://srv2/test.html
он же оригинальный реферер.
Соответственно на http не поступает оригинальный реферер (тот который
приходит на https).
Нужно его как-то получать в http запросах уже после редиректа.
т.е. у меня не получилось воспроизвести проблему
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: referer https-http
если же по Вашему сценарию srv2 это https сайт и ссылка, по которой
кликает клиент находится по ури https://srv2/test.html , то тогда
реферер не будет передаваться.
чтобы такое поведение изменить можно в локейшне с редиректом заново
переопределить этот заголовок, например так:
location = /x.php {
add_header Referer $http_referer;
return 301 http://srv1/x.php;
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: referer https-http
На этих uri нельзя использовать небезопасное соединение. :( я не предлагаю Вам использовать небезопасное соединение на этих uri, я предлагаю Вам изменить политику передачи реферера браузером при переходе с ресурса, доступного по протоколу https на протокол http, путём добавления специального тега в начало страницы. но теперь я прочитал ещё раз внимательно и понял, Вам нужно сохранить и заново передать *оригинальный* реферер :) поэтому написанное выше Вам не поможет если редирект осуществляется в браузере пользователя, то наверное контролировать (фактически, заспуфить) реферер не получится, можно, конечно передать через параметры.. но наверное самый простой способ использовать proxy_pass ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: referer https-http
добрый день, Сайт имеет две версии http и https. https используется только для определенных uri, с которых запросы редиректятся на http. Соответственно на http не поступает оригинальный реферер (тот который приходит на https). Нужно его как-то получать в http запросах уже после редиректа. попробуйте использовать тег meta name=referrer content=unsafe-url, подробнее читайте тут: http://www.w3.org/TR/referrer-policy/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
Половина попыток подключиться будет обламываться по таймауту. в итоге клиенты будут не довольны ? да. я уже много лет с нетерпением жду того момента, когда браузеры научатся понимать SRV записи типа а они имеют вид: _service._proto.name. TTL class SRV priority weight port target. т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с mx записями - задавать вес для айпишников так: _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. тогда будет счастье и отказоустойчивость без ботлнеков.. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: как лучше управлять кешированием fastcgi_cache
Нет. При кешировании заголовки If-Modified-Since и If-None-Match
на бекенд не передаются (за исключением ревалидации кеша самим
nginx'ом), так что в ключе их указывать бессмысленно и может
принести лишь проблемы.
спасибо!
Если нужна обработка одним и тем же index.php, то в нужных
location'ах явно указывать SCRIPT_FILENAME.
вынес в отдельные location'ы то, что требует особых параметров
кеширования, а сами настройки кеширования теперь задаются на уровне
server.
Лучше - по возможности избегать использование if'ов и rewrite'ов.
А вот как убирать слэши в конце URI без rewrite я не смог придумать
(так, чтобы было перенаправление на URI без слэша) - есть ли какое-то
иное решение?
Также не совсем понятно, как избавится от if, когда на то, нужно ли
кешировать (отдавать закешированный) контент, влияет несколько
факторов (есть ли определённая кука ИЛИ метод запроса post ИЛИ есть
аргументы (например)). Возможно ли и стоит ли переписать это на map'ы
и как это будет выглядеть? Как бы сделали Вы?
fastcgi_cache_path /run/shm/MAIN levels=1:2 keys_zone=MAIN:64m
max_size=100m inactive=240h;
server {
listen 80;
server_name domain.com;
error_log /var/log/nginx/domain.error.log error;
access_log /var/log/nginx/domain.access.log;
root /home/user/domain.com/public_html/;
set $no_cache 0;
if ($request_method = POST) {
set $no_cache 1; # не кешируем POST
}
if ($https = on) {
set $no_cache 1; # не кешируем https
}
if ($query_string != ) {
set $no_cache 0; # кешируем страницы с аргументами
}
# не кешируем, если есть такие куки
if ($http_cookie ~*
auth_user|login|comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in)
{
set $no_cache 1;
}
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /public_html/index.php;
fastcgi_param DOCUMENT_ROOT /public_html;
fastcgi_param KOHANA_ENV production;
# если $no_cache отличен от нуля, отдаём некешированную страницу
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;
# ревалидируем элемент кэша при помощи условных запросов с полем
заголовка If-Modified-Since
fastcgi_cache_revalidate on;
fastcgi_temp_path /run/shm/fcgi 1 2;
fastcgi_cache MAIN;
fastcgi_cache_key $scheme|$request_method|$host|$request_uri;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
fastcgi_cache_valid 1h;
fastcgi_cache_valid any 10s;
fastcgi_cache_use_stale updating error timeout invalid_header
http_500; # отдаём устаревший закешированный ответ в этих случаях
rewrite ^/(.*)/$ /$1 redirect; # все ури должны быть без слэша на конце
location / {
try_files $uri /index.php$is_args$args;
}
location ~* ^/(admin|search)((/.*)$|/$) {
set $no_cache 1;
fastcgi_pass 127.0.0.1:9001;
}
location ~* ^/(news|feed)((/.*)$|/$) {
fastcgi_cache_valid 10m;
fastcgi_pass 127.0.0.1:9001;
}
location = /index.php {
fastcgi_pass 127.0.0.1:9001;
}
# все остальные .php файлы
location ~* \.php$ { return 403; }
# статика
location ~*
^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$
{
expires 60d;
access_log off;
}
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: как лучше управлять кешированием fastcgi_cache
Лучше ещё переделать конфиг так, чтобы fastcgi_cache был включён
только там, где используется.
Ибо если кеш выключен - это одно, а если он включён, но ему
сказали bypass / no cache - это немного другое. В частности, при
обработке HEAD-запросов, а равно условных запросов будут различия
(при включённом кеше на бекенд вместо HEAD уйдёт GET, а If-*
заголовки будут убраны).
интересно, будем иметь в виду
А вот как убирать слэши в конце URI без rewrite я не смог придумать [..]
Такие вещи лучше всего делать внутри приложения, а не на конфигах
nginx'а.
хорошо, переделаем при возможности
Также не совсем понятно, как избавится от if, когда на то, нужно ли
кешировать (отдавать закешированный) контент, влияет несколько
факторов (есть ли определённая кука ИЛИ метод запроса post ИЛИ есть
аргументы (например)). Возможно ли и стоит ли переписать это на map'ы
и как это будет выглядеть? Как бы сделали Вы?
И такие вещи лучше всего делать в рамках приложения, возвращая
корректные значения Cache-Control.
Впрочем, если речь идёт про fastcgi_no_cache /
fastcgi_cache_bypass, то следует иметь ввиду, что эти директивы
принимают несколько параметров. [..]
о, действительно, надо ещё раз перечитать документацию по модулю, т.к.
за последние годы появилось много очень удобных и полезных директив, а
я по-инерции продолжаю использовать костыли и воркэраунды от ранних
версий, да ещё и исправленые множество раз, которые содержат
логические ошибки, как показал Валентин.
не кешируем POST
http://nginx.org/r/fastcgi_cache_methods/ru
спасибо!
Обращаю ваше внимание на то, что вы таким образом разрешаете
кешировать POST запросы по https с аргументами. Сомневаюсь,
что именно такая логика вам была нужна.
действительно, а ведь в одной продакшн системе так и крутится - пойду
исправлять - спасибо!
Скорее всего вы хотите:
map $args $empty_args {
default 0;
1
}
fastcgi_no_cache $empty_args $https $cookie_auth_user $cookie_login .. ;
да, именно так и требовалось
в данном же конкретном случае нужно кешировать ответы безотносительно
того, имеет ли запрашиваемая страница аргументы или нет. поэтому
конечный конфиг будет выглядеть как-то так (без map, а на других
проектах оно будет использоваться), но мы будем учитывать те
рекоммендации, которые дал Максим. Всем огромное спасибо, я многое
сегодня понял.
fastcgi_cache_path /run/shm/MAIN levels=1:2 keys_zone=MAIN:64m
max_size=100m inactive=240h;
server {
listen 80;
server_name domain.com;
error_log /var/log/nginx/domain.error.log error;
access_log /var/log/nginx/domain.access.log;
root /home/user/domain.com/public_html/;
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_param SCRIPT_FILENAME /public_html/index.php;
fastcgi_param DOCUMENT_ROOT /public_html;
fastcgi_param KOHANA_ENV production;
# отдаём некешированную страницу и не помещаем такую страницу в кеш,
# если значение хотя бы одного из строковых параметров непустое и
не равно 0
fastcgi_no_cache $https $cookie_login $cookie_auth_user;
fastcgi_cache_bypass $https $cookie_login $cookie_auth_user;
fastcgi_cache_revalidate on;
fastcgi_temp_path /run/shm/fcgi 1 2;
fastcgi_cache MAIN;
fastcgi_cache_key $scheme|$request_method|$host|$request_uri;
fastcgi_cache_methods GET HEAD; # Если метод запроса клиента
указан в этой директиве, то ответ будет закэширован
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
fastcgi_cache_valid 20m;
fastcgi_cache_valid any 10s;
fastcgi_cache_use_stale updating error timeout invalid_header http_500;
rewrite ^/(.*)/$ /$1 redirect; # все URI должны быть без слэша на конце
location / {
try_files $uri /index.php$is_args$args;
}
location ~* ^/(admin|search)(/.*$|/$) {
fastcgi_cache off;
fastcgi_pass 127.0.0.1:9001;
}
location ~* ^/(news|feed)(.*$|/$) {
fastcgi_cache_valid 10m;
fastcgi_pass 127.0.0.1:9001;
}
location = /index.php {
fastcgi_pass 127.0.0.1:9001;
}
# все остальные .php файлы
location ~* \.php$ { return 403; }
# статика
location ~*
^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$
{
expires 60d;
access_log off;
}
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление кешом - фичареквест
удалить элемент из кеша можно директивой http://nginx.org/r/proxy_cache_bypass/ru по ключу (т.е. новый элемент возмётся не из кеша, но закешируется) нет это совсем не то что в фичареквесте. ... я хочу получить механизм внутри обработчика сбросить кеш на другом роуте. как вариант - выдать хидер с урлом кеш на котором надо сбросить. а директивы в конфиге = это не программа это набор условий :) я раньше решал похожую проблему с помощью модуля ngx_cache_purge ( http://wiki.nginx.org/CachePurgeChs ). создавал в nginx специальный локейшн (/purge/), при обращении к которому удалялся из кеша указанный элемент. Т.е. после изменения в базе, запрос по этому локейшну делает само приложение (для wordpress есть специальный плагин). Подробнее (с конфигами) можно почитать тут: http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html но теперь, я бы попытался реализовать соответствующий функционал без стороннего модуля, а только директивой proxy_cache_bypass. Таким образом, применяя предложенную мной схему, вместо того чтобы просто отдать nginx страницу с заголовком X-Cache-Invalid: /users/top/123?all=yes, вам придётся сначала сделать запрос из приложения по адресу /purge/users/top/123?all=yes и элемент кеша обновится. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проблема с chroot в связке Nginx + PHP-FPM
chroot = /home/kursk.dyndns.org/www .. Если разместить в /home/kursk.dyndns.org/www/ файл index.php со строчкой phpinfo(); то всё прекрасно открывается. Но если залить тот же phpBB3, то всё время наблюдается белая страница (в php.ini прописан параметр display_errors=1). Если chroot убрать, то всё открывается нормально. В чём может быть проблема? Уже несколько дней бьюсь((( Мне кажется, что причина может быть во временных файлах и в механизме сессий php. Подробнее, конечно, можно узнать из логов - посмотрите error log nginx на предмет ошибок php типа can't create. В любом случае, внутри chroot необходимо создать папку /tmp (а можно ещё и /logs) - ведь php запускается внутри срута и временные файлы хочет создавать там же. cd /home/kursk.dyndns.org/www mkdir -p logs chmod 1777 logs mkdir -p tmp chmod 1777 tmp mkdir -p www а также иногда приходиться воссоздать всю иерархию папок и файлов, которые могут понадобиться для работы phpBB: (т.е. если ему нужен sendmail, то его нужно скомпилить со статическими библиотеками и положить в /www/bin, если bash, то то же самое сделать с bash-static ) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: not www
Что то вроде
server_name www.*
#тут редирект на домен без www
В голову приходит только пропустить $host через регулярку.
у меня для этих целей есть отдельный блок server:
server {
# редирект на основной домен (он без www) для всех сайтов.
# возможно оверрайдить данную настройку указав в кофиге самого сайта
в директиве server_name домен с www.
server_name ~^www\.(?SERVERNAME.+)$;
# обязательно указываем ip:port, ибо сайты привязаны к айпишникам и
иначе данный server не будет обрабатывать запросы
listen 91.11.11.11:80;
listen 91.11.11.12:80;
return 301 $scheme://$servername$request_uri$is_args$args;
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
фреймфорк + отдельные php-файлы
Добрый день.
Подскажите как грамотнее написать конфиг для сайта, который использует
фреймворк и несколько отдельно лежащих php сценариев.
иерархия примерно такая:
/application/
/system/
/modules/
/static/
/upload/
/customphp1/
/customphp2/
..
/customphp30/
index.php
где customphp - папка с произвольным названием внутри которой
находятся php файлы, которые можно запускать при прямом обращении к
ним из браузера. таких папок может быть достаточно много.
Пока планирую так: для самого фреймворка стандартно:
location / {
try_files $uri $uri/ @drupal;
}
location @drupal {
fastcgi_pass ...;
fastcgi_param SCRIPT_FILENAME /path/to/index.php;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param QUERY_STRING q=$uri$args;
... прочие fastcgi_param
}
Но при обращении к файлам /somedir/not-to-be-viewed.php - nginx будет
отдавать их прямо в браузер..
Можно перечислить папки фреймворка и закрыть к ним доступ например так:
location ~ ^/(application|system|modules)/ {
deny all;
}
Запуск php из папок со статикой тоже запрещаем:
location ~* ^/(?:uploads|static)/.*\.php$ {
deny all;
}
А вот как правильно реализовать возможность запускать отдельно
лежащаие php сценарии - перечислять вручную таким образом?
location ~* /customphp1/(?:.*)\.php {}
Как лучше сделать и что поправить?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
