Re: Высокое количество соединений между фронт-ендами и биддерами

[Andrey Velikoredchanin]

У нас похожее наблюдалось, когда мы офисный свич поставили между фронтом и
бэкэндом. Он банально не держал нагрузку. Если меняли аппаратуру, скорей
всего, дело в этом.

пт, 29 мар. 2019 г. в 10:37, Panichev Oleg :

> Проблема — высокое число timewait коннекшнов между nginx-proxy и бэкендами
> (до 30-40к), уровень трафика — десятки тысяч запросов в секунду извне, в
> основном короткие сессии на несколько запросов. Стек Centos 6 настроен на
> переиспользование tw sockets - tw_reuse=1, tcp_fin_timeout низкий (2с).
>
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NGINX to Join F5

[Andrey Velikoredchanin]

Примите наши поздравления! :)

пн, 11 мар. 2019 г. в 23:17, Igor Sysoev :

> Сегодня исторический день для NGINX.  Мы подписали соглашение о
> присоединении к компании F5.  Команда и я считаем это событие
> значимым этапом для наших открытых проектов, сообщества и компании.
>
> Для F5 крайне важны наши freeware opensource проекты. Мы не
> планируем никаких изменений в их названиях, лицензиях, командах
> разработчиков, периодичности выпусков и во всё остальном. F5
> приложит все усилия, чтобы проекты NGINX были ещё лучше.
>
> Наш CEO Гас Робертсон написал об этом более подробно:
> https://www.nginx.com/blog/nginx-joins-f5/
>
>
> --
> Igor Sysoev
> http://nginx.com
>
> ___
> 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

Re: Gzip + https: есть-ли смысл?

[Andrey Velikoredchanin]

Ясно. Спасибо всем за пояснения!

23 июля 2018 г., 15:34 пользователь Maxim Dounin 
написал:

> Hello!
>
> On Mon, Jul 23, 2018 at 08:57:08AM +0300, Andrey Velikoredchanin wrote:
>
> > Однако, он не совсем прояснил ситуацию. Попробую переформулировать...
> >
> > 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не
> > рекомендуется, т.к. есть проблемы с безопасностью.
>
> Всё так.  Именно из-за наличия этого механизма могло быть "что-то
> об этом слышал" в контексте SSL - одно время были попытки
> пропагандировать идею "gzip в HTTP не нужен, если есть сжатие на
> уровне SSL/TLS".  В современном мире этот механизм не
> используется, соответственно использование gzip'а ничем не
> отличается от такового в случае отсутствия SSL.
>
> > 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к.
> > это НЕ внутреннее сжатие SSL.
>
> Да, использование gzip'а для статического контента в случае SSL
> ничем не отличается от такового в случае без SSL.  Если выигрыш
> есть - сжатие стоит использовать, если нет - не стоит.  Если
> статика меняется редко, можно подумать об использовании
> gzip_static вместо gzip.
>
> > Я правильно понял?
>
> Да.
>
> Отмечу также, что в случае динамического контента и SSL проблема
> использования gzip приобретает дополнительные нюансы, так как
> результат может быть опять же уязвим к атакам, см.
> https://en.wikipedia.org/wiki/BREACH.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> 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

Re: Gzip + https: есть-ли смысл?

[Andrey Velikoredchanin]

У меня основная цель - текстовую статику жать: html, css, js (в среднем все
больше 1Кб). Для этого имеет смысл включать gzip под ssl?

23 июля 2018 г., 9:57 пользователь Илья Шипицин 
написал:

>
>
> пн, 23 июл. 2018 г. в 10:57, Andrey Velikoredchanin  >:
>
>> Максим, спасибо за ответ!
>>
>> Однако, он не совсем прояснил ситуацию. Попробую переформулировать...
>>
>> 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не
>> рекомендуется, т.к. есть проблемы с безопасностью.
>> 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к.
>> это НЕ внутреннее сжатие SSL.
>>
>
> пасьянс на самом деле более запутанный.
>
> gzip жмет тело ответа, но не заголовки. SSL теоретически, жмет в том числе
> заголовки (но ssl компрессия выключена при сборке nginx по причинам
> безопасности)
> в качестве вишенки на торте - http2, у него есть свои механизмы для
> минификации трафика (в том числе сжатые заголовки).
>
> если включать ssl компрессию, надо аккуратно, на ответах порядка 1Кб у нее
> по опыту отрицательный выигрыш
>
>
>>
>> Я правильно понял?
>>
>> 23 июля 2018 г., 1:59 пользователь Maxim Dounin 
>> написал:
>>
>>> Hello!
>>>
>>> On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote:
>>>
>>> > Извиняюсь если вопрос древний (а у меня есть такое подозрение), но
>>> > почему-то не смог найти информацию о том, имеет-ли смысл включать gzip
>>> для
>>> > статики если сайт работает через https? Я помню что что-то об этом
>>> слышал,
>>> > но, как уже отметил - не смог найти подтверждения этому.
>>>
>>> Есть.
>>>
>>> Одно время люди из мира SSL/TLS пытались продвигать сжатие на
>>> уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не
>>> пытались, и б) делает динамический контент уязвимым к атакам, см.
>>> https://en.wikipedia.org/wiki/CRIME.  Так что nginx всегда
>>> запрещает сжатие на уровне SSL.
>>>
>>> --
>>> Maxim Dounin
>>> http://mdounin.ru/
>>> ___
>>> 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
>
>
> ___
> 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

Re: Gzip + https: есть-ли смысл?

[Andrey Velikoredchanin]

Максим, спасибо за ответ!

Однако, он не совсем прояснил ситуацию. Попробую переформулировать...

1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не
рекомендуется, т.к. есть проблемы с безопасностью.
2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к.
это НЕ внутреннее сжатие SSL.

Я правильно понял?

23 июля 2018 г., 1:59 пользователь Maxim Dounin 
написал:

> Hello!
>
> On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote:
>
> > Извиняюсь если вопрос древний (а у меня есть такое подозрение), но
> > почему-то не смог найти информацию о том, имеет-ли смысл включать gzip
> для
> > статики если сайт работает через https? Я помню что что-то об этом
> слышал,
> > но, как уже отметил - не смог найти подтверждения этому.
>
> Есть.
>
> Одно время люди из мира SSL/TLS пытались продвигать сжатие на
> уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не
> пытались, и б) делает динамический контент уязвимым к атакам, см.
> https://en.wikipedia.org/wiki/CRIME.  Так что nginx всегда
> запрещает сжатие на уровне SSL.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> 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

Gzip + https: есть-ли смысл?

[Andrey Velikoredchanin]

Всем привет!

Извиняюсь если вопрос древний (а у меня есть такое подозрение), но
почему-то не смог найти информацию о том, имеет-ли смысл включать gzip для
статики если сайт работает через https? Я помню что что-то об этом слышал,
но, как уже отметил - не смог найти подтверждения этому.

Спасибо.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проксирование ssl сертификата и ключа

[Andrey Velikoredchanin]

Делал как-то такое. Это вам надо tcp-proxy на nginx настроить. Подробности
вот тут -
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

16 апреля 2018 г., 14:25 пользователь tresor.fk  написал:

> Помогите разобраться со следующей ситуацией:
>
> Есть веб сервер подрядчика, доступ к которому осуществляется по выделенному
> каналу и при указании сертификата и приватного ключа
>
> То есть у нас есть линуксовый сервер, с которого мы инициализируем
> подключение. Для этого на нем настроен дополнительный сетевой интерфейс.
>
> Например если запустить:
>
> wget --bind-address=
> --certificate=/etc/nginx/ssl/private_online.crt
> --private-key=/etc/nginx/ssl/private_online.key  https://
>
> То подключение успешное - "HTTP request sent, awaiting response... 200 OK"
>
> Но нам нужно на этом сервере настроить nginx, чтобы мы со своих компьютеров
> открывали в браузере IP нашего сервера и попадали на сервер подрядчика
>
> Как настроить NGINX, чтобы он делал bind_adress и передавал для авторизации
> сертификат и ключ по аналогии с wget?
>
> Пробовал использовать следующее, но не помогает
>
> proxy_bind XX.XX.XX.XX;
> proxy_pass https://;
> proxy_ssl_certificate /etc/nginx/ssl/private_online.pem;
> proxy_ssl_certificate_key /etc/nginx/ssl/private_online_key.pem;
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,279454,279454#msg-279454
>
> ___
> 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

