Представлен (http://mailman.nginx.org/pipermail/nginx-announce/2014/00013...) новый выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.7.1 (http://nginx.org/), в котором продолжено развитие новых возможностей. Основным улучшением (http://nginx.org/en/CHANGES) нового выпуска является возможность (http://nginx.org/en/docs/http/ngx_http_log_module.html#acces...) перенаправления в syslog логов, настраиваемых через директивы "error_log" и "access_log". Кроме того, добавлена поддержка переменных "$upstream_cookie_{имя} (http://nginx.org/en/docs/http/ngx_http_upstream_module.html#...)" и "$ssl_client_fingerprint".Примечательно, что по данным (http://w3techs.com/technologies/cross/web_server/ranking) W3Techs nginx сравнялся по популярности с http-сервером Apache в выборке из 10 тысяч самых крупных сайтов сети (доля каждого сервера составила 39.2%). В выборке из тысячи самых крупных сайтов доля nginx составляет 38.8%, в то время как apache - 33.7%. При рассмотрении миллиона самых крупных сайтов, доля nginx составляет 23.5%, а apache - 56.5%.
URL: http://mailman.nginx.org/pipermail/nginx-announce/2014/00013...
Новость: https://www.opennet.ru/opennews/art.shtml?num=39876
htaccess когда обрабатывать научица?
Никогда, надеюсь.
плюсую
Если научится, то это уже не будет событийно-ориентированный веб-сервер.
Если сделать грамотно - т. е. отслеживать изменения в .htaccess с помощью inotify и перечитывать его только в момент изменения, а не на каждый запрос, то сервер вполне останется событийно-ориентированным. Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx.
> Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginxВот-вот! Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.
> Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.При желании можно представить себе случаи, когда это полезно. Например, если требуется настраивать пользовательские редиректы, то будет эффективнее, если 301-й ответ вернет сразу фронтенд, не трогая сервер приложений.
Не надо "желать", что-то там себе "представлять". Представить можно всё что угодно. На любую супероптимизированную программу можно придумать такой use-case, когда все супероптимизации пойдут лесом. Ориентироваться надо на реальные use-cases. Не нужно теоретизировать. Направления оптимизаций управляются практикой. Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов. Напишите статейку, описывающую конфигурацию и скиньте её Сысоеву. Пускай он заценит адекватность конфигов, и сам решит: нужно или не нужно.
> Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов.В такой формулировку любая сокращалка урлов удовлетворяет критерию.
>> Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов.
> В такой формулировку любая сокращалка урлов удовлетворяет критерию.В этой ситуации, быть может, лучше кешировать 301 от бэкенда? Кеширование -- это механизм наличествующий в nginx, и если он может решить проблему, то зачем запиливать ещё один механизм для решения проблемы?
>> Дайте ссылку на сервер, который тратит процентов 10% процессорного времени
>> на обработку 301 ответов.
> В такой формулировку любая сокращалка урлов удовлетворяет критерию.И много там людей с .htaccess, если вспомнить контекст вопроса?
>> Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx
> Вот-вот! Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.Так он уже не только как фронтэнд используется, много включая меня - как обычный www-сервер с перенаправлением запросов на php-fpm
> Если научится, то это уже не будет событийно-ориентированный веб-сервер.На самом деле на лету подхватываемый htaccess особо и не нужен, можно обойтись наличие подобия namespace с отдельной секцией конфига для выполнения непривилегированных директив конфигурации.
У нас что-то подобное сделало через несколько скриптов. Первый скрипт сканирует директории на сайтах и выдирает файлы .ngacess. Второй делает фильтрацию допустимых настроек (разрешён редирект и обработка кодов ошибок) и проверку синтаксиса. Третий строит из собраный кусочков и главного шаблона конфиг nginx, проверят есть ли изменения с момента прошлого построения и если есть пытается применить новую конфигурацию. Если возникла ошибка - делается откат на прошлую версию и звон во все колокола администраторам, чтобы смотрели, что недосмотрел скрипт проверки.
Зачем мешать теплое с мягким, есть http и его задача отдавать контент, а кому какой и надо или нет, задача генератора контента. Да, в http есть функционал для минимальных ограничений, но он существует на правах заглушки, для систем (генераторов контента) в которых подобные ограничения не предусмотренны, а они очень нужны, либо разрабы ленивые м...ки и съехали с темы, либо базовых ф-й ограничения хватает (в роутере там или еще в какой опе).Перекладывать функционал с условно не надежного уровня (генератора контента) на условно надежный (простой отдавалки http), значит понижать надежность последней не повышая ее у первой, то есть снижать надежность в целом за счет дублирования функционала.
-----
Кстате раз уж вы все равно извращаетесь, могу предложить запускать на серваке два nginx'а - основной и тестовый, на разных портах, а скрипт будит редиректить 80 на новый тестовый, если запуск nginx успешный, или если пройдет проверку скриптом)).
>обрабатывать научица?Ты всё перепутал. Это же веб-сервер, а не система ИИ.
"Ученые создали устройство для управления самолетом силой мысли"
http://ria.ru/technology/20140528/1009672212.html#1401274436...
> htaccess когда обрабатывать научица?Когда все забудут про .htaccess?
Если вам нужен хтакцесс - используйте апач. Его не закрыли еще.
А я вот жду, когда они вынесут в конфиг захаркоженный на 16К max ssl record size...
Делаете правки @ Отправляете патч. Опенсорс же.
> Делаете правки @ Отправляете патч. Опенсорс же.Лень же. Я просто константу уменьшаю до 2к. И кто-то вроде за это уже взялся.
Вы про это:http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_b...
?
> Вы про это:
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_b...
> ?Почти. Эту (а может и другую) опцию надо протащить внутрь ngx_event_openssl.c
Они уже пофиксили
> Они уже пофиксилиНет. Всё по прежнему захардкожено.
nginx-1.7.1/src/event/ngx_event_openssl.h
#define NGX_SSL_BUFSIZE 16384
nginx-1.7.1/src/event/ngx_event_openssl.c
ssl->buffer_size = NGX_SSL_BUFSIZE;
BIO_set_write_buffer_size(wbio, NGX_SSL_BUFSIZE);
>> Вы про это:
>> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_b...
>> ?
> Почти. Эту (а может и другую) опцию надо протащить внутрь ngx_event_openssl.chttps://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/
> возможность перенаправления в syslog логов, настраиваемых через директивы "error_log" и "access_log"Долго держались.
Климат долины творит чудеса!
http://httpd.apache.org/
Вы бы еще IIS предложили.
С функциональностью IIS
http://tinyhttpd.sourceforge.net/
> http://httpd.apache.org/Нам чужого не надо!
http://demotivators.to/media/posters/2139/744640_mne-chuzhog...
если честно, очень не хватало