Пункт 219. Преобразование модулей версии 1.3 в версию 2.x
Это первая попытка записать уроки, которые я усвоил, пытаясь преобразовать mod_mmap_static модуль в Apache 2.0. Это ни в коем случае не является окончательным и, вероятно, даже не будет правильным в некоторых отношениях, но это только начало.
Чем проще изменения...
Процедуры очистки
Теперь они должны быть типа apr_status_t и возвращать значение этого типа. Обычно возвращаемое значение будет
APR_SUCCESS таким, если нет необходимости сигнализировать об ошибке при очистке. Имейте в виду, что даже если вы сообщаете об ошибке, не весь код еще проверяет и реагирует на ошибку.
Процедуры инициализации
Теперь их следует переименовать, чтобы лучше обозначить их место в общем процессе. Таким образом, имя получает небольшое изменение с
mmap_init на mmap_post_config . Передаваемые аргументы претерпели радикальное изменение и теперь выглядят как
-
apr_pool_t *p
-
apr_pool_t *plog
-
apr_pool_t *ptemp
-
server_rec *s
Типы данных
Многие типы данных были перемещены в APR. Это означает, что у некоторых было изменено имя, например, как показано выше. Ниже приводится краткий список некоторых изменений, которые вам, вероятно, придется внести.
-
pool становится apr_pool_t
-
table становится apr_table_t
Более грязные изменения...
Регистрация хуков
В новой архитектуре используется ряд хуков, обеспечивающих вызов ваших функций. Их вам нужно будет добавить в свой модуль с помощью новой функции static void register_hooks(void) . Функция действительно достаточно проста, когда вы понимаете, что нужно сделать. Каждую функцию, которую нужно вызвать на каком-то этапе обработки запроса, нужно регистрировать, обработчики — нет. Существует несколько фаз, на которых можно добавлять функции, и для каждой из них вы можете указать с высокой степенью контроля относительный порядок, в котором функция будет вызываться.
Это код, который был добавлен в mod_mmap_static :
статическая пустота register_hooks (пустота)
{
static const char * const aszPre[]={ "http_core.c",NULL };
ap_hook_post_config (mmap_post_config, NULL, NULL, HOOK_MIDDLE);
ap_hook_translate_name (mmap_static_xlat, aszPre, NULL, HOOK_LAST);
};
Это регистрирует 2 функции, которые необходимо вызвать: одну на post_config этапе (практически каждому модулю она понадобится) и одну для translate_name фазы. обратите внимание, что хотя существуют разные имена функций, формат каждого из них идентичен. Итак, что такое формат?
ap_hook_phase_name(function_name,
predecessors, successors, position);
Определено 3 положения крюка...
-
HOOK_FIRST
-
HOOK_MIDDLE
-
HOOK_LAST
Чтобы определить позицию, вы используете позицию, а затем изменяете ее с помощью предшественников и преемников. Каждый из модификаторов может быть списком функций, которые должны быть вызваны либо до запуска функции (предшественники), либо после запуска функции (преемники).
В этом mod_mmap_static случае меня не волновал этап
post_config , но он mmap_static_xlat
должен быть вызван после того, как основной модуль выполнил преобразование своего имени, отсюда и использование aszPre для определения модификатора позиции HOOK_LAST .
Определение модуля
Теперь при создании определения модуля нужно беспокоиться о гораздо меньшем количестве этапов. Старое определение выглядело так
модуль MODULE_VAR_EXPORT имя_модуля _module =
{
STANDARD_MODULE_STUFF,
/* инициализатор */
/* создатель конфигурации каталога */
/* слияние каталогов --- по умолчанию используется переопределение */
/* конфигурация сервера */
/* объединить конфигурацию сервера */
/* обработчики команд */
/* обработчики */
/* перевод имени файла */
/* check_user_id */
/* проверка авторизации */
/* проверка доступа */
/* type_checker */
/* исправления */
/* регистратор */
/* парсер заголовков */
/* дочерняя_инициализация */
/* дочерний_выход */
/* отправить запрос на чтение */
};
Новая структура намного проще...
модуль MODULE_VAR_EXPORT имя_модуля _module =
{
STANDARD20_MODULE_STUFF,
/* создание структур конфигурации для каждого каталога */
/* объединить структуры конфигурации для каждого каталога */
/* создание структур конфигурации для каждого сервера */
/* объединить структуры конфигурации для каждого сервера */
/* обработчики команд */
/* обработчики */
/* регистрация хуков */
};
Некоторые из них читаются прямо, некоторые нет. Ниже я попытаюсь обобщить то, что нужно сделать.
Этапы, которые читаются прямо через:
-
/* dir config creater */
-
/* create per-directory config structures */
-
/* server config */
-
/* create per-server config structures */
-
/* dir merger */
-
/* merge per-directory config structures */
-
/* merge server config */
-
/* merge per-server config structures */
-
/* command table */
-
/* command apr_table_t */
-
/* handlers */
-
/* handlers */
Остальные старые функции должны быть зарегистрированы как хуки. На данный момент определены следующие этапы ловушки...
-
ap_hook_pre_config
- выполнить любую настройку, необходимую перед обработкой директив конфигурации
-
ap_hook_check_config
- просмотрите взаимозависимости директив конфигурации
-
ap_hook_test_config
- выполняется только с
-t опцией
-
ap_hook_open_logs
- открыть любые указанные журналы
-
ap_hook_post_config
- здесь
_init регистрируются старые подпрограммы
-
ap_hook_http_method
- получить метод http из запроса. (наследие)
-
ap_hook_auth_checker
- проверить, требует ли ресурс авторизации
-
ap_hook_access_checker
- проверить ограничения для конкретных модулей
-
ap_hook_check_user_id
- проверьте идентификатор пользователя и пароль
-
ap_hook_default_port
- получить порт по умолчанию для сервера
-
ap_hook_pre_connection
- выполнить любые необходимые настройки непосредственно перед обработкой, но после принятия
-
ap_hook_process_connection
- запустить правильный протокол
-
ap_hook_child_init
- позвоните, как только ребенок заведется
-
ap_hook_create_request
- ??
-
ap_hook_fixups
- последний шанс изменить что-то перед созданием контента
-
ap_hook_handler
- генерировать контент
-
ap_hook_header_parser
- позволяет модулям просматривать заголовки, не используемые большинством модулей, потому что они используют
post_read_request для этого
-
ap_hook_insert_filter
- чтобы вставить фильтры в цепочку фильтров
-
ap_hook_log_transaction
- логировать информацию о запросе
-
ap_hook_optional_fn_retrieve
- получить любые функции, зарегистрированные как необязательные
-
ap_hook_post_read_request
- вызывается после чтения запроса, перед любой другой фазой
-
ap_hook_quick_handler
- вызывается перед обработкой любого запроса, используемого модулями кеша.
-
ap_hook_translate_name
- перевести URI в имя файла
-
ap_hook_type_checker
- определить и/или установить тип документа
