Общие сведения > Обработка uri

Редактор GitHub

Введение

Laravel: Когда вы используете любое приложение в “реальном мире”, вы чувствуете себя более уверенным когда знаете как оно работает. Разработка программного обеспечения не исключение. Когда вы понимаете как работает та или иная система, вы чувствуете себя комфортнее.

Жизненный цикл запроса

В отличие от многих современных MVC-фреймворков, продукт Битрикс24 не использует концепцию единой точки входа. Это дает преимущество в гибкости построения маршрутов и не накладывает искусственных ограничений на разработчика.

Как выполняется запрос?

  1. Проверяется физическое существование файла (если в запросе указан файл), директории (если в запросе нет конкретного файла или он index.php) или существование символьной ссылки. Если они существуют - будут подключены и исполнены.
  2. Происходит подключение файла с обработкой правил /bitrix/urlrewrite.php. Если найдено правило - подключается файл согласно правилу, если нет - шаг пропускается.
  3. Подключается файл 404.php

Исторически битрикс отрабатывает все правила переадресации через 404 ошибку, учитывайте это при разработке вашего программного обеспечения.

Структура urlrewrite.php

На момент написания статьи платформа использует аналог роутов (маршрутов) - правила адресации. Все существующие в системе правила описываются в переменной $arUrlRewrite внутри urlrewrite.php.

Каждое правило состоит из нескольких полей, описывающих его:

  • CONDITION - регулярное выражение для проверки $_SERVER["REQUEST_URI"]
  • RULE - правила замены переменных для строки переменных
  • ID - имя компонента добавившего правило
  • PATH - физический файл, который будет подключен
  • SORT - приоритет правила для сортировки

Правила располагаются в файле в порядке приоритетов сортировки, однако при одинаковой сортировке правила будут отсортированы по длине поля CONDITION.

Необходимым минимумом для описания маршрута являются ключи CONDITION и PATH.

Пример маршрутов, описанных в файле:

$arUrlRewrite = [
    [
        'CONDITION' => '#^/pub/form/([0-9a-z_]+?)/([0-9a-z]+?)/.*#',
        'RULE' => 'form_code=$1&sec=$2',
        'ID' => NULL,
        'PATH' => '/pub/form.php',
        'SORT' => 100,
    ],
    [
        'CONDITION' => '#^/crm/configs/deal_category/#',
        'RULE' => '',
        'ID' => 'bitrix:crm.deal_category',
        'PATH' => '/crm/configs/deal_category/index.php',
        'SORT' => 100,
    ]
];

Давайте остановимся и разберем как это работает на примере запроса к несуществующей странице /fake/page.php:

  1. Будет произведена проверка физического существования файла (/fake/page.php) - файла не существует.
  2. Будет произведена проверка на существование директории /fake (для обработки .htaccess) - директории не существует.
  3. В порядке очередности будет применяться каждое регулярное выражение для проверки на соответствие. Правило не найдено.
  4. Подключается 404.php

Рассмотрим еще один пример - клиент запрашивает ссылку: /pub/form/abc/123/test.php?key=value:

  1. Будет произведена проверка физического существования файла /pub/form/abc/123/test.php - файла не существует.
  2. Будет произведена проверка на существование директории /pub/form/abc/123/ - директории не существует.
  3. В порядке очередности будет применяться каждое регулярное выражение для проверки на соответствие. Найдено правило: '#^/pub/form/([0-9a-z_]+?)/([0-9a-z]+?)/.*#'.

В результате на запрос /pub/form/abc/123/test.php?key=value будет эквивалентен запросу /pub/form.php?form_code=abc&sec=123, но что же случилось с параметром key ? Битрикс активно использует подмену глобальных переменных и в случае если мы обратимся к $_SERVER['QUERY_STRING], то мы не увидим нашего значения, однако оно будет по-прежнему доступно через глобальные переменные $_GET, $_POST и $_REQUEST, точно так же как и добавленные правилом form_code и sec.

Помните что поля добавленные правилом имеют приоритет на стандартными, поэтому в данном конкретном случае мы не имеет возможности передавать form_code и sec.

Как работает RULE-параметр

Параметр RULE является необязательным для описания маршрута, однако именно он открывает много возможностей для управления ЧПУ.

Именно на его основе формируется реальный используемый URL путем выполнения preg_replace функции с аргументами CONDITION, PATH.RULE на REQUEST_URL.

Таким образом битрикс обработает наш запрос как если бы он сразу поступил на адрес /pub/form.php?form_code=some_test&sec=somesec.

Пересоздания правил обработки адресов

1С-Битрикс предоставляет стандартный инструмент пересоздания правил обработки адресов, который располагается в административной панели. Авторы этого труда настоятельно не рекомендуют применять его при работе с Битрикс24.

Как работает этот инструмент? После запуска инструмента обработчик проходится по всеми физическим файлам в рабочей директории, собирает вызовы компонентов ($APPLICATION->IncludeComponent), собирает оттуда правила обработки адресов (SEF) и генерирует новый список правил.

Причины по которым не рекомендуется применение этого инструмента в разрезе продукт Битрикс24:

  1. Модули “Диск”, “REST”, “Мобильное приложение” и другие добавляют собственные правила, которые не ссылаются на файлы с вызовом компонентов. Эти правила будут утеряны без возможности восстановления.
  2. При использовании require/include функций не происходит корректной индексации файлов.

Роутинг

Несмотря на наличие механизма правил ЧПУ, которые прекрасно выполняют свою работу, в современных условиях недостаточно. Поскольку на момент написания статьи механизм не является распространенным и не поставляется в продукт по-умолчанию (его необходимо сконфигурировать), мы не будем рассматривать этот момент и оставим его на самостоятельное изучение.

Полезные ссылки

  1. Пересоздание правил обработки адресов
  2. Роутинг