-÷итатник

Ѕез заголовка - (0)

* http://s58.radikal.ru/i161/1008/c9/ce9f614a3192.jpg http://s45.radikal.ru/i107/1008/25/edd5b...

Ѕез заголовка - (0)

–ефлексологи€ - о чем говор€т ступни —хематическа€ проекци€ органов на ступне   »з книги...

Ѕез заголовка - (0)

ѕисьмо оператору сотовой св€зи ћой уважемый, оператор сотовой св€зи! ’очу ¬ам сказать, ч...

Ѕез заголовка - (0)

»нтернет-математика  ак же забавно порой бывает... » ведь правда же...

—тереотипна€ карта ≈вропы - (0)

—тереотипна€ карта ≈вропы “оже довольно интересна€ карта, наполненна€ стереотипами чуть более...

 -неизвестно

јнкета в сервисе знакомств
»м€ в анкете: ƒмиитрий
»щу: девушку
÷ель знакомства: ƒружба, Ћюбовь, Ѕрак

 -Friends for Love


“олько дл€ студентов! Ќе веришь?

–ейтинг игроков LiveInternet.ru

1. –Ь–∞—А–≥–Њ—А–Є—В–∞13 - 654 ( +17)
2. –ѓ—Б–µ–љ–Њ–Ї! - 608
3. –°—Г–∞–љ—Н - 556 ( +19)
4. –Я–∞—В–Њ–Ї–∞ - 532
5. –Ь–Є—А—Н–є–љ - 458 ( +6)

ћаксимальный выигрыш игроков LiveInternet.ru

1. InO_o - 84 600 Ћир (20:21 28.08.2008)
2. vikysik_love - 65 089 Ћир (13:13 23.08.2008)
3. –ѓ—Б–µ–љ–Њ–Ї! - 57 240 Ћир (15:57 10.08.2008)
4. nuns - 55 800 Ћир (22:35 07.09.2008)
5. vierassi - 46 420 Ћир (20:38 24.10.2008)

ћой рейтинг

не сыграно ни одной игры.

ћой максимальный выигрыш

не сыграно ни одной игры.
ƒанные обновл€ютс€ раз в день при входе в игру

 -я - фотограф

ћосква 2010


0 фотографий

 -ћаршруты ћосквы

 -—тена

 -ѕрофайлер

—писок анкет пользовател€ (1)

 -ѕодписка по e-mail

 
ѕолучать сообщени€ дневника на почту.

 -ѕоиск по дневнику

люди, музыка, видео, фото
ѕоиск сообщений в dimaker

 -—татистика

—татистика LiveInternet.ru: показано количество хитов и посетителей
—оздан: 01.09.2005
«аписей: 2976
 омментариев: 1923
Ќаписано: 5487

ћодуль mod_rewrite - URL преобразований сервера Arache

ƒневник

—уббота, 24 Ќо€бр€ 2007 г. 01:40 + в цитатник
ћодуль mod_rewrite - URL преобразований сервера Arache

ћодуль mod_rewrite имеющийс€ в составе Apache Ч это потр€сающий модуль, т.е. это действительно интеллектуальный модуль предоставл€ющий мощные средства дл€ URL преобразований. — ним вы можете делать почти все типы URL преобразований о которых вы когда-либо мечтали. ÷ена, которую вы должны заплатить Ч прин€ть его сложность, поскольку главный недостаток mod_rewrite, Ч это то, что его нелегко пон€ть и использовать новичку. » даже эксперты Apache иногда наход€т новые аспекты где им может помочь mod_rewrite.

ƒанный модуль представл€ет собой основанный на правилах механизм (синтаксический анализатор с применением регул€рных выражений), выполн€ющий URL преобразовани€ на лету. ћодуль поддерживает неограниченное количество правил и св€занных с каждым правилом условий, реализу€ действительно гибкий и мощный механизм управлени€ URL. URL преобразовани€ могут использовать разные источники данных, например переменные сервера, переменные окружени€, HTTP заголовки, врем€ и даже запросы к внешним базам данных в разных форматах, Ч дл€ получени€ URL нужного вам вида.