Re: unit-0.2 beta release

[Andrey Velikoredchanin]

Вопрос разработчикам nginx unit - его лицензия будет оставаться открытой в
будущем? Будет-ли версия Enterprise и чем она будет отличаться от открытой?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

[Andrey Velikoredchanin]

Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но
на нем еще много чего написано и пишется.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

[Andrey Velikoredchanin]

20 октября 2017 г., 16:00 пользователь Илья Шипицин <chipits...@gmail.com>
написал:

>
>
> 20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
> unclean...@gmail.com> написал:
>
>> Очень интересная штука! Обязательно будем пробовать.
>>
>
> можно поподробнее, чем именно интересна ?
>

Для меня unit интересен возможностью прозрачного апгрейда сайта без обрыва
имеющихся коннектов.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

[Andrey Velikoredchanin]

Очень интересная штука! Обязательно будем пробовать.

20 октября 2017 г., 11:27 пользователь Anton Kiryushkin 
написал:

> Простите за мою не понятливость. Но где в unit задается путь до php.ini?
> Используется сугубо тот, что был при сборке, или же можно как-то указать
> тот, с которым нужно запуститься?
>
> 2017-10-20 10:42 GMT+03:00 Igor Sysoev :
>
>> http://unit.nginx.org
>>
>> Changes with Unit 0.219 Oct
>> 2017
>>
>>*) Feature: Go package improvements.
>>
>>*) Feature: configuration persistence.
>>
>>*) Feature: improved handling of configuration errors.
>>
>>*) Feature: application "timeout" property.
>>
>>*) Bugfix: Go application crashed under load.
>>
>>*) Bugfix: POST request for PHP were handled incorrectly.
>>
>>*) Bugfix: the router exited abnormally if all listeners had been
>>   deleted.
>>
>>*) Bugfix: the router crashed under load.
>>
>>*) Bugfix: memory leak in the router.
>>
>>
>> --
>> Igor Sysoev
>> http://nginx.com
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>
>
> ___
> 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

Re: Очень медленный ответ после нескольких быстрых ответов

[Andrey Velikoredchanin]

А пробовали сделать лог своего приложения что-бы определить на каком
моменте останавливается второй запрос? Тогда перед этим местом вы могли-бы,
например, ставить какой-то общедоступный флаг, за которым следил-бы первый
запрос и отрубался при его обнаружении. Т.е. решение тут вообще nginx не
касается - это чисто прикладная задача.

27 сентября 2017 г., 11:18 пользователь EugeneNF <
nginx-fo...@forum.nginx.org> написал:

> Спасибо за ответ. Может быть 20 вокеров было мало. Попробую увеличить до
> 50.
> Но хотелось бы найти вариант застраховаться от "зависания". Поскольку нет
> гарантии, что и 50 будет достаточно при посылки запросов со многих IP. Я
> хочу для начала просто делать "reset" для зависшего IP и "начинать жизнь
> сначала".
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276566#msg-276566
>
> ___
> 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

Re: Очень медленный ответ после нескольких быстрых ответов

[Andrey Velikoredchanin]

С самого начала у меня есть подозрение что приложение запущено в одном
воркере. В таком варианте, если оно не потоковое, запрос и будет
блокироваться до окончания выполнения первого запроса. Может в этом дело?

27 сентября 2017 г., 10:59 пользователь EugeneNF <
nginx-fo...@forum.nginx.org> написал:

> Попробую сформулировать по-другому то, что наблюдаю и пробую изменить.
> - nginx получает запрос по какому-то IP. Запрос выполняется очень долго.
> - посылается второй запрос с того же самого IP, когда предыдыущий запрос
> ещё
> не обработан и ответ не послан. Этот запрос не доходит до приложения, и нет
> возможности принять решение внутри приложения, что же делать в таком
> случае.
> Вопрос: можно ли настроить nginx таким образом, чтобы при посылки запроса с
> того же самого IP, предыдущий запрос просто обрывался и забывался. Я
> понимаю
> тяжёлые последствия такого сценария, но вопрос сейчас - можно или нельзя с
> помощью опции nginx это сделать?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276563#msg-276563
>
> ___
> 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

