Друзья, просветите, пожалуйста, как именно действует апач на примере данного рабочего кода. Хотелось бы понимать «дословно». Первое дело касается двух строчек RewriteRule. Код (PHP): <IfModule mod_rewrite.c> RewriteEngine on RewriteRule ^$ webroot/ [L] RewriteRule (.*) webroot/$1 [L] </IfModule> Тут мы имеем два взаимоисключающих правила - о чем говорит флажок [L] – last rule (?). Непонятно, есть ли вообще резон в первом правиле, если, по-видимому, сложное перенаправление происходит и без первой строчки RewriteRule (будь то сам домен site.com или чпу-шное site.com/controller/action/). Пример взят с mvc-фреймворка, и я склоняюсь к мысли, что разработчики что-то знают, чего не знаю я) Второй момент. Если в папке webroot нет очередного .htaccess с кодом, подобным приведенному ниже, получаем ошибку 500. Это какая-то особенность апача, что он не выбирает index.php автоматически, и приходится строго прописывать? Есть ли разница между написанием (.*) и ^(.*)$ в этих двух примерах? Код (PHP): <IfModule mod_rewrite.c> RewriteEngine on RewriteRule ^(.*)$ index.php [PT,L] </IfModule> И третий обучающий момент. Хотя в конечном итоге все перенаправляется на index.php, и модуль-правило называются rewrite, «переписывания» как такого не происходит? - изначальный пользовательский запрос доступен в глобальном элементе $_SERVER['REQUEST_URI']. Возможно, некоторые выдающиеся личности смогут разложить по полочкам Заранее спасибо за участие. Добавлено спустя 29 минут 32 секунды: Вдогонку: читаю в документации, что [PT] уже подразумевает [L] (https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_pt)... т.е. возможно ",L" здесь так же лишний код? [PT] - это, я так понял важный флаг, если мы собираемся работать вдобавок с другими модулями, но пример с алиасом из документации не сформировал конкретного понимания. Буду благодарен за отдельное пояснение по данному флагу... Подсказка от модератора: Любой код или текст конфигурации пишите между тегом [code=php] и [/code]. Используйте отступы в коде для форматирования текста. Это помогает быстрее понять вас, увеличивает шанс на получение ответа. Что выделять? Например: PHP, HTML, CSS, JavaScript, SQL, XML, .htaccess, ini, регулярные выражения, код шаблонизаторов, любая другая разметка, результаты array/object dump и т. д.
denis01, спасибо за наставления. Вижу, что вы заменили Код (Text): на [code=php], но по поводу отступов в коде не могу отследить, в чем отличия.
для начала эти правила эквивалентны. в первом правиле ищется пустая строка а во втором правиле ищется строка любой длины. нулевая длина (пустая строка, первое правило) тоже сюда подходит. так что разработчики этого фреймворка скорее чего-то не знают. логически никакой разницы нет. одно ищет любое кол-во любых символов а второе - любое кол-во любых символов от начала до конца строки. то есть в первом случае просто не указано начала-конца. они там и так будут. первая строка "переписать пустой адрес" (чего кстати не может быть емнип) на каталог вебрут вложенный в текущий каталог. вторая строка "переписать любой адрес" на каталог вебрут вложенный в текущий каталог. нет, это особенность написанных выше правил. каталог вебрут в который совершен рерайт так же входит в правило "переписать любой адрес" и рерайтер тупо уходит в бесконечный цикл а достигая лимит рекурсии тормозит со статусом 500. в журнале ошибок все написано человеческим языком. рерайтер работает не с входящим адресом а с целевым ресурсом файловой системы сервера. у тебя есть допустим каталог /var/www/test/. при запросе /file.php этот адрес разрешается апачем в локальный файл /var/www/test/file.php. рерайтер собственно помогает гибко подменить цель. например если файла такого нет - направить на /index.php что на выходе из рерайтера будет указывать на /var/www/test/index.php который и обработает запрос. при этом исходный запрошенный адрес всегда доступен в requiest_uri иначе твой бэкэнд не сможет корректно сгенерировать ответ на запрос. Добавлено спустя 8 минут 30 секунд: конечно же первое-второе правило. первая строка тупо рерайтер включает.
Вообще, фреймворки обычно рекомендуют ставить выше DOCUMENT ROOT сервера, а в папку webroot (public_html, web - варианты могут быть разные) складывать только общедоступные файлы. Подобные htaccess нужны на хостингах, которые не позволяют писать выше document root или менять document root сайтов
denis01, ok Ganzal, благодарю за участие. Поясни, плз, точное значение "эквивалентны") Ясно, что для запроса site.com включится любое первое из них. Но если одно было применено, второе уже применено не будет? Не совсем понял, почему нельзя переписать пустую строку на строку? Понятно, что правила в конечном итоге применяются к путям, но ведь работают регулярные выражения со строками? Т.е. не уловил "чего кстати не может быть". Так и есть, спасибо за гайд) Рерайтер остановился после 10-ой рекурсии. Получается, что после "переписи", новый путь опять проверяется .htaccess в руте? Ganzal, можешь пару слов рассказать по этому поводу? - рерайтер обработанный путь затем снова сам у себя принимает, или как? Картина проясняется, благодаря качеству поступающей инфы) По поводу особенностей работы флага [PT] можешь сказать? mkramer, спасибо, что присоединился к теме. Твоя мысль ясна. Интересно, если эта рекомендация не соблюдается, и все файлы лежат в пределах document root - насколько возможно постороннему достать файл типа config.php с параметрами доступа к бд, солью и т.д.? Насколько велики риски? В случае если это стандартная какая-то cms, и вероятное нахождение файлов известно - .php файлы скачиваются?
это ровно то и значит. первая строка логически тождественна второй. потому что еминп там не будет пустой строки. но её конечно же можно переписать если она попадает под правило. совершенно верно. сначала идет разрешение запроса виртуальным хостом, потом алиасами и потом рерайтер работает столько, сколько нужно до получения целевого ресурса или достижения лимита рекурсии рерайтера. полученный ресурс возвращается на начало разрешения запроса - к виртуальным хостам, алиасам и так далее.
Ganzal, спасибо за ответы. В целом, есть понимание, кроме опять-таки данной формулировки. Это ведь разные правила, и по-разному включаются - если идет запрос site.com - включится первое правило (потому что стоит раньше), если site.com/blabla - второе. Первое правило не нужно, это уже понятно. Но в чем логическая тождественность?))
Нет, не скачиваются, кончено. Но могут быть вызваны напрямую, и видимо есть атаки, основанные на этом. Типа закачивается файл, который дописывает код, а потом файлы напрямую вызываются. Поэтому все файлы нормальных CMS содержат защиту от прямого доступа Код (PHP): if (!defined("MUST_BE_DEFINED")) die("HACKING ATTEMP");
в том что запрос идет не к сайт-ком и сайт-ком-слэш-блабла а к "" (пустая строка) и слэш-блабла. и обе эти строки могут быть обработаны одним единственным вторым правилом. да, про тождественность я перегнул. надо не так было сформулировать. первое правило является бессмысленным так как входит во второе.
mkramer, пасиб за полезную инфу. ок, узрел. докапывался, чтобы использовать формулировку сведущих людей как камертон - понять, насколько я далеко от верных определений. Оказалось, что не так уж и далеко) Беседа получилась весьма продуктивной (для меня), за что искренний респект.