Ётот модуль оперирует с полными URL (включа€ path-info) и в контексте сервера (httpd.conf) и в контексте каталога (.htaccess) и даже может генерировать части строки запроса в качестве результата. ѕреобразованный результат может приводить к внутренней обработке, внешнему перенаправлению запроса или даже к прохождению через внутренний прокси модуль.

Ќо, вс€ эта функциональность и гибкость имеет свой недостаток Ч сложность. ѕоэтому, не думайте что вы поймете работу модул€ за один день.

Ётот модуль был придуман и написан в апреле 1996 и эксклюзивно подарен The Apache Group в июле 1997

¬нутренние процессы

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

‘азы API

ƒл€ начала, нужно просто пон€ть, что обработку какого-либо HTTP запроса, сервер Apache делает в фазах. ѕерехватчик этих фаз обеспечиваетс€ Apache API. Mod_rewrite использует 2 из этих перехватчиков: трансл€тор из URL в им€ файла используемый после считывани€ HTTP запроса, но до начала какой-либо авторизации и перехватчик адресной прив€зки начинающий работать после фаз авторизации и считывани€ конфигурационных файлов каталога (.htaccess), но до активизации обработчика содержани€.

ѕоэтому, после поступлени€ запроса и определени€ Apache'ем соответствующего сервера (или виртуального сервера) механизм преобразований начинает обработку всех директив mod_rewrite из конфигурационного файла сервера в фазе трансл€ции из URL в им€ файла. Ќесколько шагов спуст€, когда наход€тс€ каталоги с конечными данными, конфигурационные директивы mod_rewrite запускаютс€ в фазе адресной прив€зки. ¬ обоих этих ситуаци€х mod_rewrite преобразует URL, либо в новые URL, либо в имена файлов, хот€ между ними нет объективных различий. ѕри создании API, не предполагалось его использование таким образом, однако что касаетс€ Apache 1.x это единственный возможный способ работы mod_rewrite. „тобы внести больше €сности запомните 2 вещи:

’от€ mod_rewrite и преобразует URL в URL, URL в имена файлов и даже имена файлов в имена файлов, в насто€щий момент API предоставл€ет только перехватчик дл€ преобразовани€ URL в им€ файла. ¬о 2-м Apache будут добавлены 2 отсутствующих перехватчика дл€ того, чтобы сделать этот процесс более логичным. ќднако это никак не вли€ет на пользовател€, Ч просто этот факт надо запомнить: Apache в перехватчике URL им€ файла делает больше нежели чем это подразумеваетс€ в API.

Ѕесподобный mod_rewrite проделывает URL преобразовани€ и в контексте каталога, т.е. в файлах .htaccess, хот€ они и обрабатываютс€ намного позже трансл€ции URL в имена файлов. “ак должно быть, потому что .htaccess файлы наход€тс€ в файловой системе, и поэтому обработка уже дошла до этой стадии. ƒругими словами: —огласно фазам API, Ч в это врем€ уже слишком поздно управл€ть URL. „тобы решить проблему курицы и €йца, mod_rewrite использует хитрость: когда вы манипулируете URL/именем файла в контексте каталога, mod_rewrite сначала преобразует им€ файла обратно, к соответствующему ему URL (что обычно невозможно, однако, смотрите директиву RewriteBase чуть ниже, где написано как это сделать) и затем инициирует новый внутренний подзапрос с этим новым URL. Ёто перезапускает процесс обработки фаз API.

» снова mod_rewrite упорно пытаетс€ сделать этот сложный шаг полностью прозрачным дл€ пользовател€, однако здесь вам следует запомнить: в то врем€ как манипул€ции с URL контексте сервера действительно быстры и эффективны, манипул€ции в контексте каталога медленны и неэффективны из-за проблемы курицы и €йца. ќднако, с другой стороны это единственный возможный путь работы mod_rewrite (локально ограниченный) дл€ URL преобразований, доступный обычному пользователю.

Ќе забывайте 2 эти вещи!

ќбработка наборов правил

«апуска€сь в этих двух фазах API, mod_rewrite считывает конфигурационные наборы правил из своей конфигурационной структуры (создаваемой либо один раз при запуске сервера, Ч дл€ контекста сервера, либо каждый раз при обходе €дром Apache каталогов, Ч дл€ контекста каталога). «атем запускаетс€ механизм URL преобразований с уже имеющимс€ набором правил (правило(а) вместе со своими услови€ми). ‘ункционирование самого механизма преобразований в точности одинаково дл€ обоих контекстов конфигурации. –азличаютс€ только конечные результы обработки.

