Quantcast
Channel: Nginx Forum - Nginx Mailing List - Russian
Viewing all 3102 articles
Browse latest View live

Fedora 19 не тянет (1 reply)

$
0
0
Пытаюсь перейти с Fedora 14 (2.6.35.14-97.fc14.x86_64) на Fedora 19
(3.10.11-200.fc19.x86_64)

worker_processes 40;
events {
worker_connections 8000;
use epoll;
}
http {
proxy_headers_hash_max_size 8096; # default was: 512
proxy_headers_hash_bucket_size 128; # default was: 64
variables_hash_max_size 1024;
variables_hash_bucket_size 128;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
charset utf-8;
resolver 127.0.0.1; # necessary for dynamic upstream resolution
limit_req_log_level warn;
proxy_intercept_errors on;
server {
listen 80;
location = /service_check_nginx { echo "nginx"; }
}
}


Симптомы:

* ab -n1000000 -c1000 'http://localhost/service_check_nginx'
(параллельно 4 раза, т.е. 4000 одновременных соединений)
говорит что некоторые запросы занимают >3сек

* netstat -s:
...
1269313 times the listen queue of a socket overflowed
1282868 SYNs to LISTEN sockets dropped
...

Растёт со скоростью примерно 2000/сек, иногда больше


* CPU загрузка не одинакова по workers:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27671 nobody 20 0 418.6m 149.2m 1.1m S 51.1 0.1 0:00.77 nginx: worker process
27685 nobody 20 0 418.6m 149.2m 1.1m S 39.7 0.1 0:01.76 nginx: worker process
27661 nobody 20 0 418.6m 149.2m 1.1m S 22.7 0.1 0:01.63 nginx: worker process
27688 nobody 20 0 418.6m 149.2m 1.2m S 22.7 0.1 0:01.90 nginx: worker process
27697 nobody 20 0 418.6m 149.2m 1.1m S 17.0 0.1 0:00.95 nginx: worker process
27666 nobody 20 0 422.0m 152.3m 1.1m R 7.6 0.1 0:01.50 nginx: worker process
27701 nobody 20 0 419.3m 149.7m 1.1m S 1.9 0.1 0:00.01 nginx: worker process
27650 nobody 20 0 418.6m 149.9m 1.8m S 0.0 0.1 0:03.52 nginx: worker process
27658 nobody 20 0 418.6m 149.2m 1.1m S 0.0 0.1 0:01.30 nginx: worker process
27664 nobody 20 0 419.0m 149.5m 1.1m S 0.0 0.1 0:01.86 nginx: worker process
27669 nobody 20 0 418.6m 149.2m 1.1m S 0.0 0.1 0:00.35 nginx: worker process
27672 nobody 20 0 418.6m 149.2m 1.1m S 0.0 0.1 0:00.23 nginx: worker process


а на F14:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30042 nobody 20 0 1224m 955m 17m R 41.2 0.4 523:24.45 nginx: worker process
30038 nobody 20 0 1224m 955m 17m S 39.4 0.4 522:24.30 nginx: worker process
30047 nobody 20 0 1224m 955m 17m R 39.4 0.4 520:35.36 nginx: worker process
30053 nobody 20 0 1224m 955m 17m R 39.4 0.4 520:42.77 nginx: worker process
30027 nobody 20 0 1224m 955m 17m S 37.6 0.4 520:55.20 nginx: worker process
30036 nobody 20 0 1224m 955m 18m R 37.6 0.4 525:26.07 nginx: worker process
30037 nobody 20 0 1224m 955m 17m S 37.6 0.4 523:59.09 nginx: worker process
30041 nobody 20 0 1224m 955m 17m R 37.6 0.4 529:31.88 nginx: worker process
30049 nobody 20 0 1224m 954m 17m R 37.6 0.4 519:58.73 nginx: worker process


Кстати, если ставлю worker_connections 800 (worker_processes 40) и запускаю "ab -c1000 ..." -- то ab отваливается с ошибкой (на F19).

Где же дальше копать?

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

ошибка 400 request header or cookie too large (2 replies)

