Руководство по URL преобразованиям

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

Введение в mod_rewrite

Модуль mod_rewrite имеющийся в составе Apache — это потрясающий модуль, т.е. это действительно интеллектуальный модуль предоставляющий мощные средства для URL преобразований. С ним вы можете делать почти любые URL преобразования о которых вы когда-либо мечтали. Цена, которую вы должны заплатить — принять его сложность, поскольку главный недостаток mod_rewrite , — это то, что его нелегко понять и использовать новичку. И даже эксперты Apache иногда находят новые аспекты где им может помочь mod_rewrite .

Другими словами: с mod_rewrite вы либо сами себе прострелите ногу при первом знакомстве, и никогда не будете его снова использовать, или полюбите его на всю оставшуюся жизнь из-за его мощи. Цель этого документа — дать вам несколько простых, работающих примеров, а также помочь вам избежать первого разочарования, путём показа готовых решений.

Практические решения

Здесь есть масса практических решений когда-то придуманных либо мной либо другими людьми. Чувствуйте себя свободнее изучая из этих примеров чёрную магию URL преобразований.

Работа с URL

На некоторых веб-серверах существует более одного URL для какого-либо ресурса. Обычно существуют реальные URL (которые в действительности следует использовать и распространять) и те, которые просто являются ссылками, внутренними, и т.д. Независимо от того, какой URL пользователь применил в своём запросе, в конце концов, он должен увидеть только реальный URL.

Решение:

Для всех виртуальных URL, мы делаем внешний HTTP редирект, исправляя их и в адресной строке браузера и во всех последующих запросах. В приведённом ниже наборе правил /

user заменяется реальным /u/user и исправляется отсутствующий завершающий слэш для /u/user .

Обычно DocumentRoot вебсервера в точности совпадает с URL " / ". Однако часто DocumentRoot выше по иерархии нежели чем URL "/" и в одном DocumentRoot могут располагаться несколько сайтов. Например для наших Intranet сайтов /e/www/ (главная страница WWW), /e/sww/ (главная страница для Intranet) и т.д. Сейчас из-за того что DocumentRoot остается "/" для /e/www/ мы должны обеспечить работу всех подстановок картинок и других объектов во всех последующих запросах этой области.

Решение:

Мы просто сделаем преобразование URL / в /e/www/ . С первого взгляда это кажется тривиальным, — однако в действительности, это тривиально только с mod_rewrite . Типичные старые маханизмы URL псевдонимов (что делается mod_alias и ему подобными) использовали только совпадение по префиксу. В этом случае, вы не можете делать такое преобразование, потому что DocumentRoot является префиксом для всех URL. А с mod_rewrite это действительно тривиально:

Каждый вебмастер может спеть песню о проблеме отсутствующих завершающих слэшей при использовании URL ссылающихся на каталоги. Если они отсутствуют, сервер выдает ошибку, потому что если вы пишете /

quux/foo/ сервер ищет файл foo . И поскольку этот файл является каталогом, происходит ошибка. В действительности, в большинстве случаев это исправляется само, однако, в некоторых случаях, нужно самим эмулировать этот механизм. Например, после того, как вы сделали массу сложных редиректов URL на CGI скрипты и т.д.

Решение:

Решение этой тонкой проблемы — это позволить серверу добавлять завершающий слэш автоматически. Чтобы сделать это правильно, мы должны использовать внешний редирект, для того чтобы браузер правильно запрашивал картинки и пр. В случае если бы мы сделали только внутренний редирект, это бы работало только для самой страницы каталога (страницы по-умолчанию), однако были бы проблемы при наличии любых картинок на этой странице с относительными URL, потому что браузер сделал бы запрос на вставку in-lined объекта. Например, запрос для image.gif на странице /

quux/foo/index.html без внешнего редиректа выглядел бы как /

Поэтому, для того чтобы сделать это трюк, мы пишем:

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