Re: Nginx Inc is hiring. Yes, again.

[Andrey Velikoredchanin]

Эх, моя мечта у вас работать. :) Вот только уровень C не дотягивает. :(

7 февраля 2017 г., 15:27 пользователь Maxim Konovalov 
написал:

> Добрый день.
>
> Мы опять ищем разработчиков к нам в коллектив.
>
> Основные факты о нас: компания основана в 2011 году, занимается
> развитием nginx f/oss [1] и созданием коммерческих продуктов на базе
> nginx [2].  Технический офис в Москве, штаб-квартира в
> Сан-Франциско, США.
>
> Чем заниматься: разработкой прокси-сервера, интеграцией языков
> программирования в сервер приложений. Проект ведет непосредственно
> Игорь Сысоев.
>
> Что надо знать и уметь:
>
> - опыт профессионального программирования под UNIX на C от 3 лет;
> - продвинутый/экспертный уровень;
> - понимание архитектур современных операционных систем;
> - владение инструментами разработки под UNIX;
> - уверенные навыки пользователя UNIX;
> - технический английский язык.
>
> Желательно:
>
> - опыт написания клиент-серверных приложений;
> - навыки программированния асинхронных и многопоточных приложений;
> - понимание устройства и принципов работы интерпретируемых языков
> программирования;
> - знание и опыт программирования на Java, Go, PHP, Python,
> JavaScript, Ruby;
> - знание протокола HTTP.
>
> В обмен на ваше участие предлагаем следующее:
>
> - работа в проекте с международным признанием (~50% из top-100K
> мировых сайтов используют nginx [3]), в компактном коллективе
> профессионалов, увлеченных своим делом;
> - профессиональный рост;
> - конкурентная зарплата, ДМС после исп. срока, гибкий график работы,
> участие в опционной программе.
>
> В связи со спецификой проекта, на который ищем людей, варианты с
> удаленной работой не рассматриваем, т.е. речь о полной занятости в
> Москве.
>
> Жду ваши CV на ma...@nginx.com.
>
> [1] http://nginx.org
> [2] http://nginx.com
> [3] http://w3techs.com/technologies/cross/web_server/ranking
>
> --
> Maxim Konovalov
> ___
> 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

Re: NGiNX в качестве сервера за закачивания файлов

[Andrey Velikoredchanin]

Поддерживаю вариант DAV.

21 апреля 2016 г., 21:52 пользователь Andrey Kopeyko 
написал:

> On Thu, 21 Apr 2016, Dimka wrote:
>
> Всем привет!
>>
>
> Добрый вечер!
>
> Хочу использовать NGiNX для закачивания файлов на сервер.
>> При этом не хочется использовать сторонние модули или скрипт на бекенд
>> сервере.
>>
>
> Используйте модуль DAV -
> http://nginx.org/en/docs/http/ngx_http_dav_module.html
>
> проблема что нельзя оставить оригинальное имя файла
>>
>
> Примерно вот так должно сработать:
>
> $ curl -T source.file http://host/path/to/destination.file
>
>
> --
> Best regards,
> Andrey Kopeyko 
> ___
> 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

Re: модуль на заказ

[Andrey Velikoredchanin]

Присоединяюсь к советующему X-Accel-Redirect. Тоже рекомендую. И надежнее и
функциональнее.

25 февраля 2016 г., 11:52 пользователь Alexander Uskov 
написал:

> Как минимум random и floor.
>
> А вообще реализация нужной мне ф-ции на js -
> https://gist.github.com/larchanka/7080820/
>
> ~~~
> wbr, Alexander Uskov
>
> - Исходное сообщение -
> > От: "Igor Sysoev" 
> > Кому: nginx-ru@nginx.org
> > Отправленные: Четверг, 25 Февраль 2016 г 13:35:39
> > Тема: Re: модуль на заказ
> >
> > On 25 Feb 2016, at 07:48, Alexander Uskov  wrote:
> >
> > > Попробую Lua, так как яваскрипт пока нефункционален (нет класса
> > > Math),
> >
> > А что нужно в Math?
> >
> >
> > --
> > Igor Sysoev
> > http://nginx.com
> >
> > ___
> > 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: один сервер с несколькими сайтами с/без ssl

[Andrey Velikoredchanin]

А в конфиге nginx прописать только 80 порт для сайтов без ssl не пробовали?


7 марта 2014 г., 12:31 пользователь vaal nginx-fo...@nginx.us написал:

 Проблема в том что пользователи могут заходить по https на сайты для
 которых
 не установлены ssl. При этом они будут получать в браузере сообщения про
 проблему с ssl и т.п.., которые могут их напугать.

 В итоге хотелось бы чтобы на сайты без ssl нельзя попытаться было войти по
 https. Выше мне уже ответили что нужен второй ip.

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

 ___
 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

Re: Распределённое хранение файлов [OFFTOPIC]

[Andrey Velikoredchanin]

Когда у меня была такая задача, я исходил из принципа что самое надежное
решение - самое простое. Я использовал много серверов с NFS, запись в базе
того, на каком сервере лежит файл и X-Accel-Redirect при его выдаче.


17 февраля 2014 г., 1:41 пользователь Alex Yakovenko 
aleksey.yakove...@gmail.com написал:

 https://github.com/mogilefs/

 16 февраля 2014 г., 21:33 пользователь Михаил Монашёв
 postmas...@softsearch.ru написал:
  Здравствуйте.
 
  Расскажите,  пожалуйста,  как Вы храните много разных файлов, если они
  на  один  сервер  не  влазят?  Есть  ли  специальные  инструменты  для
  распространения  файлов  по  серверам,  поддержания нужного количества
  реплик, обхода всех файлов или файлов с каким-то признаком и т.п.
 
  --
  С уважением,
   Михаил  mailto:postmas...@softsearch.ru
 
  ___
  nginx-ru mailing list
  nginx-ru@nginx.org
  http://mailman.nginx.org/mailman/listinfo/nginx-ru



 --
 WBR
 Alex Yakovenko
 ___
 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

Re: [no subject]

[Andrey Velikoredchanin]

Думаю, вам нужно использовать
proxy_intercept_errors on;


15 августа 2013 г., 21:04 пользователь xServer xdebi...@gmail.com написал:

 добрый день!
 Имею следующую проблему:

 Не срабатывает директива error_page при связке Nginx + php-fpm.
 Использую директиву limit_conn для лимитирования одновременных соединений
 с одного IP, при превышении лимита выдаётся ошибка 503, я создал свою
 страницу для этой ошибки (50x.shtml) но я не вижу эту свою страницу, вместо
 неё выдаётся дефолтная встроенная страница для ошибки 503.
 При связке Nginx + Apache моя страница для ошибки 503 отображалась
 нормально, дефолтная встроенная страница не беспокоила.

 Настройки те же:
 error_page 500 502 503 504 /50x.shtml;
 location = /50x.shtml {
 allow all;
 }

 ___
 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

Re: предлагаю немного поменять логику proxy_next_upstream

[Andrey Velikoredchanin]

А что происходит если идет сбой по чтению в вашем случае? Ожидание до
бесконечности?


12 августа 2013 г., 14:59 пользователь Илья Шипицин
chipits...@gmail.comнаписал:

 Добрый день!

 мы столкнулись с ситуацией такого характера.
 есть веб-приложения, которые долго отвечают, в отношении них
 справедливо, что лучше запрос отправить не более одного раза
 (например, это может быть разнесения платежа, на 20 фронтов платеж
 разнесется 20 раз).

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

 в случае, если мы не можем отправить данные - нормально уйти на
 следующий хост. если мы уходим в таймаут при чтении - на следующий
 хост лучше не уходить, может быть массовый расстрел (разнесение
 платежа 20 раз из 20).


 патч вложил.


 Илья Шипицин

 ___
 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

Re: Ищу решения для нестандартного upload progress-а

[Andrey Velikoredchanin]

Что-то я не совсем понял. А чем не подходит стандартный nginx
модуль nginx_upload_module? Насколько я понимаю, он может предоставлять
информацию о прогрессе закачки любому клиенту, который знает идентификатор
файла. Я его использовал в своих проектах для обычного варианта показа
загрузки клиенту, но с тем-же успехом его можно использовать и для показа
прогресса третьей стороне. Главное что-бы третья сторона знала
идентификаторы закачиваемых файлов.


2 мая 2013 г., 9:21 пользователь pioneer32 nginx-fo...@nginx.us написал:

 Приветствую всех!

 Стоит следующая задача:
 Есть web-сервер front - nginx, back - fcgi-php. На него идут upload-ы
 файлов
 (несколько десятков клиентов единовременно), необходимо с периодичностью
 10-15 секунд, предоставлять информацию стороннему сервису о состояние
 загрузок (% выполненности или в байтах всего/аплоадед - не принципиально).
 Как предоставлять - не принципально, т.к. я вообще не могу нагуглить, какой
 модуль можно для этого использовать (ну или не понял как применить для
 данной задачи имеющиеся).

 Бузу очень признателен любой подсказке или направлению гугления.

 P.S. Всех с первомайскими праздниками!

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

 ___
 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

Re: nginx доступ к странице по времени

[Andrey Velikoredchanin]

Не обязательно встроенный. Можно скриптом проверять время и делать
внутреннее перенаправление на страницу если доступ разрешен. IMHO, самый
простой и гибкий вариант.


5 апреля 2013 г., 11:40 пользователь Vadim Lazovskiy 
vadim.lazovs...@gmail.com написал:

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

 Начиная с версий 1.3.12 и 1.2.7 доступна переменная $time_iso8601 (раньше
 была только в log_module). Ее можно смапить в флажок доступа:

 map $time_iso8601 $hour {
 ~\d{4}-\d{2}-\d{2}T(?h\d{2}): $h;
 }

 map $hour $forbidden {
09 0;
10 0;
11 0;
12 0;
 default 1;

 }

 ...
 server {
...
location /webinar/ {
  error_page 403 /webinar_forbidden.html;
  if ($forbidden) {
return 403;
  }
}

 Можно обойтись и без промежуточной переменной $hour, забив в регулярное
 выражение нужные часы.
 В более старых версиях, imho, только встроенный perl.


 5 апреля 2013 г., 9:15 пользователь heroin nginx-fo...@nginx.us написал:

 Всем добрый день.

 Подскажите как ограничить время доступа к странице в nginx ?
 Есть установленный BigBlueButton, нужно чтобы доступ к созданному вебинару
 был только в определенное время, а в другое время выдавалась нужная
 заглушка.
 В apache я так понимаю это делается модулем mod_rewrite и записью в
 .htaccess в директории с нужной страницей что то вроде

 Код:
 RewriteEngine on

 RewriteCond %{TIME_HOUR}%{TIME_MIN}  900
 RewriteCond %{TIME_HOUR}%{TIME_MIN}  1800
 RewriteRule .* - [ F ]


 Как сделать в nginx ?

 Заранее спасибо.

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

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




 --
 Best Regards,
 Vadim Lazovskiy

 ___
 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

Re: nginx доступ к странице по времени

[Andrey Velikoredchanin]

5 апреля 2013 г., 14:15 пользователь heroin nginx-fo...@nginx.us написал:

 Не обязательно встроенный. Можно скриптом проверять время и делать
 внутреннее перенаправление на страницу если доступ разрешен. IMHO, самый
 простой и гибкий вариант.

 Можно уточнить как это сделать ?
 Заранее спасибо.


Типа вот такого:

location /files {
proxy_pass http://127.0.0.1:8080/
}

location /int_files {
   internal;

   root_path /var/www/files;
}

На порту 3000 повесить скрипт, который будет получать запрос,
анализировать, имеет-ли право данный юзер на данный запрос в данное время и
если имеет - выдавать в ответ заголовок с X-Accel-Redirect на путь
/int_files/... на нужный файл. Если прав нет, можно выдавать, например,
статус 404 или перенаправить внешним редиректом на страницу с объяснением
что типа Время вышло.

Для пользователя все это будет прозрачно и незаметно, т.к. перенаправление
внутреннее.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru