ются как сценарии на PHP. Они запускаются уже после того, как 
подключен библиотекарь, так что могут пользоваться функцией Uses(). 
Если вы не собираетесь использовать библиотекарь, а хотите применять опи- 
санный выше механизм только для того, чтобы включить PHP для файлов с 
расширением html, лучше прочитайте конец этой главы. Там описано, как сде- 
лать это проще. 
Перехват обращений 
к несуществующим страницам 
Самое интересное, что наш обработчик будет вызываться как для существующих 
файлов с расширением html, так и для несуществующих (правда, расположенных в 
существующем каталоге). Какой простор это открывает для творчества! Например, 
мы можем написать систему новостей или форум, в котором у всех сценариев не бу- 

дет ни одного "видимого" параметра. Все данные могут передаваться прямо в имени 

файла, например: 
/forum/Computers-01-04-01.html 
Хотя файла Computers-01-04-01.html нет и в помине, обработчик может пере- 
хватить запрос к нему и определить, что речь идет о новостях в разделе 
"Компьютеры" за 1 апреля 2001 года. Затем, получив нужную информацию из базы 
данных, остается лишь отправить ее клиенту. 
Обычно для подобных целей используют специальный модуль Apache — 
mod_rewrite. К сожалению, по статистике далеко не все хостинг-провайдеры 

Часть V. Приемы программирования на PHP 
412 
соглашаются устанавливать его на свои серверы. В то же время механизм 
ActionAddHandler работает всегда и везде, где установлен Apache. 
Надо заметить, что в примере из листинга 29.5 мы никак не перехватываем обраще- 

ния к несуществующим страницам. Что происходит, если пользователь все же введет 

неправильный адрес? Очевидно, вызов include, стоящий в предпоследней строчке, 
завершится неуспешно, а PHP выведет сообщение об ошибке. Наверное, в реальной 
программе нужно как-то обрабатывать эту ситуацию, — например, при помощи про- 
верки существования запрошенного файла. 
Связывание PHP с другим расширением 
Как мы знаем, сам PHP представляет собой обычный обработчик. Значит, скажете 
вы, чтобы заставить его обрабатывать документы с расширением, отличным от PHP, 
нам нужно просто добавить директиву AddHandler для этого расширения в соответ- 
ствующий файл .htaccess? Не совсем. Проблема заключается в том, что мы не зна- 
ем идентификатора обработчика, он хранится где-то в недрах кода интерпретатора. 

Вместо этого мы поступим по-другому: заставим Apache считать, что документы с 
нужным нам расширением имеют тот же тип, что и с расширением php. 
Что же такое тип документа? Это еще одно понятие, которое использует Apache в 
своей работе. Некоторые из этих типов также "понимают" и браузеры. В их числе, 
например, text/html, обозначающий HTML-страницу, image/gif, который сигна- 
лизирует, что данные являются рисунком GIF, 
и т. д. Именно этими типами (а не расширениями страниц!) руководствуются 
браузе- 
ры, когда решают, в каком формате прислал сервер данные. 
Однако есть несколько типов документов, которые никогда не отсылаются браузеру 
в 
исходном виде. Один из них — application/x-httpd-php. Именно с этим типом 
и связан интерпретатор PHP. Если сервер "видит", что пользователь запросил 
стра- 
ницу, которая имеет тип application/x-httpd-php, он активизирует PHP, а уж тот 
берет на себя всю дальнейшую ответственность по запуску сценария и выводу "пра- 

вильного" заголовка типа (чаще всего text/html) в браузер. 
Как же сервер узнает, какой тип имеет тот или иной документ? Вообще говоря, это 

отдельная проблема. Самое простое ее решение — определять тип по расширению 
файла. В большинстве случаев это оказывается самым лучшим решением. Програм- 
мист может сам задать, какое расширение соответствует тому или иному типу, 
доба- 
вив в нужный файл .htaccess следующую директиву: 
AddType имя_типа расширение1 расширение2 … 
А как быть, если многие из наших д