Мы хотим создать одинаковый и постоянный URL для всех WWW серверов в Intranet веб-кластере, т.е. все URL (конкретных локальных серверов и таким образом зависящие от сервера!) становятся, в действительности, независимыми от сервера! То что мы хотим, — так это дать пространство имен WWW постоянной независимой от сервера схеме: никакой URL не должен включать какой-либо реальный сервер. Кластер сам должет автоматически перенаправлять нас на реальный сервер.

Решение:

Первое, информация о конкретных серверах берется из (распределенных) внешних массивов содержащих информацию о том, где находятся наши пользователи, группы и ресурсы. Имеем такую форму:

Мы помещаем эти записи в файлы map.xxx-to-host . Второе, мы должны информировать все наши серверы перенаправлять URL вида

если URL не находится на каком-либо локальном сервере. Следующий набор правил делает это для нас при помощи файлов c ассоциативными массивами для преобразований (примем что server0 — это сервер, который будет использован по-умолчанию, если в массиве нет записи для какого-либо пользователя):

Масса вебмастеров просили решение для следующей ситуации: Они хотели просто перенаправить все домашние каталоги (пользователей или подсайтов) с одного сервера на другой. Такие вещи, обычно нужны при замене старого сервера новым.

Решение:

С mod_rewrite решение тривиально. На нашем старом вебсервере мы просто сделаем преобразование всех URL вида /

user/anypath в URL вида http://newserver/

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

foo/anypath имеет путь /home/f/foo/.www/anypath в то время как /

bar/anypath имеет путь /home/b/bar/.www/anypath .

Решение:

Следующий набор правил, используется для раскрытия в URL символа тильды, точно в соответствии с вышеуказанной схемой:

Это действительно очень сложный пример: серьёзная вещь, очень интенсивно использующая RewriteRules в контексте каталогов(.htaccess) для того, чтобы получить приятный вид данных и и при просмотре их через Интернет чувство того, что структура данных никогда не трогается или регулируется. Предыстория: net.sw это мой архив свободно распространяемого ПО для Unix, который я начал собирать в 1992. Для меня это одновременно и хобби и работа, потому что изучая компьютерную науку, многие годы, в свободное время, я также работал системным и сетевым администратором. Каждую неделю мне нужно некоторое количество ПО, поэтому я создал глубокую иерархию каталогов, где я сохранил эти дистрибутивы:

В июле 1996 я решил сделать этот архив общедоступным всему миру через нормальный веб-интерфейс. "Нормальный" имеется ввиду интерфейс где вы можете перемещаться прямо по иерархии этого архива. И "нормальный" значит то, что я не хотел ничего изменять внутри этой иерархии — даже не помещать некоторые CGI скрипты на её верх. Почему? Потому что вышеприведённая структура позже должна была быть доступна также и через FTP, и я не хотел наличия там каких-либо веб или CGI штук.

Решение:

Решение состоит из 2-х частей: Первое — это набор CGI скриптов которые создают все страницы на лету на всех уровнях каталогов. Я поместил их в /e/netsw/.www/ в следующем виде:

Подкаталог DATA/ содержит вышеприведенную структуру каталогов, т.е. настоящие данные net.sw и автоматически, время от времени, получает обновления через rdist . Вторая часть проблемы остается: как связать эти две структуры вместе в одно нормальное дерево URL? Мы хотим скрыть каталог DATA/ от пользователя при запуске соответствующих CGI скриптов для разных URL. Вот и решение: сначала я поместил следующее в конфигурационный файл каталога в DocumentRoot сервера для преобразования объявленного URL /net.sw/ во внутренний путь /e/netsw :

Первое правило предназначено для запросов у который отсутствует завершающий слэш! Второе правило делает нужное преобразование. И затем, в конфигурационном файле каталога /e/netsw/.www/.wwwacl , производится полное конфигурирование:

Некоторые советы по интерпретации:

1. Отметьте флаг L (последний) и отсутствие поля подстановки (' - ') в 4-й части
2. Отметьте символ ! (не) и флаг C (цепочка) в первом правиле последней части
3. Отметьте шаблон перехватывающий все запросы в последнем правиле

