| |
| 2.3, Аноним (-), 13:56, 28/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если научится, то это уже не будет событийно-ориентированный веб-сервер.
| | |
| |
| 3.5, Аноним (-), 14:22, 28/05/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если сделать грамотно - т. е. отслеживать изменения в .htaccess с помощью inotify и перечитывать его только в момент изменения, а не на каждый запрос, то сервер вполне останется событийно-ориентированным. Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx.
| | |
| |
| 4.15, Аноним (-), 15:38, 28/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx
Вот-вот! Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.
| | |
| |
| 5.18, Аноним (-), 16:07, 28/05/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.
При желании можно представить себе случаи, когда это полезно. Например, если требуется настраивать пользовательские редиректы, то будет эффективнее, если 301-й ответ вернет сразу фронтенд, не трогая сервер приложений.
| | |
| |
| 6.20, Ordu (ok), 16:41, 28/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Не надо "желать", что-то там себе "представлять". Представить можно всё что угодно. На любую супероптимизированную программу можно придумать такой use-case, когда все супероптимизации пойдут лесом. Ориентироваться надо на реальные use-cases. Не нужно теоретизировать. Направления оптимизаций управляются практикой. Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов. Напишите статейку, описывающую конфигурацию и скиньте её Сысоеву. Пускай он заценит адекватность конфигов, и сам решит: нужно или не нужно.
| | |
| |
| 7.22, Аноним (-), 16:59, 28/05/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Дайте ссылку на сервер, который тратит процентов 10% процессорного времени на обработку 301 ответов.
В такой формулировку любая сокращалка урлов удовлетворяет критерию.
| | |
| |
| 8.24, Ordu (ok), 17:23, 28/05/2014 [^] [^^] [^^^] [ответить] | +/– | В этой ситуации, быть может, лучше кешировать 301 от бэкенда Кеширование -- это... текст свёрнут, показать | | |
|
|
|
| 5.32, Miha (??), 11:22, 29/05/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Другой вопрос, что это не кроссплатформенно и не нужно там, где обычно применяется nginx
> Вот-вот! Нахер ему, как фронт-энду, какие-то .htaccess перечитывать.
Так он уже не только как фронтэнд используется, много включая меня - как обычный www-сервер с перенаправлением запросов на php-fpm
| | |
|
|
| 3.17, Аноним (-), 15:45, 28/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если научится, то это уже не будет событийно-ориентированный веб-сервер.
На самом деле на лету подхватываемый htaccess особо и не нужен, можно обойтись наличие подобия namespace с отдельной секцией конфига для выполнения непривилегированных директив конфигурации.
У нас что-то подобное сделало через несколько скриптов. Первый скрипт сканирует директории на сайтах и выдирает файлы .ngacess. Второй делает фильтрацию допустимых настроек (разрешён редирект и обработка кодов ошибок) и проверку синтаксиса. Третий строит из собраный кусочков и главного шаблона конфиг nginx, проверят есть ли изменения с момента прошлого построения и если есть пытается применить новую конфигурацию. Если возникла ошибка - делается откат на прошлую версию и звон во все колокола администраторам, чтобы смотрели, что недосмотрел скрипт проверки.
| | |
| |
| 4.23, cmp (ok), 17:02, 28/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Зачем мешать теплое с мягким, есть http и его задача отдавать контент, а кому какой и надо или нет, задача генератора контента. Да, в http есть функционал для минимальных ограничений, но он существует на правах заглушки, для систем (генераторов контента) в которых подобные ограничения не предусмотренны, а они очень нужны, либо разрабы ленивые м...ки и съехали с темы, либо базовых ф-й ограничения хватает (в роутере там или еще в какой опе).
Перекладывать функционал с условно не надежного уровня (генератора контента) на условно надежный (простой отдавалки http), значит понижать надежность последней не повышая ее у первой, то есть снижать надежность в целом за счет дублирования функционала.
-----
Кстате раз уж вы все равно извращаетесь, могу предложить запускать на серваке два nginx'а - основной и тестовый, на разных портах, а скрипт будит редиректить 80 на новый тестовый, если запуск nginx успешный, или если пройдет проверку скриптом)).
| | |
|
|
| 2.33, XoRe (ok), 19:39, 29/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > htaccess когда обрабатывать научица?
Когда все забудут про .htaccess?
| | |
| 2.37, Hety (??), 15:07, 01/06/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если вам нужен хтакцесс - используйте апач. Его не закрыли еще.
| | |
|
| 1.6, p5n (ok), 14:29, 28/05/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А я вот жду, когда они вынесут в конфиг захаркоженный на 16К max ssl record size...
| | |
| |
| |
| 3.16, p5n (ok), 15:39, 28/05/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Делаете правки @ Отправляете патч. Опенсорс же.
Лень же. Я просто константу уменьшаю до 2к. И кто-то вроде за это уже взялся.
| | |
|
| |
| |
| |
| 5.36, p5n (ok), 20:27, 29/05/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Они уже пофиксили
Нет. Всё по прежнему захардкожено.
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);
| | |
|
|
|
|
| 1.7, YetAnotherOnanym (ok), 14:38, 28/05/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 > возможность перенаправления в syslog логов, настраиваемых через директивы "error_log" и "access_log"
Долго держались.
| | |
|
