Эта тема гораздо шире тех возможностей, которые мы имеем в рамках данной книги. Нижеследующее описание предназначено служить исключительно введением в данную тему, чтобы помочь технически продвинутым читателям (и в том числе web-разработчикам и web-мастерам) понять функционирование перезаписи и перенаправления. Если вы хотите пропустить это техническое описание, переходите к следующему разделу.
Modrewrite для сервера Apache и ISAPIRewrite для сервера Microsoft IIS Server предлагают очень мощные способы переписывания ваших URL. Вот некоторые причины для использования этих мощных инструментов:
• вы изменили структуру URL вашего сайта таким образом, что контент переместился из одного места в другое. Такое может произойти при замене системы CMS или при изменении организации вашего сайта (по любой причине);
• вы хотите поставить в соответствие вашим недружественным для поисковых движков URL более дружественные URL.
Если вы используете в качестве web-сервера Apache, то должны будете разместить директивы "правил перезаписи" в файле. htaccess или в файле конфигурации вашего сервера Apache (например, в файле httpd.conf или в специфичном для сайта файле конфигурации (в каталоге sites_conf)). Если же вы используете IIS Server, то примените дополнительный модуль ISAPI (такой, как ISAPI_Rewrite) и разместите правила в конфигурационном файле httpd.ini.
Обратите внимание, что правила ISAPI_Rewrite несколько отличаются от правил mod rewrite. Дальнейшее наше обсуждение будет сосредоточено на mod rewrite.
Ваш файл. htaccess должен начинаться со следующего:
RewriteEngine on
RewriteBase /
Если вы добавляете правила перезаписи в файл конфигурации вашего сервера, то следует опустить вторую строку (поскольку RewriteBase поддерживается только для. htaccess). Мы используем здесь RewriteBase для того, чтобы вы могли писать только ^ (а не ^/) в начале каждого правила (регулярные выражения мы скоро обсудим).
После этого шага правила перезаписи будут готовы. Возможно, вы захотите иметь запросы товарных страниц в виде http://www.yourdomain.com/products/123(для показа контента по адресу at http://www.yourdomain.com/get_product.php?id=123) без изменения URL в поле Location браузера пользователя и без необходимости изменять скрипт get_product.php. Конечно, это не заменит все динамические URL в ссылках на всех страницах сайта (это отдельная проблема). Вы можете реализовать первую часть задачи при помощи одного правила перезаписи, примерно такого:
Здесь web-серверу указывается на то, что все приходящие на каталог /product/ запросы следует преобразовывать в запросы к /get_product.php, при этом подкаталог каталога /product/ используется как параметр для скрипта PHP.
Теперь посмотрим, что есть что:
• знак ^ обозначает начало URL (после имени домена);
• знак $ обозначает конец URL;
• [0–9] обозначает цифру;
• следующий сразу за цифрой знак + означает одно или несколько вхождений цифры;
• аналогично, знак? сразу же за знаком / обозначает ноль или одно вхождение символа косой черты;
• скобки () помещают в память то, что в них находится;
• при помощи $1 вы можете обратиться к тому, что сохранено в памяти (к тому, что было в первом комплекте скобок). Естественно, что при использовании в правиле второго комплекта скобок вы сможете получить к ним доступ при помощи $2 (и т. д.);
• флаг [L] экономит на обработке сервером, он говорит движку перезаписи о том, что в случае совпадения с правилом нужно остановиться. В противном случае все оставшиеся правила также будут выполнены.
Вот несколько более сложный пример, где URL формата http://www.yourdomain.com/webapp/wcs/stores/servlet/ProductDisplay?storeId=10001&catalogId=10001&langId=-1&categoryID=4&productID=123 будут перезаписываться как http://www.yourdomain.com/4/123.htm:
• знак [/] обозначает любой символ, кроме косой черты, потому что внутри квадратных скобок знак ^ интерпретируется как "нет";
• флаг [QSA] предназначен для случая, когда вы не хотите отбрасывать строку запроса (например, когда хотите сохранить параметр отслеживания).
Чтобы писать хорошие правила перезаписи, вам нужно стать специалистом по сопоставлению с шаблонами (это просто другое название работы с регулярными выражениями).
Вот некоторые из самых важных специальных символов и то, как они интерпретируются движком перезаписи:
• * означает 0 или более повторений предыдущего символа;
• + означает 1 или более повторений предыдущего символа;
• ? означает 0 или 1 вхождение предыдущего символа;
• ^ означает начало строки;
• $ означает конец строки;
• . означает любой символ (т. е. работает как групповой символ);
• \ означает "отказ" от специального значения следующего символа (например, \. означает то, что точка является не групповым символом, а обычным символом);
• ^ внутри скобок [] означает "нет" (например, [^/] означает "не косая черта".
В регулярных выражениях очень легко наделать ошибок.
Вот некоторые из наиболее часто встречающихся ошибок, которые могут привести к ненамеренным совпадениям строк:
• применение.* в том случае, когда нужно использовать.+ (поскольку.* не может совпасть ни с чем);
• отсутствие "отказа" от специального символа, который вы не хотите интерпретировать (например, когда вы указываете. вместо \. и имеете в виду символ точки, а не любой символ). Таким образом, default.htm совпадет с defaulthtm, а default\.htm совпадет только с default.htm;
• пропуск ^ или $ (в предположении, что начало или конец подразумеваются), т. е. default\.htmсовпадет с mydefault.html, а Adefault\.htm$ совпадет только с default.htm;
• использование "жадных" выражений, которые совпадут со всеми вхождениями (вместо того, чтобы остановиться после первого вхождения).
Самый простой способ проиллюстрировать "жадные" выражения – дать пример:
RewriteRule ^(.*)/?index\.html$ /$1/ [L,R=301]
Здесь производится редирект запросов с http://www.yourdomain.com/blah/index.html на http://www.yourdomain.com/blah//. Вероятно, это не то, что планировалось сделать. Почему так получилось?
Потому что .* захватит символ косой черты еще до того, как /? его увидит.
К счастью, это просто исправить. Нужно использовать [^ или .*? (вместо .*). Например, используйте ^(.*?)/? вместо ^(.*)/? или [^/]+/[^/] вместо.*/.*.
Итак, чтобы исправить предыдущее правило, вы можете написать следующее:
RewriteRule ^(.*?)/?index\.html$ /$1/ [L,R=301]
Почему бы не использовать вот такое:
RewriteRule ^([^/]*)/?index\.html$ /$1/ [L,R=301]
Это более ограниченный вариант, поскольку он будет давать совпадения только для URL с одним каталогом. URL с несколькими подкаталогами (например,http://www.yourdomain.com/store/cheese/swiss/wheel/index.html) совпадать не будут.
Понятно, что тестирование и отладка – это существенная часть перезаписи URL. Ваши лучшие друзья при отладке – директивы RewriteLog и RewriteLogLevel. Установите RewriteLogLevel в значение 4 и посмотрите, что делает движок перезаписи при интерпретации ваших правил.
Кстати, флаг [R=301] в последних нескольких примерах (как легко догадаться) говорит движку перезаписи о необходимости выполнить 301-й редирект (вместо стандартной перезаписи).
Есть еще одна очень удобная для совместного использования с RewriteRule директива под названием RewriteCond. Директиву RewriteCond следует использовать в тех случаях, когда вы пытаетесь найти совпадение в строке запроса, имени домена или прочих вещах (не присутствующих между именем домена и знаком вопроса в URL).
Обратите внимание, что ни RewriteRule, ни RewriteCond не могут обращаться к тому, что находится в якорной части URL, т. е. к тому, что следует за знаком #, поскольку оно используется браузером внутренним образом и не посылается на сервер как часть запроса.
А вот пример, когда RewriteCond ищет совпадение имени хоста и только после этого разрешает выполнить следующее далее правило перезаписи:
Обратите внимание на знак восклицания в начале регулярного выражения. Движок перезаписи интерпретирует это как "нет".
Для любого имени хоста (кроме http://www.yourdomain.com) выдается 301-й редирект на эквивалентный канонический URL поддомена www. Флаг [NC] делает условие перезаписи нечувствительным к регистру.
Вы можете спросить, где же флаг [QSA] для сохранения строки запроса? При редиректе он не нужен, т. к. в этом случае он просто подразумевается.
Если вы не хотите сохранять строку запроса в правиле перезаписи с редиректом, то поставьте в правиле знак вопроса в конец URL назначения:
Это не даст совпадений для доменов с опечатками вроде yourdoamin.com, на которые будут отвечать сервер DNS и виртуальный хост (если предположить, что ошибочно был написан тот домен, который зарегистрировали вы и который принадлежит вам).
При каких обстоятельствах вам может понадобиться опустить строку запроса из перенаправленного URL (как мы это делали в предыдущих двух примерах)? Когда нужно опустить идентификатор сеанса или параметр отслеживания (такой, как source=banner_ad1)? Сохранение параметра отслеживания после редиректа не только не нужно (поскольку оригинальный URL с приписанным к нему исходным кодом будет записан в ваших журналах доступа), но и нежелательно с точки зрения канонизации. Что будет, если вы захотите отбросить параметр отслеживания из перенаправленного URL, но сохранить остальные параметры строки запроса?
Обратите внимание на отсутствие в предыдущем коде флага [R=301]. Это сделано специально. Нет необходимости демонстрировать этот скрипт пользователю. Используйте перезапись и пусть скрипт сам отправит 301-й редирект после завершения своей работы.
Прочие случаи корректировок проблем канонизации при помощи правил перезаписи и флага [R=301]:
• когда поисковые движки индексируют страницы каталогов с указателями HTTPS;
• когда в конце URL отсутствует косая черта (которая там должна быть).
Сначала корректировка для HTTPS:
# redirect online catalog pages in the /catalog/ directory if HTTPS
Обратите внимание: если ваш безопасный сервер отделен от вашего основного сервера, то можно опустить строку RewriteCond.
Теперь для добавления концевой косой черты:
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]
После того как проект по перезаписи URL (для миграции с динамических на статические URL) будет завершен, вы захотите убрать динамические URL (не простой заменой всех вхождений устаревших URL вашего сайта, а при помощи 301-го редиректа устаревших динамических URL на их новые статические эквиваленты). При таком способе любые (указывающие на удаленные URL) входящие ссылки приведут и пауков, и людей на правильные новые URL, обеспечив их индексирование, ссылки и закладки на них (а старые URL будут удалены из индекса). Вот как можно этого добиться:
Однако если вы не будете осторожны, то получите бесконечный цикл рекурсивных редиректов. Быстрый (но некрасивый) способ избежать этого – добавить бессмысленный параметр в URL назначения при перезаписи и обеспечить отсутствие этого бессмысленного параметра перед выполнением редиректа, например:
Обратите внимание, что в примере использованы две строки RedirectCond (одна над другой). Все условия редиректа, перечисленные в одном блоке, будут связаны операцией AND. Если вы хотите, чтобы их связывала логическая операция OR, то придется использовать флаг [OR].