При переходе с веб-сервера NCSA, на более современный веб-сервер Apache, масса народу хотят чтобы, этот переход был безболезненный. Поэтому они хотят, чтобы страницы, использующие старую программу NCSA imagemap , работали и под Apache с новым модулем mod_imap . Проблема в том, что есть много гиперссылок, ссылающихся на программу imagemap через /cgi-bin/imagemap/path/to/page.map . В Apache необходимо прочитать только /path/to/page.map .

Решение:

Для всех запросов, мы используем глобальное правило удаления на лету ненужного префикса:

Иногда необходимо позволить веб-серверу искать страницы больше чем в одном каталоге. Здесь вам не помогут ни MultiViews ни другие техники.

Решение:

Мы пишем явный набор правил который ищет файлы в каталогах.

Возможно вы хотите хранить информацию о статусе между запросами и использовать URL для её кодирования. Однако не хочется, просто для получения этой информации, использовать CGI обработчик всех страниц.

Решение:

Мы используем правило для того чтобы скрывать информацию о статусе и хранить её в переменной окружения которая затем может быть использована в XSSI или CGI. Таким образом URL /foo/S=java/bar/ преобразуется в /foo/bar/ и переменная окружения STATUS устанавливается в "java".

Предположим — вы хотите предоставлять адреса www.username.host.domain.com для страниц пользователей через записи DNS типа A на той же самой машине и без каких либо виртуальных хостов на этой машине.

Решение:

Для запросов HTTP/1.0 решения нет, однако для запросов HTTP/1.1 которые содержат HTTP заголовок Host: мы можем использовать следующий набор правил для преобразования http://www.username.host.com/anypath во внутренний путь /home/username/anypath :

Мы хотим перенаправить URL домашних каталогов на другой веб-сервер www.somewhere.com когда запрашиваемый пользователь не принадлежит локальному домену ourdomain.com . Это иногда используется в контексте виртуальных хостов.

Решение:

Просто правило на перенаправление:

Типичный часто задаваемый вопрос по URL преобразованиям — это как перенаправить несуществующие запросы с сервера А на сервер B. Обычно это делается через ErrorDocument CGI-скрипты на Perl, однако с модулем mod_rewrite тоже есть решение. Заметьте однако, что это менее ресурсоёмко чем использвание ErrorDocument CGI-скрипта!

Решение:

Первое решение имеет лучшую производительность однако меньшую гибкость и меньшую защиту от ошибок:

Проблема здесь в том, что это будет работать только для страниц находяшихся внутри DocumentRoot . Тогда как вы можете добавить больше условий (например ещё и для управления домашними каталогами, и т.д.) есть лучший вариант:

Здесь используется функция опережающей проверки URL (look-ahead), присутствующая в mod_rewrite . В результате это будет работать для всех типов URL и к тому же это безопасно. Однако это снижает производительность веб-сервера, потому что для каждого запроса производится более одного внутреннего подзапроса. Поэтому, если ваш веб-сервер имеет мощный процессор, используйте этот вариант. Если это медленная машина, используйте первый или лучше ErrorDocument CGI-скрипта.

Иногда нам нужно больше контроля над URL (касаемо механизма обрезания символов) при преобразованиях. Обычно обрезающие функции URL ядра Apache также убирают и якоря, т.е. в URL вида "url#anchor". Вы не можете это непосредственно использовать при редиректах с mod_rewrite потому что функция Apache uri_escape() также обрезала бы срезаемый символ. Как мы можем сделать редирект такому URL?

Решение:

Мы должны использовать ляп в программе используя NPH-CGI скрипт который делает редирект на себя самого. Потому что здесь не делается обрезание (NPH=non-parseable headers). Сначала мы вводим новую URL scheme xredirect: в следующей строке конфигурационного файла сервера (должно быть одной из последних директив ):

Это направляет все URL начинающиеся с xredirect: через программу nph-xredirect.cgi . И эта программа выглядит примерно так :