$
0
0
Добрый день!
Ошибку 400 Bad request (request header or cookie too large) выдает
nginx, стоящий на фронт-енде (на бэк-енде апач). Ошибка плавающая, может быть при посещениях разных ссылок с разных браузеров.
Жалуются клиенты региональные. В Москве ни у кого, в т.ч. у себя отловить не смог.
Подскажите, куда копать. Можно ли как-то включить лог таких ошибок.
Спасибо.

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

directio_alignment (7 replies)

$
0
0
Приветствую,
Имеет ли смысл данный параметр ставить в 4к при ФС с соответствующими
блоками на SSD?
Заранее благодарю.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Теперь нельзя выставлять тип контента! (3 replies)

$
0
0
Здравствуйте,

Обновили nginx до версии 1.5.5 и perl-скрипты перестали отдавать файлы, в лог выпадает следующее:
"header already sent while reading response header from upstream"

Нашёл, что всему виной вот этот коммит: http://hg.nginx.org/nginx/rev/03ff14058272
Он проверяет, если заголовок уже отправлялся, то это ошибка.

Но как быть? Нам перед тем как сделать внутренний редирект обязательно нужно установить MIME-тип, так как редирект будет на файл без расширения, и если не установить явно тип контента, то nginx сам установит application/octet-stream.

Устанавливаем из скрипта тип контента таким образом:
$r->send_http_header("$mime")

Если убрать эту строку, то всё работает, но отдаётся с application/octet-stream.

nginx proxy vs memcached data (no replies)

$
0
0
Подскажите пожалуйста, никак не могу сообразить, как сделать так, чтобы данные возвращаемые memcached-сервером, использовать в качестве uri для дальнейшего проксирования с помощью nginx? Можно ли их поместить в какую-либо переменную, а потом сделать proxy_pass $var; ? Или как-то иначе....

Fwd: Авторизация с помощью SSL (1 reply)

$
0
0
Здравствуйте.
Пытаюсь реализовать авторизацию с помощью SSL сертификатов, но получаю
ошибку:
400 Bad Request
The SSL certificate error

Схема подписи:
CA -> Промежуточный CA -> клиентский сертификат.
Насколько я понял, проблема именно в том, что клиентский сертификат
подписан промежуточным центром сертификации, а не корневым (при подписи
корневым все было нормальноe).

server {
listen 456;
ssl on;
ssl_certificate /var/www/client/data/www/client.ru/ssl/ca.crt;
ssl_certificate_key /var/www/client/data/www/client.ru/ssl/ca.key;
ssl_client_certificate /var/www/client/data/www/client.ru/ssl/pca.crt;
ssl_verify_client optional;

...
}
--
С уважением,
Тищенко Андрей.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Генерация ответа для клиента и асинхронные сокеты (1 reply)

$
0
0
Добрый день!

Мой модуль работает по следующему алгоритму:
1) Получает заголовок от клиента;
2) Записывает по специальному формату заголовок в сокет другого сервера;
3) Закрывает на запись сокет;
4) Читает ответ: заголовок и html-страницу из этого же сокета;
5) Отдаёт полученный заголовок и html клиенту.

Всё бы было хорошо, но работать с сокетами нужно асинхронно, а сейчас чтение и запись происходит блокирующим способом.
Подскажите, следуя каким принципам, я должен составить код для асинхронного получения заголовка и html из сокета?

Прочитал про регистрацию событий в этой статье: http://green-shaman.livejournal.com/32600.html. Но там не написано, где я должен вызывать функцию регистрации событий и где могу разместить код, отрабатывающий после прочтения всего ответа из сокета?

Учитывает ли nginx-прокси кэш-заголовки с бэкенда? (3 replies)

$
0
0
День добрый!
Изучаю nginx, разбираюсь в кэшировании, имею browser + nginx reverse proxy + nginx web-server.

Допустим клиент сделал запрос, прокси перевел его на бэкенд, тот ответил и прокси отдал ответ клиенту. Допустим бэкенд проставил какие-то заголовки, связанные с кэшем, например:
Cache-Control: no-cache (или)
Cache-Control: max-age=100000 (или)
Expires: 'Next Friday'

Вопрос 1: следующий запрос клиента к этому ресурсу будет обработан с учетом этих заголовков?
Вопрос 2: как nginx-proxy понимает что ресурс stale и его не надо отдавать клиенту, а надо спросить бэкенд? (кроме директивы proxy_cache_valid) Может ли он понять это из заголовков ответа бэкенда?
Вопрос 3: может ли клиент заставить прокси закрузить свежую версию ресурса, которая еще не истекла согласно proxy_cache_valid?