ѕор€док правил в наборе важен потому что механизм преобразований обрабатывает их в специальном (и не очень очевидном) пор€дке. ¬от это правило: ћеханизм преобразований просматривает весь набор правил строчка за строчкой (RewriteRule директивы) и когда находитс€ соответствие конкретному правилу производитс€ просмотр соответствующих этому правилу условий (RewriteCond директивы). ѕо историческим причинам услови€ наход€тс€ перед правилами, и поэтому последовательность выполнени€ команд немного более длинна€.

—начала URL сравниваетс€ с Ўаблон дл€ каждого из правил. ѕри неудаче mod_rewrite сразу же останавливает обработку этого правила и продолжает работу, использу€ следующее правило. ≈сли Ўаблон совпадает, mod_rewrite ищет соответствующие этому правилу услови€. ≈сли их нет, он просто замен€ет URL новой величиной полученной из строки ѕодстановка и продолжает дальше обрабатывать правила. ќднако если существуют услови€, запускаетс€ внутренний цикл дл€ их обработки в том пор€дке в котором они перечислены. ƒл€ условий эта логика друга€: мы не сравниваем URL на соответствие какому-либо шаблону. ¬место этого мы сначала создаем строку —равниваема€—трока дополн€€ еЄ переменными, обратными ссылками, запросами в базы данных, и т.д. и затем пытаемс€ провер€ть на соответствие с ”словие. ≈сли шаблон не соответствует, весь набор условий и соответствующих правил считаетс€ несоответствующим условию. ≈сли есть соответствие шаблону, в этом случае производитс€ обработка следующего услови€ до тех пор пока они будут не исчерпаны. ≈сли все услови€ совпадают, процесс обработки продолжаетс€ с использованием дл€ URL подстановки данных из пол€ ѕодстановка.

Ёкранирование специальных символов

„то касаетс€ Apache 1.3.20, специальные символы в —равниваема€—трока и ѕодстановка строках могут быть экранированы (имеетс€ ввиду, отношение к ним как к нормальным символам без их обычного специального значени€) путем предшествующего им символа слеша (''). ƒругими словами, вы можете включать символ доллара в строку ѕодстановка использу€ '\$'; это не позволит mod_rewrite относитьс€ к нему как к обратной ссылке.

Ќаличие обратных св€зей в регул€рных выражени€х

«десь нужно запомнить одну важную вещь: ¬с€кий раз, когда вы используете круглые скобки в Ўаблон или в одном из ”словие, создаютс€ внутренние обратные св€зи которые могут быть использованы со строками $N и %N (см. ниже). ќни полезны при создании строк ѕодстановка и —равниваема€—трока. –исунок 2 показывает в какие места при дополнении (строк ѕодстановка и —равниваема€—трока) перемещаютс€ обратные св€зи.

–исунок 2: ƒвижение обратных св€зей в правиле.

»так, Ч это был неподъЄмный курс по внутренним механизмам mod_rewrite, но он вам сильно поможет при дальнейшем чтении документации по данному модулю.

ѕеременные окружени€

Ётот модуль отслеживает две дополнительные (нестандартные) переменные окружени€ CGI/SSI называемые SCRIPT_URL и SCRIPT_URI. ќни содержат логическое представление текущего ресурса, т.е. то, каким вы видите это в адресной строке браузера, в то врем€ как стандартные переменные CGI/SSI SCRIPT_NAME и SCRIPT_FILENAME содержат физическое или системное представление.

«амечание: эти переменные содержат URI/URL в том виде, в котором они были первоначально запрошены, т.е., перед тем как были сделаные какие-либо преобразовани€. Ёто важно, ибо процесс преобразовани€ в первую очередь используетс€ дл€ преобразовани€ логических URL в физические пути к конкретным файлам.

ѕример

SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html

SCRIPT_FILENAME=/u/rse/.www/index.html

SCRIPT_URL=/u/rse/

SCRIPT_URI=http://en1.engelschall.com/u/rse/
–убрики:  —айт

ћетки:  

 —траницы: [1]