Это предоставляет вам функции для того чтобы делать перенаправления на все URL schemes, т.е. включая те, которые, не прямо принимаются mod_rewrite . Для примера вы можете сейчас также перенаправить news:newsgroup через

Вы знаете такую классную вещь как CPAN (Comprehensive Perl Archive Network) расположенную по адресу http://www.perl.com/CPAN? Здесь работает редирект на один из нескольких FTP серверов по всему миру, на которых расположено зеркало CPAN и они приблизительно расположены рядом с местоположением запращивающего клиента. В действительности это может быть названо мультиплексирующей службой доступа к FTP. Хотя CPAN работает на CGI скриптах, как можно реализовать похожее решение с помощью mod_rewrite ?

Решение:

Для начала отметим что начиная с версии 3.0.0 mod_rewrite также может использовать "ftp:" префикс при редиректах. И второе, апроксимация местоположения может быть сделана путем ассоциативного массива преобразований RewriteMap через домен верхнего уровня, для конкретного клиента. С помощью хитрой цепочки директив мы можем использовать этот домен верхнего уровня в качестве ключа для поиска в нашем ассоциативном массиве мультеплексирования.

Когда нужно применять уловки типа содержания зависящего от времени масса вебмастеров все ещё используют CGI скрипты которые производят редиректы на специальные страницы. Как это может быть сделано через mod_rewrite ?

Решение:

Есть много переменных названных TIME_xxx для условий редиректа. В связке со специальными лексикографическими образцами для сравнения <STRING , >STRING и =STRING мы можем производить редиректы зависящие от времени:

Это выдает содержимое foo.day.html при запросе URL foo.html с 07:00 до 19:00 а в оставшееся время содержимое foo.night.html . Просто класная вещь для какой-либо странички…

Как возможно сделать URL обратно совместимыми (все ещё существующими виртуально) после миграции документа document.YYYY в документ document.XXXX , т.е. после преобразования кучи .html файлов в файлы .phtml ?

Решение:

Мы просто оставляем без изменения имя файла и проверяем существование нового расширения. Если оно существует, мы оствляем это без изменений, иначе мы перенаправляем URL в его реальное местоположение.

Управление содержанием

Предположим что мы недавно переименовали страницу bar.html в foo.html и сейчас хотим для обратной совместимости сделать доступным и старый URL. В действительности мы хотим чтобы пользователи использующие старый URL даже не узнали что страницы были переименованы.

Решение:

Мы перенаправим старый URL на новый через внутренний редирект путем следующих директив:

Снова предположим что мы недавно переименовали страницу bar.html в foo.html и хотим сейчас для обратной совместимости сделать доступным и старый URL. Однако, в этот раз мы хотимчтобы пользователи использующие старый URL узнали этот новый URL, т.е. адресная строка их браузеров также должна измениться.

Решение:

Мы используем HTTP редирект на новый URL который приведет к к изменениям в браузерах(в адресной строке) и таким образом это видят пользователи:

Иногда, по крайней мере для важных страниц верхнего уровня необходимо предоставить оптимизированное для конкретного браузера содержание, т.е. для одного нужно выдавать полную версию для последних версий Netscape, минимальную для браузеров Lynx и промежуточную для всех других.

Решение:

Мы не можем использовать content negotiation потому что браузеры не не представляют свой тип в этой форме. Вместо этого мы должны использовать HTTP заголовок "User-Agent". Следующее условие делает следующее: Если HTTP заголовок "User-Agent" начинается с "Mozilla/3", страница foo.html преобразуется в foo.NS.html и редирект прекращается. Если браузер "Lynx" или "Mozilla" версий 1 или 2 URL становится foo.20.html . Все остальные браузеры получают страницу foo.32.html . Это делается следующим набором директив:

Предположим что есть чудесные страницы на удалённых хостах и мы хотим внести их в наше пространство имен(сайт). Для FTP серверов мы бы использовали программу зеркало которая в действительности управляет обновлениями копий удалённых данных на локальной машине. Для веб-сервера мы могли бы использовать программу webcopy которая делает похожие вещи по HTTP. Однако обе эти технологии имеют один главный недостток: локальная копия актуальна всегда настолько, насколько часто мы запускаем эту программу. Было бы намного лучше если бы зеркало было не статическим должно быть полное соответствие копий, вне зависимости от частоты запуска этой программы. Вместо этого мы хотим динамическое зеркало с автоматическим обновлением данных когда это необходимо (обновление данных на удаленном сервере).

Решение:

Для обеспечения этой функции мы отобразим удаленную страницу или даже полностью удаленный сайт в наше веб-пространство используя Proxy Throughput опцию (флаг [P] ):

Это хитрый способ виртуального корпоративного (внешнего) Internet веб-сервера ( www.quux-corp.dom ), в действительности хранящем и управляющем данными расположенными на (внутреннем) Intranet веб-сервере ( www2.quux-corp.dom ) которые защищены firewall'ом. Фокус в том, что на внешнем веб-сервере мы получаем запрошенные данные на лету с внутреннего сервера.

Решение:

Сначала, мы должны убедиться что наш firewall все ещё защищает внутренний веб-сервер и что только внешнему веб-серверу разрешено получать с него данные. Для firewall'a с фильтрацией пакетов мы могли бы для примера сконфигурировать набор директив для firewall подобно этому:

Просто подправьте это чтобы соответствовать вашему синтаксису. Теперь мы можем использовать директивы mod_rewrite которые запрашивают отсутствующие данные с backend сервера через прокси:

Предположим что мы хотим сделать балансировку нагрузки для траффика www.foo.com на www[0-5].foo.com (всего 6 серверов). Как это возможно сделать?

Решение:

Есть масса возможных решений этой проблемы. Мы обсудим сначала общеизвестный основанный на DNS вариант и специфический с помощью mod_rewrite :

Циклический DNS

Самый простой способ для балансировки нагрузки это использование функции циклического DNS в DNS сервере BIND. Просто сконфигурируйте www[0-9].foo.com как обычно в своем DNS сервере с использованием записей типа A(address) т.е.

Затем, дополнительно добавьте следующую запись:

Заметьте что это кажется неправильным, однако в действительности это характерная особенность BIND и может быть использована таким способом. Однако, теперь, когда происходит разрешение www.foo.com , BIND выдает www0-www6 — однако слегка меняя/перемещая каждый раз порядок. Таким образом клиенты распределяются по разным серверам . Однако заметьте что это не блестящая схема балансировки нагрузки, потому что информация о разрешении имен DNS кэшируется другими серверами имен в сети, поэтому при первом разрешении имени www.foo.com клиентом на конкретный wwwN.foo.com , все последующие запросы также пойдут на это конкретное доменное имя wwwN.foo.com . Однако конечный результат хороший , потому что общая сумма запросов действительно распределяется на разные веб-серверы.

Научный метод балансировки нагрузки основанный на DNS это использование программы lbnamed которая может быть найдена по http://www.stanford.edu/

schemers/docs/lbnamed/lbnamed.html. Эта программа на Perl 5 в связке с вспомогательными средствами, представляет настоящую балансировку нагрузки с использованием DNS.

В этом варианте мы используем mod_rewrite и его proxy функцию. Сначала мы сопоставим www0.foo.com реальному www.foo.com при помощи простой

записи в DNS. Затем мы направляем www0.foo.com только на proxy сервер, т.е. мы настраиваем эту машину так чтобы все входные URL просто пропускались через внутренний proxy на один из 5-ти других серверов ( www1-www5 ). Для этого мы сначала введем набор директив которые взаимодействуют со скриптом lb.pl балансировки нагрузки для всех URL.

Затем мы пишем lb.pl :