Я пробую играть с заголовками Cache-Control прокси и бэкенда, и насколько я могу судить, если ресурс закэшировался в прокси ничто не поможет мне получить его свежую версию кроме удаления кэша или истечения proxy_cache_valid. То есть "модель" кэша nginx reverse proxy это просто веб-сервер с контентом, равным тому, что удалось закэшировать, а что именно кэшировать определяется тем, не ставит ли бэкенд Cache-Control: no-cache или no-store; заголовки Expired, Cache-Control: max-age бэкенда не учитываются.

Я правильно понимаю, или нет?
Так работают все прокси, и squid, и разные публичные прокси в интернете?
Изменить ли что-то, если nginx-proxy соединяется с клиентом по SSL?

ssl_crl non-critical (no replies)

$
0
0
Добрый день!

Подскажите, пожалуйста, по поводу указанной инструкции:
ошибка проверки клиентского сертификата (если SN есть в списке отзыва) возникает только в случае, если CDP extention отмечен как critical?

Версия nginx 1.2.9.
ssl on;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
ssl_certificate server.crt;
ssl_certificate_key server_private.key;
ssl_verify_client on;
ssl_client_certificate root.crt;
ssl_crl revoked.crl;

Вопрос к старым программистам: визуальное програмирование :) (1 reply)

$
0
0
Вопрос к зубрам!

Есть большая многокомпонентная система. Компоненты опираются друг на друга
достаточно затейливыми конфигурированием, сам процесс которого нетривиален.
То есть типичный выкат в бой с нуля ещё как-то реален, но быстрое
динамическое переконфигурирование - задача не для слабонервных.

Речь идёт не о типовых перестановках, которые конечно же можно
запрограммировать. Например, есть несколько слегка отличающихся экземпляров
одной и той же компоненты, которые последовательно подключаются одна за
другой к общей системе и мы смотрим, как система взаимодействует с каждой
из них.

Весь опыт попыток подхода к этому снаряду показывает то, что любая система
автоматизации подобного динамического переконфигурирования ОЧЕНЬ БЫСТРО
устаревает (так как вся система растёт и развивается,
меняются/добавляются/удаляются конфигурационные параметры) подобно тому,
как устраревает документация.

Тыщу лет назад мелькал кейс о том, как решать эту задачу. - путём обычного
визуального конструктора похожего на лего или на пазл. С таким визуальным
конструктором очень удобно быстро перекидывать связи между компонентами. И
вроде бы кейс был достаточно удачен.

Может ли кто-то что-то рассказать о своих подходах к этому "снаряду"?
Пожалуйста, не рассказывайте мне о том, как это надо делать. Расскажите о
том, как вы делали и на какие грабли наткнулись.

---
Dmitriy V. Simonov,
Perl & Python programmer
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Перезапись Referer по условию (no replies)

$
0
0
Привет всем, столкнулся с необходиомстью тестирования подключаемых
шрифтов на сайтах через сервисы typekit.com и fonts.com

Суть сводится к подключению в html коде js скрипта

fonts.com
<script type="text/javascript"
src="http://fast.fonts.net/jsapi/8163d577-49e6-9656-88c9-d8609ff327a1.js"></script>

typekit.com
<script type="text/javascript" src="//use.typekit.net/0cd8xtd.js"></script>

В админке каждого из сервисов прописывается для каких доменов будет
отдаваться данный шрифт, проверка производится по полю Referer.

И вот собственно возникла проблема, необходимости тестирования данных
сайтов из 3х разных мест, при этом в админке должен быть указан только
один реальный домен.

Что на данный момент: каждый раз приходится заходить в админку соотв
сервиса и менять домен. Часто клиент не дает доступов и приходится
дергать его, что очень неудобно.

Хотелось бы избежать подобной ситуации, и в настройках сервисов
прописать только localhost. Для этого я завернул на шлюзе все
обращения к fast.fonts.net (93.184.220.188) и use.typekit.net
(93.184.220.20) на nignx.

# iptables -I PREROUTING -p tcp -s 192.168.0.0/16 -d 93.184.220.20
--dport 80 -j DNAT --to-destination 192.168.1.1:80

# iptables -I PREROUTING -p tcp -s 192.168.0.0/16 -d 93.184.220.188
--dport 80 -j DNAT --to-destination 192.168.1.1:80

Внутри локальной сети подняты два внутр домена, typekit.example.net и
fonts.example.net и соотв следующий конфиг nginx

server {
listen 192.168.1.1:80;
server_name _;

location / {

if ($http_referer ~ '^http://typekit.example.net/') {
set $referer http://localhost;
proxy_pass http://93.184.220.20:80;
}

if ($http_referer ~ '^http://fonts.example.net/') {
set $referer http://localhost;
proxy_pass http://93.184.220.188:80;
}

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Referer $referer;
}
}

И все бы классно, за исключением двух моментов:

1. Многие сайты используют эти сервисы для размещения css, например,
wordpress.org, fonts.com, typekit.com и т.д. Хотелось бы для всех
сайтов, кроме typekit.example.net и fonts.example.net пропускать
запросы без модификаций

2. Необходимо как то сделать исключения для наших внешних тестовых
серверов (с внешними доменными именами). Т.е. например, если
http_referer = project.domain.com, то мы ничего не делаем с запросом,
а просто перенаправляем на соотв сервер (typekit.com или fonts.com)

Читал, что http://wiki.nginx.org/IfIsEvil крайне не желательно
использовать if в Location, может есть более элегантный способ решить
данную задачу?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Сервер по-умолчанию для конкретного домена (6 replies)

$
0
0
Всем привет,

Возникла задача:

- На один nginx ссылаются >1 домена, при этом, для каждого из них должен
быть доступен SSL (есть сертификаты).
- Все запросы к несуществующим на сервере хостам должны попадать в некий
хост по-умолчанию (и редиректиться оттуда rewrite-ом, но это частности).

Т.е, поступает запрос. Если есть сервер, для которого запрошенный хост
прописан в server_name - отправляем его туда. Если нет - в сервер
по-умолчанию для domain.tld, откуда его регулярка отправляет "по адресу"
(на главный сайт в зависимости от запрошенного домена).

Классическая схема (сервера + один сервер с опцией default) прекрасно
работала до тех пор, пока домен был один, а сейчас - не вариант, т.к. мы не
можем прописать в сервере больше, чем 1 SSL-сертификат (в результате чего
пользователь при обращении к несуществующему серверу по домену, отличному
от первого вместо ожидаемого редиректа получает неожиданный
FailedCertificateAlert от браузера и блокировку дальнейшего редиректа).

Если же создать сервер с server_name = *.domain.tld для каждого домена, то
туда попадают все запросы, даже те, для которых есть отдельные server-ы.

Есть какой-то нормальный путь это обойти? Например, задавать приоритет
серверу (тогда можно поставить минимальный умолчальному серверу и запрос
таки будет улетать туда только тогда, когда более подходящих серверов нет).
Или выбирать сертификат в зависимости от домена (по IF-у)?

--
With best regards,
differentlocal (www.differentlocal.ru | differentlocal@gmail.com),
System administrator.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

upstream prematurely closed connection while reading response header from upstream (no replies)

$
0
0
Вопрос, если в логе nginx

появляется сообщение (раз в 10-20 обновлений страницы)

upstream prematurely closed connection while reading response header
from upstream

и при этом на бэкенде в логах конкретно об этом запросе ни чего нет

но предыдущие запросы и последующие запросы нормально логируются.

Зачит куда нужно копать ?

Я понимаю, что дело в бэкенде, тем более, что я менял бэкенд - со старым
все работает нормально.

Проверял работу через HTTPS поднятом на nginx c валидными сертификатами.
Использовать для тестов 443 порт не могу, т.к. через него сейчас
работают люди со старым сервером.

Другой backend - очень старая версия redmine под apache и из старой
ubuntu 10.04
Новый backend - lxc контейнер с новой версией redmine и новым apache из
ubuntu 12.04 на том же же серевере где стоит прокси nginx.

Спасибо.



--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

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

Управление бэкендами (14 replies)

$
0
0
Приветсвую

Nginx стоит как frontend. За ним находится несколько десятков или более
бэкендов (разные servername). Необходимо динамически управлять на какой
бэкенд запрос упадет.

Править nginx.conf и перечитывает его не вариант, т.к. это может
происходить ежесекундно.

Думал хранить соответствие servername -> backend в memcached, но nginx
похоже только умеет доставать http response и memcached.

Остается только Nginx -> Perl -> Memcached. Или есть еще варинаты? lua?

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

Можно ли определить делимость числа ? (7 replies)

$
0
0
Можно ли в nginx без использования сторонних модулей ( в перле или в lua это можно сделать ) определить делимость числа на какое-либо число, например 10 ?

Уточнение логики работы ngx_http_auth_request_module (26 replies)

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

Я установил nginx и модуль Максима Дунина (ngx_http_auth_request_module)
Настройку этого модуля производил по README от модуля.
Сам вебсервер собрал с такими параметрами в дебиане:

nginx version: nginx/1.3.14
built by gcc 4.4.5 (Debian 4.4.5-8)
TLS SNI support enabled
configure arguments: --with-openssl=/usr/build/openssl-1.0.1e
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug
--with-http_flv_module --with-http_geoip_module
--with-http_gzip_static_module --with-http_realip_module
--with-http_stub_status_module --with-http_ssl_module
--with-http_sub_module --with-ipv6 --with-mail --with-mail_ssl_module
--add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module
--add-module=/usr/build/ngx_http_auth_request_module

Предисловие для понимания возможности проявления архитектурной ошибки у
меня.
Я разработал модуль авторизации по pin+token поверх google authenticator
http://sourceforge.net/projects/simsim/
Он работает хорошо. Возвращает по локейшну /auth/ или 200 или 401 в разных
случаях.
Алгоритм проекта прост.
1) Клиент приходит в локейшн /auth/ без кук или с просроченными/неверными и
получает 401, предлагает перейти на /gauth/
2) /gauth/ выдаёт запрос basic auth на ввод данных. Данные обрабатывает
моим модулем. Если пара пин-токен подходящая, то
клиенту выдаются куки и его редиректят на /auth/ снова.
3) /auth/ получает куки и возвращает 200.
4) В последующие запросы браузер вставляет куки и прохождение /auth/
просиходит по их наличию без переходов на /gauth/
Проверка куки происходит совместно с обращением в редис, который их хранит..

Чтобы удалённо пользоваться своими проектами, я на фронте сделал reverse
proxy средствами nginx.
Запрос приходит на https://ssl.stremki.net/project_name/
Пример обработки локейшна:

location /nagios {
auth_request /auth/;
proxy_pass http://192.168.125.47;
proxy_buffering on;
proxy_set_header SSL NO;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 1800;
proxy_redirect off;
}

/auth/ локейшн описан по докумментации от Максима методом проксирования.
location /auth/ {
proxy_pass http://192.168.125.35/auth/;
proxy_pass_request_body off;
proxy_buffering off;
proxy_cache off;
proxy_set_header Content-Length "";
proxy_set_header Host 192.168.125.35;
}

Я пытался делать без проксирования, указывая URI
auth_request http://192.168.125.35/auth/
Но это не работало и я в логах nginx видел ошибку
2013/11/01 23:31:51 [error] 10938#0: *245 "/usr/local/nginx/htmlhttp://
192.168.125.35/auth/index.html" is not found (2: No such file or
directory), client: 192.168.125.47, server: ssl.stremki.net, request: "GET
/mail/ HTTP/1.1", subrequest: "http://192.168.125.35/auth/", host: "
ssl.stremki.net"

Было бы здорово, если бы я смог работать без проксирования /auth/.
Просто, пока не понял, как прописать внутренний бекенд для обработки и
сейчас
пользуюсь локейшном /auth/ в режиме проксирования.

Для наджиоса всё работает отлично.
Однако, есть точно такие же локейшны для ownCloud и RoundCube

Во время захода на https://ssl.stremki.net/mail/
nginx обрабатывает auth_request
Поскольку, cookie достаточную для прохождения /auth/ я посылаю, то я
получаю страницу логина в RoundCube.
Страница прогружается вся (все элементы: js скрипты, картинки).
Затем, когда я ввожу логин и пароль к RoundCube, браузер впадает в ожидание
ответа от nginx
В tcpdump на бэкенде, отвечающем за /auth/ я не вижу запросов в этот момент.

