Re: Высокое количество соединений между фронт-ендами и биддерами
У нас похожее наблюдалось, когда мы офисный свич поставили между фронтом и бэкэндом. Он банально не держал нагрузку. Если меняли аппаратуру, скорей всего, дело в этом. пт, 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
Примите наши поздравления! :) пн, 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: есть-ли смысл?
Ясно. Спасибо всем за пояснения! 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: есть-ли смысл?
У меня основная цель - текстовую статику жать: 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: есть-ли смысл?
Максим, спасибо за ответ! Однако, он не совсем прояснил ситуацию. Попробую переформулировать... 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: есть-ли смысл?
Всем привет! Извиняюсь если вопрос древний (а у меня есть такое подозрение), но почему-то не смог найти информацию о том, имеет-ли смысл включать gzip для статики если сайт работает через https? Я помню что что-то об этом слышал, но, как уже отметил - не смог найти подтверждения этому. Спасибо. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование ssl сертификата и ключа
Делал как-то такое. Это вам надо 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
Вопрос разработчикам 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
Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но на нем еще много чего написано и пишется. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
20 октября 2017 г., 16:00 пользователь Илья Шипицин написал: > > > 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
Очень интересная штука! Обязательно будем пробовать. 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: Очень медленный ответ после нескольких быстрых ответов
А пробовали сделать лог своего приложения что-бы определить на каком моменте останавливается второй запрос? Тогда перед этим местом вы могли-бы, например, ставить какой-то общедоступный флаг, за которым следил-бы первый запрос и отрубался при его обнаружении. Т.е. решение тут вообще 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: Очень медленный ответ после нескольких быстрых ответов
С самого начала у меня есть подозрение что приложение запущено в одном воркере. В таком варианте, если оно не потоковое, запрос и будет блокироваться до окончания выполнения первого запроса. Может в этом дело? 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.
Эх, моя мечта у вас работать. :) Вот только уровень 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 в качестве сервера за закачивания файлов
Поддерживаю вариант 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: модуль на заказ
Присоединяюсь к советующему 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
При чем тут DNS? Если поставить 80 порт для сайтов без SSL, то они перестанут отвечать по https порту (443). Я так понимаю, именно это и нужно автору? 7 марта 2014 г., 12:59 пользователь Daniel Podolsky написал: > > А в конфиге nginx прописать только 80 порт для сайтов без ssl не > пробовали? > DNS записи от этого не поправятся > ___ > 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
А в конфиге nginx прописать только 80 порт для сайтов без ssl не пробовали? 7 марта 2014 г., 12:31 пользователь vaal написал: > Проблема в том что пользователи могут заходить по 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]
Когда у меня была такая задача, я исходил из принципа что самое надежное решение - самое простое. Я использовал много серверов с NFS, запись в базе того, на каком сервере лежит файл и X-Accel-Redirect при его выдаче. 17 февраля 2014 г., 1:41 пользователь Alex Yakovenko < aleksey.yakove...@gmail.com> написал: > https://github.com/mogilefs/ > > 16 февраля 2014 г., 21:33 пользователь Михаил Монашёв > написал: > > Здравствуйте. > > > > Расскажите, пожалуйста, как Вы храните много разных файлов, если они > > на один сервер не влазят? Есть ли специальные инструменты для > > распространения файлов по серверам, поддержания нужного количества > > реплик, обхода всех файлов или файлов с каким-то признаком и т.п. > > > > -- > > С уважением, > > Михаил 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: предлагаю немного поменять логику proxy_next_upstream
А что происходит если идет сбой по чтению в вашем случае? Ожидание до бесконечности? 12 августа 2013 г., 14:59 пользователь Илья Шипицин написал: > Добрый день! > > мы столкнулись с ситуацией такого характера. > есть веб-приложения, которые долго отвечают, в отношении них > справедливо, что лучше запрос отправить не более одного раза > (например, это может быть разнесения платежа, на 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: [no subject]
Думаю, вам нужно использовать
proxy_intercept_errors on;
15 августа 2013 г., 21:04 пользователь xServer написал:
> добрый день!
> Имею следующую проблему:
>
> Не срабатывает директива 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: Ищу решения для нестандартного upload progress-а
Что-то я не совсем понял. А чем не подходит стандартный nginx модуль nginx_upload_module? Насколько я понимаю, он может предоставлять информацию о прогрессе закачки любому клиенту, который знает идентификатор файла. Я его использовал в своих проектах для обычного варианта показа загрузки клиенту, но с тем-же успехом его можно использовать и для показа прогресса третьей стороне. Главное что-бы третья сторона знала идентификаторы закачиваемых файлов. 2 мая 2013 г., 9:21 пользователь pioneer32 написал: > Приветствую всех! > > Стоит следующая задача: > Есть 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: прозрачное проксирование с AWS S3
А в чем проблема? Задача довольно тривиальная. 9 апреля 2013 г., 16:37 пользователь Anatoly Mikhailov написал: > > On Apr 4, 2013, at 1:01 PM, Daniel Podolsky wrote: > > >> пока нашел вариант с X-Accel-Redirect ( > http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) > > X-Accel-Redirect вам нужен, если вы хотите отдать локальный файл, но > > проверить право доступа к нему на бекенде. С S3 это не так, насколько > > мне известно. > > я не зря предоставил ссылку на блог пост, прочтите его еще раз. > S3 - обычная файловая помойка со своим API для доступа к public/private > файлам > > > > >> вопрос - использует ли кто данный подход и как правильно организовать > прозрачное проксирование? > > nginx - это продукт для реверсного, а не для прозрачного > > проксирования. Вы уверены, что правильно ставите задачу? > > с точки зрения клиента эти термины равнозначные, для меня важно > организовать > отдачу файлов с нашего субдомена, CNAME для S3 корзины подходит до тех пор, > пока у вас нет HTTPS > > Анатолий > > > ___ > > 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: nginx доступ к странице по времени
5 апреля 2013 г., 14:15 пользователь heroin написал:
> >Не обязательно встроенный. Можно скриптом проверять время и делать
> >внутреннее перенаправление на страницу если доступ разрешен. 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
Re: nginx доступ к странице по времени
Не обязательно встроенный. Можно скриптом проверять время и делать
внутреннее перенаправление на страницу если доступ разрешен. 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(?\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 ?
>> Есть установленный 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
