| |
л
хоста.
# Сначала связываем имя обработчика с конкретным файлом.
# Знак "?" говорит серверу, что исходный URL запроса следует
# передать сценарию методом GET, т. е. через QUERY_STRING.
Action libhandler "/lib/libhandler.php?"
# Теперь уведомляем сервер, документы какого типа мы желаем
# "пропускать" через наш обработчик.
AddHandler libhandler .html .htm
В этом фрагменте есть два тонких места.
r Путь к сценарию обработчика всегда указывается как абсолютный URL без указа-
ния имени хоста и порта. Мы не можем задать здесь ни путь к файлу, ни даже от-
носительный URL. По той причине, чтобы позволить одному обработчику "пере-
давать эстафету" другому. В самом деле, ведь это и происходит в нашем примере:
Apache сначала определяет, что документ нужно "пропустить" через обработчик
libhandler, а т. к. он представляет собой ни что иное, как сценарий на PHP, то
и
через интерпретатор PHP. В деталях затронутый процесс чуть сложнее, но мы не
будем в него углубляться.
r После URL сценария в директиве Action следует знак ?. Зачем он? Это связано с
механизмом, который использует Apache для того, чтобы определить конечный
обработчик для того или иного документа. Когда пользователь посылает серверу
URL, который, как Apache "знает", подходит под одну из команд Action, к этому
URL слева просто присоединяется второй параметр директивы, и все начинается
сначала — до тех пор, пока не будет найден последний обработчик. Например, ес-
ли пользователь ввел /dir/file.html, то благодаря директиве Action указан-
ный адрес преобразуется в /lib/libhandler.php?/dir/file.html. Это — ни
что иное, как адрес PHP-сценария с параметром, который будет передан програм-
ме, как обычно, через переменную окружения QUERY_STRING.
Теперь сервер знает, что все документы с расширением html и htm нужно обрабаты-
вать при помощи сценария, расположенного по адресу /lib/libhandler.php. Точ-
нее, при каждой попытке открыть страницы с указанными расширениями Apache бу-
дет запускать наш сценарий и в числе обычных переменных окружения отправлять
ему несколько специальных, содержащих первичную информацию о запросе, пере-
данном пользователем. Мы сейчас рассмотрим эти переменные на практике. Если вас
интересует их полный список, попробуйте распечатать массив $GLOBALS или вос-
Глава 29. Модульность программы. Написание "библиотекаря"
409
пользоваться функцией phpinfo(), вставив ее первой и единственной командой об-
работчика libhandler.php.
Вы, возможно, спросите, почему же мы не добавили в список расширений, на
которые будет "реагировать" сценарий, еще одно — php? Давайте посмотрим,
что бы произошло, поступи мы так. Предположим, пользователь хочет загру-
зить страницу /a.php. Apache "видит", что расширение у нее — php, и запус-
кает обработчик с именем /lib/libhandler.php. Точнее, он "сваливает"
всю работу на сценарий libhandler.php. Еще точнее — перенаправляет
сервер по адресу /lib/libhandler.php?a.php! И тут же зацикливается,
потому что у этого сценария расширение — также php. Итак, сервер начинает
вызывать сценарий снова и снова, все удлиняя его URL — до тех пор, пока не
"поймет": что-то неверно, и пора аварийно завершаться, о чем и сообщает в
файлах журнала. О том, как решить эту проблему, рассказано в самом конце
главы.
Ну вот, у нас уже почти все готово. Осталось только написать сам код
обработчика.
Это не так уж и сложно. Но прежде давайте вспомним, зачем мы вообще связались с
обработчиками. Для автоматической загрузки библиотекаря перед выполнением того
или иного сценария, помните? Что же, вот пример (листинг 29.5).
Мы подразумеваем, что обработчик libhandler.php находится в том же са-
мом каталоге, что и библиотекарь с большинством модулей. Это довольно
удобно, поскольку позволяет нам задавать путь к каталогу с модулями лишь в
единственном месте — в директиве Action файла .htaccess,
|
|