Для дополнительного тестирования, я поставил на клиентскую часть Burp Proxy
и пошагово прошёл весь процесс авторизации
От получения кук для /auth/ до попадания в вебинтерфейс уже самого ящика в
RoundCube.
И был удивлён. Так, как Burp запрашивает разрешение на каждый шаг (каждый
запрос), как дебаггер, то это даёт временные
промежутки между запросами браузера к nginx.
Если браузер делает запросы не моментально, а через промежутки 1-2 секунды,
то авторизация RoundCube отрабатывает и я
попадаю в почтовый ящик.

Я пока не очень хорошо знаю, как работает nginx во время проксирования
вкупе с модулем Максима и предполагаю, что он
не делает запрос к бекенду, отвечающему за локейшн /auth/ при большом
количестве запросов.
Возможно, я что-то не так настроил.

Помогите, пожалуйста, разобраться.
Спасибо.

--
<pre>
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
</pre>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Досрочное закрытие соединения по заголовкам браузера (5 replies)

$
0
0
В PHP под управлением Apache можно досрочно закрыть соединение, а затем продолжить выполнение скрипта в "фоновом" режиме, освободив при этом браузер пользователя: http://stackoverflow.com/questions/4806637/continue-processing-after-closing-connection.

Но если использовать Nginx между посетителем и Apache (кэширование не настроено), то такая схема не работает.

Возможно что-то сделать?

Проблема с загрузкой файлов на сервер (1 reply)

$
0
0
Дано:

1. VPS-сервер

2. Настройки PHP
— max_execution_time = 600
— max_input_time = 600
— memory_limit = 256M
— post_max_size = 100M
— upload_max_filesize = 100M
— max_file_uploads = 40

3. Настройки ngnix
— client_max_body_size 100M в настройках ngnix

При загрузке любых файлов (минимальный объем — 354 КБ) на сервер происходит следующее:
загружаются примерно до 30%, после этого состояние загрузки сбрасывается на 0%, файл снова загружается примерно на 30% и браузер (Chrome) выдаёт следующую ошибку: Ошибка 101 (net::ERR_CONNECTION_RESET): Соединение сброшено.

В других браузерах аналогичная ситуация.

malloc(270336) failed (3 replies)

$
0
0
Сегодня столкнулся со следующей проблемой:

2013/11/03 17:24:54 [emerg] 4532#1564: *1875523 malloc(270336) failed (8:
Not enough storage is available to process this command) while sending to
client, client: 5.10.83.57, server: ___.ru, request: "GET /6032/33621/
HTTP/1.1", upstream: "http://127.0.0.1:8081/6032/33621/", host: "____.ru"


Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

c:\nginx>nginx -V
nginx version: nginx/1.4.2
TLS SNI support enabled
configure arguments: --with-cc=cl --builddir=objs.msvc8 --with-debug
--prefix= -
-conf-path=conf/nginx.conf --pid-path=logs/nginx.pid
--http-log-path=logs/access
..log --error-log-path=logs/error.log --sbin-path=nginx.exe
--http-client-body-te
mp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp
--http-fast
cgi-temp-path=temp/fastcgi_temp --http-scgi-temp-path=temp/scgi_temp
--http-uwsg
i-temp-path=temp/uwsgi_temp --with-cc-opt=-DFD_SETSIZE=1024
--with-pcre=objs.msv
c8/lib/pcre-8.32 --with-zlib=objs.msvc8/lib/zlib-1.2.8 --with-select_module
--wi
th-http_realip_module --with-http_addition_module --with-http_sub_module
--with-
http_dav_module --with-http_stub_status_module --with-http_flv_module
--with-htt
p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module
--with-htt
p_random_index_module --with-http_secure_link_module --with-mail
--with-openssl=
objs.msvc8/lib/openssl-1.0.1e --with-openssl-opt=enable-tlsext
--with-http_ssl_m
odule --with-mail_ssl_module --with-ipv6


Что это было и как этого избегать в дальнейшем?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Как сделать редирект? (3 replies)

$
0
0
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Viewing all 3102 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>