ой сервера. Последние могут быть помещены в любой каталог, содержащий 
сценарии на PHP. Таким образом, для заданного каталога и всех его подкаталогов 
указанные настройки всегда будут действовать. 
Помните, что для помещения директивы PHP с каким-нибудь именем NAME в 
файл .htaccess ее нужно назвать php_NAME, а значение отделить от имени 
не знаком =, как в php.ini, а пробелом. В противном случае Apache будет со- 
общать о неизвестной директиве в файле конфигурации. 
Среди обрабатываемых интерпретатором директив есть две особенных. Называются 
они auto_prepend_file и auto_append_file. В первой задается абсолютный 
путь к файлу, содержащему код на PHP, который будет автоматически выполняться 
перед запуском любого сценария. Не правда ли, это то, что нам нужно? 
Конечно, вставлять директиву auto_prepend_file в глобальный php.ini нет ни- 
какого смысла. Ведь у подавляющего большинства хостинг-провайдеров одни и те же 

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

ки интерпретатора. В этом случае модификация файлов .htaccess оказывается 
единственно правильным и возможным решением. Правда, для этого нам нужно 
знать, какой физический каталог соответствует на нашем сервере корневому для 
до- 
кументов. Выяснить это можно, например, с помощью такого простого сценария: 
Листинг 29.4. Определение физического корневого каталога сервера 
 

Глава 29. Модульность программы. Написание "библиотекаря" 
407 
Пусть, к примеру, у нашего хостинг-провайдера используется каталог 
/home/dk/www. Тогда для автоматического подключения библиотекаря ко всем сце- 
нариям на PHP нужно добавить в файл .htaccess примерно такую строку: 
php_auto_prepend_file /home/dk/www/lib/librarian.phl 
Вообще говоря, лучше всего сделать это в файле .htaccess, который нахо- 
дится в корневом каталоге сервера, для того чтобы подключение библиотекаря 
происходило ко всем сценариям во всех каталогах. Если этого файла не суще- 
ствует, необходимо его создать. 
Как уже упоминалось, данный способ не подходит для того виртуального сервера 
для 
Windows, установка которого описана в части II настоящей книги. Изменение 
php.ini — тоже не очень удачная идея в силу вышеизложенных рассуждений. Тут 
нам на помощь придет второй способ, который мы сейчас и рассмотрим. 
Способ второй: установка обработчика Apache 
Установка своего обработчика сопряжена с несколько большими сложностями, чем 
использование директив auto_prepend_file и auto_append_file. Тем не менее, 
он позволяет нам получить чуть больший контроль над сервером, поскольку 
перекла- 
дывает задачу выбора и запуска нужного сценария на плечи программиста. Это — 
установка нового обработчика Apache. Тема настолько важна, что мы, пожалуй, от- 

ложим на время нашего библиотекаря (к нему мы еще обязательно вернемся) и зай- 
мемся непосредственно обработчиками. 
Обработчики Apache 
Итак, что же такое обработчик Apache? На самом деле мы постоянно сталкиваемся с 

одним из классических примеров обработчика. Да-да, вы уже догадались: это сам 
PHP. Если чуть углубиться в теорию, то обработчиком называется сценарий (воз- 
можно, встроенный в сам сервер, как это происходит с PHP), который запускается 
сервером при попытке пользователя открыть ту или иную страницу определенного 
типа. 
Каждый обработчик должен иметь уникальный идентификатор — имя обработчика, 
который я для краткости буду называть просто именем. Оно может состоять только 
из 
алфавитно-цифровых символов и знаков подчеркивания. Заметьте, что это имя — не 
то же самое, что имя файла сценария, в котором хранится код обработчика. Имя 
об- 
работчика и является тем, которое нужно указывать серверу в директиве 
AddHandler, когда мы хотим связать определенные документы с нашим сценарием. 

Часть V. Приемы программирования на PHP 
408 
Но как же сопоставить идентификатор обработчика тому сценарию, который содер- 
жит его код? У сервера Apache для этого есть специальная директива под 
названием 
Action. Где задается эта директива? В любом файле конфигурации Apache. Конечно, 

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