У цій публікації ми розглянемо ті директиви, які не встигли охопити в попередніх частинах. Ці директиви не піддаються визначенню на рівні директорій. Це означає те, що ви повинні мати доступ до файлу конфігурації веб-сервера Apache (httpd.conf).
Зазвичай такий доступ мають користувачі «root» або адміністратор сервера.
Якщо ви хочете вести логи всіх операцій, виконаних за допомогою mod_rewrite, можна активувати за допомогою наступної запису:
RewriteLog /usr/local/apache/logs/mod_rewrite_log
RewriteLogLevel 1
Цей рядок потрібно вписати в «Розділ 2: Конфігурація сервера» у файлі httpd.conf, а не в .htaccess!
Всі маніпуляції, вироблені mod_rewrite будуть записуватися до файлу. Ім’я лог файлу може бути будь-яким. Ви можете вказати абсолютний або відносний (стосовно ServerRoot) шлях до файла.
Якщо ви хочете вести різні лог файли для різних віртуальних хостів, то потрібно ввести зміни до «Розділ 3: Віртуальні сервера», наприклад так:
ServerAdmin [email protected]
DocumentRoot /usr/www/htdocs/yourdomain
ServerName yourdomain.com
RewriteLog /usr/apache/logs/yourdomain_mod_rewrite_log
RewriteLogLevel 1
RewriteLogLevel може бути визначений в межах діапазону від 1 до 8. Зазвичай достатньо першого рівня. Більш високі рівні використовуються для деббагинга.
Інша директива, яка є дуже зручною в цілях клоакинга – це так звана карта перезапису. Це файли, що містять пари ключ/значення, зазвичай у форматі текстового файлу:
cde2c920.infoseek.com spider
205.226.201.32 spider
cde2c923.infoseek.com spider
205.226.201.35 spider
cde2c981.infoseek.com spider
205.226.201.129 spider
cde2cb23.infoseek.com spider
205.226.203.35 spider
Ключі, як ви бачите, імена хостів або IP адреси. У цьому простенькому прикладі значення завжди одне – «spider». Звісно, в реальному файлі значення будуть інші. Ця директива може бути записана у другій («Конфігурація сервера») або третій («Віртуальні сервера») розділ файлу httpd.conf:
RewriteMap botBase txt:/www/yourdomain/spiderspy.txt
«Карта перезапису» матиме ефект на весь сервер.
Також, у файл .htaccess записується:
RewriteCond ${botBase:%{REMOTE_HOST}} =spider [OR]
RewriteCond ${botBase:%{REMOTE_ADDR}} =spider
RewriteRule ^(.*).htm$ $1.htm [L]
RewriteRule ^.*.htm$ index.html [L]
Дані умови будуть проводити системну перевірку: зроблено запит пошукачем. З цією метою проводиться пошук по файлу spiderspy.txt. Якщо ключ знайдено, буде повернуто значення «spider», а «умова» буде істинним.
Потім виконується перший RewriteRule. Це означає те, що запитувана «.htm» сторінка буде віддана пошуковику. Змінна $1 дорівнює частині в круглих дужках «^(. *).htm$», тобто ім’я файлу залишиться тим же самим.
Якщо ж URL викликаний звичайним відвідувачем, то застосовується друге «правило»: користувач буде перенаправлено на сторінку «index.html».
Оскільки «.htm» сторінки будуть читатися тільки «павуками», вони можуть бути оптимізовані відповідно для пошукових серверів. Ви можете також використовувати файл у форматі «dbm» замість звичайного текстового файлу. Бінарний формат даних дозволяє прискорити пошук, який є особливо важливим, якщо ви працюєте з дуже великими списками пошуковиків. Приклад, даний вище, пропонує прості функціональні можливості клоакинга. Всі звичайні відвідувачі завжди будуть переадресовуватися до сторінки «index.html» і не буде вестися ніяких лог-файлів поза логів mod_rewrite.
Можна замінити кілька рядків коду php (perl і т. д.) у ваших додатках, використовуючи всього одну-дві рядки mod_rewrite. Останній приклад проілюструє це більш детально.
Мета – показати відвідувачам «фото дня». Відвідувач, кликнувший за посиланням http://yoursite.com/pic.html побачить кращу фотографію або картинку дня, і так кожен день. Ми будемо працювати з внутрішніми змінними:
TIME_MON
TIME_DAY
Помістимо в файл .htaccess одну єдину рядок:
RewriteRule ^pic.html$ pic-%{TIME_MON}-%{TIME_DAY}.html
Запитуваний URL буде перезаписаний, наприклад:
pic-08-28.html
pic-08-29.html
pic-08-30.html
і так далі.
Тепер, все що ви повинні зробити – це один раз завантажити файли з відповідними іменами і забути про щоденне оновлення посилання. Змінні часу також можуть використовуватися для іншої періодичності.
Це був останній приклад в серії публікацій про чудовому модуль mod_rewrite. Природно неможливо було охопити всі нюанси, директиви, змінні і т. д. в даній публікації, метою було інше – дати загальне уявлення і розуміння основ, і так би мовити «ввести в курс справи».