Для этой задачи есть также доступные аппратные решения. Cisco имеет устройство называемое LocalDirector которое производит балансировку нагрузки на уровне TCP/IP. В действительности это некоторый вид циклического шлюза стоящего перед веб-кластером. Если у вас есть достаточно денег и вас действительно нужно высокопроизводительное решение, используйте этот вариант.

В сети есть масса отличных CGI программ. Однако их применение обычно надоедает, поэтому многие веб-мастера их не используют. Даже функция Action handler Apache'а для MIME-типов применима только тогда, когда CGI программы не нуждаются в специальных URL (в действительности PATH_INFO и QUERY_STRINGS ) для них является входом. Сначала, давайте настроим новый тип файла с расширением .scgi (для защищенных CGI) которые будут обрабатываться популярной программой cgiwrap . Проблема здесь заключается в том что для этого случая мы используем однородный URL (см. выше) и и какой-либо файл находящийся внутри домашних каталогов пользователей имеет URL /u/user/foo/bar.scgi . Однако cgiwrap требует URL в виде /

user/foo/bar.scgi/ . Следующая директива решает эту проблему:

Или предположим что у нас есть несколько полезных программ: wwwlog (отображающая access.log для поддерева URL и wwwidx (запускающая Glimpse на поддереве URL ). Мы должны предоставить область URL для этих программ чтобы они знали для какой области они должны работать. Однако обычно это ужасно, потому что они все время запрашиваются из тех областей, т.е. обычно мы бы запускали программу swwidx из /u/user/foo/ через ссылку

которая ужасна. Так как мы должны жестко связывать и местоположение области и местонахождение CGI внутри гиперссылки. В случае если нам необходимо реорганизовать эту область, мы тратим массу времени меняя различные гиперссылки.

Решение:

Решение в этом случае это сделать новый специальный формат URL который автоматически приводит к вызову нужного CGI. Настраиваем так:

Теперь гиперссылка для поиска /u/user/foo/ считывает только

который внутренне автоматически трансформируется в

То же самое приводит к вызову CGI программы для доступа к логам когда используется гиперссылка :log .

Как можно трансформировать статическую страницу foo.html в ее динамический вариант foo.cgi незаметным образом, т.е. так чтобы ни браузер ни пользователь не заметили этого.

Решение:

Мы просто перенаправляем URL на CGI-скрипт и корректируем MIME-тип так чтобы это действительно работало как CGI-скрипт. Таким образом запрос к /

quux/foo.html внутренне приведет к вызову /

Здесь рассматривается действительно вещь для посвященных: Динамически созданные однако статически обслуживаемые страницы, т.е. страницы которые должны передаваться как чисто статические (считываемые из файловой системы и затем передаваемые по запросу), однако они должны быть динамически сгенерированны веб-сервером если они отсутствуют в файловой системе. Таким образом вы можете иметь страницы сгенерированные CGI которые являются статически обслуживаемыми если только кто-либо (либо планировщик) не удалит статическое содержание. В таком случае содержание обновляется.

Решение: Это делается следующим набором директив:

Здесь, запрос к page.html приводит к внутреннему запуску соответствующего page.cgi если page.html все-ещё отсутствует или имеет нулевой размер. Фокус здесь в том что page.cgi это обычный CGI скрипт который (в дополнение к собственному STDOUT ) записывает свой вывод в файл page.html . Запустив это один раз, сервер передает данные page.html . Когда вебмастер хочет обновить содержание, он просто удаляет page.html (обычно с помощью cronjob).

Разве это было бы не здорово при создании сложной страницы если бы браузер автоматически обновлял эту страницу каждый раз когда мы создаем новую её версию в нашем редакторе? Невозможно?

Решение:

Нет! Мы просто скомбинируем опцию составного MIME веб-сервера, опцию NPH вебсервера и мощь mod_rewrite при URL преобразованиях. Сначала, мы реализуем новую опцию URL: Простое добавление :refresh к любому URL является причиной его обновления каждый раз когда происходит его обновление в файловой системе.

Теперь когда мы ссылаемся на URL

происходит внутренний вызов URL

Единственная отсутствующая часть это NPH-CGI скрипт. Хотя обычно говорится что "это остается для упражения читателю" ;-) Я также здесь приведу и этот код.

