Apache. Документация на русском


Разделы:   1    2    3      4      5    6    7    8    9    10    11    12    13    14    15    16  

Раздел 4. Руководство по перезаписи URL

Пункты:   35    36    37    38    39    40      41      42    43    44  

 <         > 
  RU            EN  

Пункт 41. Продвинутые методы использования RewriteMap

Этот документ дополняет mod_rewrite справочную документацию. Он предоставляет несколько продвинутых методов использования mod_rewrite.

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

Шардинг на основе URL для нескольких бэкэндов

Описание:

Распространенный метод распределения нагрузки на сервер или дискового пространства называется «шардинг». При использовании этого метода интерфейсный сервер будет использовать URL-адрес для последовательного «разделения» пользователей или объектов на отдельные внутренние серверы.

Решение:

Сопоставление пользователей с целевыми серверами поддерживается во внешних файлах сопоставления. Они похожи:

user1 physical_host_of_user1
user2 physical_host_of_user2
: :

Мы помещаем это в map.users-to-hosts файл. Цель состоит в том, чтобы составить карту;

/u/user1/anypath

к

http://physical_host_of_user1/u/user/anypath

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

 RewriteEngine включен
RewriteMap пользователей-хостов "txt:/path/to/map.users-to-hosts"
RewriteRule "^/u/([^/]+)/?(.*)" "http://${users-to-hosts:$1|server0}/u/$1/$2" 

См. RewriteMap документацию для более подробного обсуждения синтаксиса этой директивы.

Регенерация контента «на лету»

Описание:

Мы хотим динамически генерировать контент, но хранить его статически после создания. Это правило проверит наличие статического файла и, если его нет, создаст его. При желании статические файлы можно периодически удалять (скажем, через cron) и создавать заново по требованию.

Решение:
Это делается с помощью следующего набора правил:
 # Этот пример действителен только в контексте каталога
RewriteCond "%{REQUEST_URI}" "!-U"
RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L] 

Оператор -U определяет, является ли тестовая строка (в данном случае REQUEST_URI ) допустимым URL-адресом. Это делается через подзапрос. В случае, если этот подзапрос терпит неудачу, то есть запрошенный ресурс не существует, это правило вызывает программу CGI, /regenerate_page.cgi которая генерирует запрошенный ресурс и сохраняет его в каталоге документов, так что при следующем запросе статический копия может быть подана.

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

Балансировка нагрузки

Описание:

Мы хотим случайным образом распределить нагрузку между несколькими серверами, используя mod_rewrite.

Решение:

Для этого мы будем использовать RewriteMap и список серверов.

 RewriteEngine включен
RewriteMap lb "rnd:/path/to/serverlist.txt"
RewriteRule "^/(.*)" "http://${lb:servers}/$1" [P,L] 

serverlist.txt будет содержать список серверов:

## serverlist.txt

servers one.example.com|two.example.com|three.example.com

Если вы хотите, чтобы на один конкретный сервер приходилось больше нагрузки, чем на другие, добавьте его в список несколько раз.

Обсуждение

Apache поставляется с модулем балансировки нагрузки, mod_proxy_balancer который гораздо более гибкий и функциональный, чем все, что вы можете собрать вместе с помощью mod_rewrite.

Структурированные пользовательские каталоги

Описание:

Некоторые сайты с тысячами пользователей используют структурированный домашний каталог, т.е. каждый домашний каталог находится в подкаталоге, который начинается (например) с первого символа имени пользователя. Итак , /~larry/anypath пока есть . /home/l/larry/public_html/anypath /~waldo/anypath /home/w/waldo/public_html/anypath

Решение:

Мы используем следующий набор правил, чтобы расширить URL-адреса тильды в приведенном выше макете.

 RewriteEngine включен
RewriteRule "^/~( ([az]) [a-z0-9]+)(.*)" "/home/ $2 /$1/public_html$3" 

Перенаправление якорей

Описание:

По умолчанию перенаправление на якорь HTML не работает, потому что mod_rewrite экранирует символ # , превращая его в %23 . Это, в свою очередь, нарушает перенаправление.

Решение:

Используйте [NE] флаг на RewriteRule . NE расшифровывается как No Escape.

Обсуждение:
Этот метод, конечно же, будет работать и с другими специальными символами, которые mod_rewrite по умолчанию кодирует в URL.

Зависимая от времени перезапись

Описание:

Мы хотим использовать mod_rewrite для обслуживания различного контента в зависимости от времени суток.

Решение:

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

 RewriteEngine включен
RewriteCond "%{TIME_HOUR}%{TIME_MIN}" ">0700"
RewriteCond "%{TIME_HOUR}%{TIME_MIN}" "<1900"
RewriteRule "^foo\.html$" "foo.day.html" [L]
RewriteRule "^foo\.html$" "foo.night.html" 

Это обеспечивает содержимое foo.day.html под URL-адресом foo.html , 07:01-18:59 а в остальное время — содержимое foo.night.html .

mod_cache , промежуточные прокси-серверы и браузеры могут кэшировать ответы и отображать любую страницу за пределами настроенного временного окна. mod_expires можно использовать для управления этим эффектом. Конечно, гораздо лучше просто динамически отображать контент и настраивать его в зависимости от времени суток.

Установите переменные среды на основе частей URL

Описание:

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

Решение:

Используйте флаг [E] для установки переменной среды.

 RewriteEngine включен
Правило перезаписи "^/лошадь/(.*)" "/пони/$1" [E= перезаписано:1 ] 

Позже в вашем наборе правил вы можете проверить эту переменную среды, используя RewriteCond:

 RewriteCond "%{ENV:переписано}" "=1" 

Обратите внимание, что переменные среды не сохраняются при внешнем перенаправлении. Вы можете рассмотреть возможность использования флага [CO] для установки файла cookie.



 <         > 

Пункты:   35    36    37    38    39    40      41      42    43    44  

Рейтинг@Mail.ru