Comments 17
> if ($request_uri ~ ^(.*)/index.(html|php)) { return 301 $1/$is_args$args; }
Почему бы этот if не убрать, попробовав завести соответствующий location?
Почему бы этот if не убрать, попробовав завести соответствующий location?
Ну хотя бы потому что такой if нельзя заменить локейшеном. Цитирую документацию nginx
Если провернуть тоже самое с локейшеном, то после редиректа запрос снова будет попадать в этот же локейшен и зациклится. Что вызовет ошибку 500.
Попробую наглядно…
запрашиваем /index.php
В обоих случаях и с if и location произойдёт редирект на /
Теперь запрос в / и $request_uri тут равно /, а значит редиректа не будет, в случае с локейшеном у нас отрабатывает директива index и происходит внутреннее перенаправление на index.php и снова идёт запрос на обработку в location, а там редирект)… и так до бесконечности)
Если вдруг Вы нашли способ избавиться от такого if и при этом не сломать работу сайта, поделитесь) Буду признателен. Уверен что не только я.
$request_uri — первоначальный URI запроса целиком (с аргументами)
Если провернуть тоже самое с локейшеном, то после редиректа запрос снова будет попадать в этот же локейшен и зациклится. Что вызовет ошибку 500.
Попробую наглядно…
запрашиваем /index.php
В обоих случаях и с if и location произойдёт редирект на /
Теперь запрос в / и $request_uri тут равно /, а значит редиректа не будет, в случае с локейшеном у нас отрабатывает директива index и происходит внутреннее перенаправление на index.php и снова идёт запрос на обработку в location, а там редирект)… и так до бесконечности)
Если вдруг Вы нашли способ избавиться от такого if и при этом не сломать работу сайта, поделитесь) Буду признателен. Уверен что не только я.
Решил всё таки заморочиться и сделать без if. Вот что у меня получилось
Пока применил у себя на дев-сайте. Страшно сразу выбрасывать на прод, помучаю сначала.
Позже добавлю в статью если нормально всё работать будет.
P.S. Немного поправил от первоначального состояния. Пересмотрите те кто смотрел первоначальный вариант комментария. Оттестирую этот вариант у себя и если всё хорошо. допишу его в статью.
map $request_uri $index {
default "";
"~(.*)/index.(html|php)" "$1/$is_args$args";
}
map $index $return {
default "1";
"" "";
}
location @index { return 301 $index; }
location / { try_files $return$uri $return$uri/ $return/bitrix/urlrewrite.php$is_args$args @index; }
Пока применил у себя на дев-сайте. Страшно сразу выбрасывать на прод, помучаю сначала.
Позже добавлю в статью если нормально всё работать будет.
P.S. Немного поправил от первоначального состояния. Пересмотрите те кто смотрел первоначальный вариант комментария. Оттестирую этот вариант у себя и если всё хорошо. допишу его в статью.
Не нужно тащить
fastcgi_index index.php и fastcgi_intercept_errors on в location'ы, достаточно указать на уровне server.internal в большинстве location'ов лучше заменить на deny all.
Все бы хорошо, но как насчёт применения правил для автокомпозита заданных в админке битры?
Тех самых которые приводят к изменению .config.php из которого в bitrixvm генерятся правила для nginx..
Всё работает. Более того, куда лучше чем в битриксвм, то что они там напороли просто ужас у меня вызывает. Не надо думать что у них крутой конфиг потому он такой сложный. Всё куда проще)) Писал его явно тот кто не умеет в Nginx.
Вопрос не в том что круче, а в том как реализован проброс правил из .config.php в nginx…
В bitrixvm это делает perl скрипт вызываемый из ansible.
Правила все прописаны сразу, о каких правилах идёт речь?
Не первый день работаю с битрикс, и впервые слышу о файле, можно ссылочку на документацию о нём?
Не первый день работаю с битрикс, и впервые слышу о файле, можно ссылочку на документацию о нём?
Спросили бы чего попроще, отдельно файлы никто не документирует. Поищу что-нибудь специально для вас
Да Вы шутите, в этой статье я как раз и написал как избавиться от этого колхозанства. Эти правила как раз и прописываются в мапах.
проблема в том что содержимое .config.php меняется в зависимости от настроек автокомпозита, которые пользователь делает просто в админке.
Хотелось бы чтобы оные прозрачно для юзера попадали в nginx, а в вашем случае все прибито гвоздями. Как в прочем и в bitrixvm (разрабы просят в menu.sh прожимать скриптик при изменении настроек автокомпозита).
Вполне возможно я не достаточно хорошо понял как оно работает и ваша реализация действительно полноценно работает.
Хотелось бы чтобы оные прозрачно для юзера попадали в nginx, а в вашем случае все прибито гвоздями. Как в прочем и в bitrixvm (разрабы просят в menu.sh прожимать скриптик при изменении настроек автокомпозита).
Вполне возможно я не достаточно хорошо понял как оно работает и ваша реализация действительно полноценно работает.
Не подскажете, как при замене Apache на php-fpm настроить «Ускорение открытия страниц»?
При проверке пишет, что нужно либо подключить модуль компрессии, либо настроить его в веб-сервере.
gzip включил, но, похоже битрикс подразумевает что-то своё.
При проверке пишет, что нужно либо подключить модуль компрессии, либо настроить его в веб-сервере.
gzip включил, но, похоже битрикс подразумевает что-то своё.
UFO just landed and posted this here
нашёл, в чём была ошибка.
запишу, чтобы вопрос без ответа не висел.
У меня выстроена цепочка nginx (front with ssl) → nginx (on app server) → php-fpm → bitrix code
я настроил сжатие на nginx (on app server) и не настроил на nginx (front with ssl).
Т.е. надо было всего лишь включить gzip на граничном nginx.
запишу, чтобы вопрос без ответа не висел.
У меня выстроена цепочка nginx (front with ssl) → nginx (on app server) → php-fpm → bitrix code
я настроил сжатие на nginx (on app server) и не настроил на nginx (front with ssl).
Т.е. надо было всего лишь включить gzip на граничном nginx.
Sign up to leave a comment.
Битрикс в связке Nginx+PHP-FPM, настройка ЧПУ, а так же композитный кэш с отдачей через nginx. Доработанная конфигурация