Опция <VirtualHost> Apache очень хороша и великолепно работает когда у вас есть немного виртуальных хостов. Однако когда в являетесь ISP и имеете сотни виртуальных хостов это является не лучшим выбором для такой задачи.

Решение:

Для решения этой задачи мы создадим ассоциации страниц на виртуальных хостах или даже полностью всего веб-пространства виртуальных хостов, с ресурсами в нашем пространстве имен(ресурсами основного сервера) с использованием Proxy функции (флаг [P] ):

Ограничение доступа

Как мы можем заблокировать действительно надоедливых роботов на получение страниц из специфических областей сайта? Файла /robots.txt содержащего записи "Robot Exclusion Protocol" обычно недостаточно для избавления от такого робота.

Решение:

Мы используем набор правил запрещающие доступ для роботов к URL из веб-пространства /

quux/foo/arc/ (возможно это пространство имеет очень глубокую иерархию каталогов, обход которой роботом, привел бы к очень большой нагрузке на сервер). Мы должны убедиться что запрещается доступ только для конкретного робота, т.е. просто запрет для хоста с которого работает робот недостаточен. Это, также блокировало бы доступ пользователей с этого хоста. Этого эффекта мы добьемся проверяя также информацию из HTTP заголовока User-Agent.

Предположим что мы имеем на http://www.quux-corp.de/

quux/ некоторые страницы на которых у нас есть графические изображения в формате GIF. Эти графические изображения очень хороши, поэтому другие могут помещать их на свои страницы прямо через гиперссылки. Нам не нравится эта практика потому что она добавляет бесполезный траффик для нашего сервера.

Решение:

В то время как мы не можем на 100% защитить наши картинки от вставки на другие страницы, мы, по крайней мере, можем ограничить случаи в которых браузер посылает HTTP заголовок Referer.

Как мы можем запретить доступ к нашему серверу для списка внешних хостов?

Решение:

Для Apache версий >= 1.3b6:

Для Apache версий

Как мы можем запретить конкретному хосту или даже пользователю со специального хоста использовать proxy нашего Apache?

Решение:

Сначала мы должны убедиться что вызов mod_rewrite ниже(!) чем вызов mod_proxy в конфигурационном файле при сборке Apache. Таким образом он вызывается перед mod_proxy . Затем мы настраиваем следующий запрет зависящий от хоста…

…и следующий запрет зависящий от пользователя с конкретного хоста:

Иногда необходима очень специфичная аутенфикация, например аутенфикация проверяющая принадлежность к списку особых пользователей. Только они могут иметь доступ к какому-либо ресурсу и при этом не должно быть окна запроса предлагающего ввести данные для аутенфикации (которое появляется при использовании базовой аутенфикации через mod_auth_basic ).

Решение:

Мы используем список условий для для исключения всех кроме разрешенных лиц:

Как мы можем запрограммировать гибкий отражатель URL который работает полагаясь на HTTP заголовок "Referer" и может быть настроен на такое количество ссылающихся страниц, какое мы хотим?

Решение:

Используйте следующий, действительно хитроумный набор правил…

… в связке с соответствующим ассоциативным массивом преобразований:

Это автоматически перенаправит запрос назад на ссылающуюся страницу (когда " - " используется в качестве значения в массиве) или на конкретный URL (когда в массиве в качестве значения указан какой-либо URL).

Другое

Часто задаваемый вопрос: Как мы можем решить проблему FOO/BAR/QUUX/и т.д.? Здесь кажется нет решения с использованием mod_rewrite …

Решение:

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

Это только демонстрационный пример и тут просто все URL /

quux/foo/. преобразуются в /

quux/bar/. . В действительности вы можете запрограммировать здесь все что угодно. Примите во внимание, что хотя такие массивы и могут быть использованы, в том числе и обычным пользователем, однако определять их может только системный администратор.