Apache: Обработка запросов в версии 2.x

RU EN

Пункт 220. Обработка запросов в версии 2.x

Предупреждение — это первый (быстрый) черновик, который нуждается в доработке!

Некоторые изменения в версии 2.0 и выше влияют на внутреннюю механику обработки запросов. Авторы модулей должны знать об этих изменениях, чтобы они могли воспользоваться оптимизацией и улучшениями безопасности.

Первое серьезное изменение касается механизмов подзапроса и перенаправления. В Apache HTTP Server 1.3 было несколько различных путей кода, чтобы попытаться оптимизировать поведение подзапроса или перенаправления. Когда в версию 2.0 были внесены исправления, эти оптимизации (и поведение сервера) были быстро нарушены из-за дублирования кода. Весь повторяющийся код был свернут обратно ap_process_request_internal() , чтобы предотвратить повторную рассинхронизацию кода.

Это означает, что большая часть существующего кода была «неоптимизированной». Первой целью проекта Apache HTTP является создание надежной и правильной реализации RFC для HTTP-сервера. Дополнительные цели включают безопасность, масштабируемость и оптимизацию. Были найдены новые методы оптимизации сервера (помимо производительности 1.3) без добавления ненадежного или небезопасного кода.

Цикл обработки запроса

Все запросы проходят через ap_process_request_internal() , server/request.c включая подзапросы и редиректы. Если модуль не пропускает сгенерированные запросы через этот код, автор предупреждается, что модуль может быть поврежден будущими изменениями в обработке запросов.

Чтобы упростить запросы, автор модуля может воспользоваться хуками, предлагаемыми для раннего выхода из цикла запроса, или для обхода основных хуков, которые не имеют значения (и затратны с точки зрения ЦП).

Фаза разбора запроса

Отменяет экранирование URL

Путь запроса parsed_uri не экранируется один и только один раз в начале внутренней обработки запроса.

Этот шаг пропускается, если установлен флаг proxyreq или parsed_uri.path элемент не установлен. Модуль не имеет дальнейшего контроля над этой одноразовой операцией отмены экранирования, либо неспособность отменить экранирование, либо многократное удаление экранирования URL-адреса приводит к последствиям для безопасности.

Удаляет родительский и этот элементы из URI

Все элементы /../ и /./ удаляются с помощью ap_getparents() . Это помогает обеспечить (почти) абсолютный путь до продолжения обработки запроса.

Этот шаг нельзя обойти.

Прогулка по начальному местоположению URI

Каждый запрос подлежит звонку ap_location_walk() . Это гарантирует, что <Location> разделы последовательно применяются для всех запросов. Если запрос является внутренним перенаправлением или подзапросом, он может частично или полностью заимствовать обработку из ap_location_walk предыдущего или родительского запроса, поэтому этот шаг обычно очень эффективен после обработки основного запроса.

translate_name

На этом шаге модули могут определить имя файла или изменить заданный URI. Например, mod_vhost_alias он преобразует путь URI в настроенный виртуальный хост, mod_alias преобразует путь в путь-псевдоним и, если запрос возвращается к основному серверу, DocumentRoot к ресурсу запроса добавляется .

Если все модули DECLINE на этом этапе, в браузер возвращается ошибка 500, и автоматически регистрируется ошибка «не удалось перевести имя».

Хук: map_to_storage

После определения файла или правильного URI соответствующие конфигурации для каждого каталога объединяются. Например, mod_proxy сравнивает и объединяет соответствующие <Proxy> разделы. Если URI представляет собой не что иное, как локальный (не прокси-сервер) TRACE запрос, ядро обрабатывает запрос и возвращает DONE . Если ни один модуль не ответит на этот хук с помощью OK или DONE , ядро выполнит имя файла запроса для разделов <Directory> и <Files> . Если запрос «имя файла» не является абсолютным допустимым именем файла, устанавливается примечание для последующего прекращения.

Прогулка по местоположению URI

Каждый запрос усиливается вторым ap_location_walk() вызовом. Это гарантирует, что переведенный запрос по-прежнему подчиняется настроенным <Location> разделам. Запрос снова заимствует часть или всю обработку из предыдущего location_walk выше, поэтому этот шаг почти всегда очень эффективен, если только преобразованный URI не сопоставлен с существенно другим путем или виртуальным хостом.

Хук: header_parser

Затем основной запрос анализирует заголовки клиента. Это подготавливает оставшиеся этапы обработки запроса для лучшего обслуживания запроса клиента.

Этап безопасности

Нужна документация. Код:

 если ((access_status = ap_run_access_checker(r)) != 0) {
 вернуть decl_die(access_status, "проверить доступ", r);
}
если ((access_status = ap_run_check_user_id(r)) != 0) {
 вернуть decl_die(access_status, "проверить пользователя", r);
}
если ((access_status = ap_run_auth_checker(r)) != 0) {
 return decl_die(access_status, "проверить авторизацию", r);
}

Фаза подготовки

Хук: type_checker

Модули имеют возможность проверить URI или имя файла на соответствие целевому ресурсу и установить MIME-информацию для запроса. Оба mod_mime и mod_mime_magic используют эту фазу для сравнения имени файла или содержимого с конфигурацией администратора и установки типа содержимого, языка, набора символов и обработчика запросов. Некоторые модули могут настроить свои фильтры или другие параметры обработки запросов в это время.

Если все модули DECLINE на этом этапе, в браузер возвращается ошибка 500, и автоматически регистрируется ошибка «не удалось найти типы».

Крючок: исправления

Многие модули «побеждены» какой-то фазой выше. Фаза исправления используется модулями, чтобы «подтвердить» свое право собственности или принудительно установить для полей запроса соответствующие значения. Это не всегда самый чистый механизм, но иногда это единственный вариант.

Фаза обработчика

Этот этап не является частью обработки в ap_process_request_internal() . Многие модули подготавливают один или несколько подзапросов до создания какого-либо контента. После вызова ядра или модуля ap_process_request_internal() он вызывается ap_invoke_handler() для генерации запроса.

Хук: insert_filter

Модули, которые каким-либо образом преобразуют содержимое, могут вставлять свои значения и переопределять существующие фильтры, так что, если пользователь настроил более сложный фильтр не по порядку, модуль может изменить свой порядок по мере необходимости. Кода результата нет, поэтому действиям в этом хуке лучше доверять, чтобы они всегда были успешными.

Крючок: обработчик

Модуль, наконец, получает возможность обслужить запрос в своем обработчике. Обратите внимание, что не каждый подготовленный запрос отправляется в хук обработчика. Многие модули, такие как mod_autoindex , будут создавать подзапросы для заданного URI, а затем никогда не обслуживать подзапрос, а просто отображать его для пользователя. Не забудьте не помещать в этот модуль требуемый разрыв из хуков выше, а регистрировать очистки пула в пуле запросов, чтобы освобождать ресурсы по мере необходимости.