URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 96055
[ Назад ]

Исходное сообщение
"Новый выпуск http-сервера nginx 1.7.1"

Отправлено opennews , 28-Май-14 13:34 
Представлен (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...
Новость: http://www.opennet.me/opennews/art.shtml?num=39876


Содержание

Сообщения в этом обсуждении
"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 13:34 
htaccess когда обрабатывать научица?

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено zunkree , 28-Май-14 13:39 
Никогда, надеюсь.

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено rshadow , 28-Май-14 13:56 
плюсую

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 13:56 
Если научится, то это уже не будет событийно-ориентированный веб-сервер.

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 14:22 
Если сделать грамотно - т. е. отслеживать изменения в .htaccess с помощью inotify и перечитывать его только в момент изменения, а не на каждый запрос, то сервер вполне останется событийно-ориентированным. Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx.

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 15:38 
> Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx

Вот-вот! Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 16:07 
> Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.

При желании можно представить себе случаи, когда это полезно. Например, если требуется настраивать пользовательские редиректы, то будет эффективнее, если 301-й ответ вернет сразу фронтенд, не трогая сервер приложений.


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Ordu , 28-Май-14 16:41 
Не надо "желать", что-то там себе "представлять". Представить можно всё что угодно. На любую супероптимизированную программу можно придумать такой use-case, когда все супероптимизации пойдут лесом. Ориентироваться надо на реальные use-cases. Не нужно теоретизировать. Направления оптимизаций управляются практикой. Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов. Напишите статейку, описывающую конфигурацию и скиньте её Сысоеву. Пускай он заценит адекватность конфигов, и сам решит: нужно или не нужно.

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 16:59 
> Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов.

В такой формулировку любая сокращалка урлов удовлетворяет критерию.


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Ordu , 28-Май-14 17:23 
>> Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов.
> В такой формулировку любая сокращалка урлов удовлетворяет критерию.

В этой ситуации, быть может, лучше кешировать 301 от бэкенда? Кеширование -- это механизм наличествующий в nginx, и если он может решить проблему, то зачем запиливать ещё один механизм для решения проблемы?


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Michael Shigorin , 28-Май-14 21:08 
>> Дайте ссылку на сервер, который тратит процентов 10% процессорного времени
>> на обработку 301 ответов.
> В такой формулировку любая сокращалка урлов удовлетворяет критерию.

И много там людей с .htaccess, если вспомнить контекст вопроса?


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Miha , 29-Май-14 11:22 
>> Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx
> Вот-вот! Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.

Так он уже не только как фронтэнд используется, много включая меня - как обычный www-сервер с перенаправлением запросов на php-fpm


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 15:45 
> Если научится, то это уже не будет событийно-ориентированный веб-сервер.

На самом деле на лету подхватываемый htaccess особо и не нужен, можно обойтись наличие подобия namespace с отдельной секцией конфига для выполнения непривилегированных директив конфигурации.

У нас что-то подобное сделало через несколько скриптов. Первый скрипт сканирует директории на сайтах и выдирает файлы .ngacess. Второй делает фильтрацию допустимых настроек (разрешён редирект и обработка кодов ошибок) и проверку синтаксиса. Третий строит из собраный кусочков и главного шаблона конфиг nginx, проверят есть ли изменения с момента прошлого построения и  если есть пытается применить новую конфигурацию. Если возникла ошибка - делается откат на прошлую версию и звон во все колокола администраторам, чтобы смотрели, что недосмотрел скрипт проверки.


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено cmp , 28-Май-14 17:02 
Зачем мешать теплое с мягким, есть http и его задача отдавать контент, а кому какой и надо или нет, задача генератора контента. Да, в http есть функционал для минимальных ограничений, но он существует на правах заглушки, для систем (генераторов контента) в которых подобные ограничения не предусмотренны, а они очень нужны, либо разрабы ленивые м...ки и съехали с темы, либо базовых ф-й ограничения хватает (в роутере там или еще в какой опе).

Перекладывать функционал с условно не надежного уровня (генератора контента) на условно надежный (простой отдавалки http), значит понижать надежность последней не повышая ее у первой, то есть снижать надежность в целом за счет дублирования функционала.
-----
Кстате раз уж вы все равно извращаетесь, могу предложить запускать на серваке два nginx'а - основной и тестовый, на разных портах, а скрипт будит редиректить 80 на новый тестовый, если запуск nginx успешный, или если пройдет проверку скриптом)).


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Andrey Mitrofanov , 28-Май-14 14:47 
>обрабатывать научица?

Ты всё перепутал. Это же веб-сервер, а не система ИИ.


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено NikolayV81 , 28-Май-14 14:54 
"Ученые создали устройство для управления самолетом силой мысли"
http://ria.ru/technology/20140528/1009672212.html#1401274436...

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено XoRe , 29-Май-14 19:39 
> htaccess когда обрабатывать научица?

Когда все забудут про .htaccess?


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Hety , 01-Июн-14 15:07 
Если вам нужен хтакцесс - используйте апач. Его не закрыли еще.

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено p5n , 28-Май-14 14:29 
А я вот жду, когда они вынесут в конфиг захаркоженный на 16К max ssl record size...

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Mr. Cake , 28-Май-14 15:34 
Делаете правки @ Отправляете патч. Опенсорс же.

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено p5n , 28-Май-14 15:39 
> Делаете правки @ Отправляете патч. Опенсорс же.

Лень же. Я просто константу уменьшаю до 2к. И кто-то вроде за это уже взялся.


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено whocarez , 28-Май-14 21:09 
Вы про это:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_b...

?


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено p5n , 28-Май-14 21:11 
> Вы про это:
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_b...
> ?

Почти. Эту (а может и другую) опцию надо протащить внутрь ngx_event_openssl.c


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 29-Май-14 20:10 
Они уже пофиксили

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено p5n , 29-Май-14 20:27 
> Они уже пофиксили

Нет. Всё по прежнему захардкожено.

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 1.7.1"
Отправлено Аноним , 29-Май-14 20:12 
>> Вы про это:
>> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_b...
>> ?
> Почти. Эту (а может и другую) опцию надо протащить внутрь ngx_event_openssl.c

https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено YetAnotherOnanym , 28-Май-14 14:38 
> возможность перенаправления в syslog логов, настраиваемых через директивы "error_log" и "access_log"

Долго держались.


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено SprintSet , 28-Май-14 15:00 
Климат долины творит чудеса!

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 15:29 
http://httpd.apache.org/

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Аноним , 28-Май-14 16:10 
Вы бы еще IIS предложили.

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Труповращатель , 28-Май-14 20:06 
С функциональностью IIS
http://tinyhttpd.sourceforge.net/

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено YetAnotherOnanym , 28-Май-14 22:08 
> http://httpd.apache.org/

Нам чужого не надо!


"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Куяврег , 29-Май-14 02:25 
http://demotivators.to/media/posters/2139/744640_mne-chuzhog...

"Новый выпуск http-сервера nginx 1.7.1"
Отправлено Sw00p aka Jerom , 28-Май-14 16:56 
если честно, очень не хватало