Rewritecond request filename


Директива RewriteCond

Описание: Определяет условие при котором происходит преобразование
Синтаксис: RewriteCond СравниваемаяСтрокаУсловие
Значение по умолчанию: None
Контекст: server configvirtual hostdirectory.htaccess
Разрешение: FileInfo
Статус: Расширение
Модуль: mod_rewrite

Директива RewriteCond определяет условия для какого-либо правила. Перед директивой RewriteRule располагаются одна или несколько директив RewriteCond. Следующее за ними правило преобразования используется только тогда, когда URI соответствует условиям этой директивы и также условиям этих дополительных директив.

СравниваемаяСтрока строка которая может содержать следующие дополнительные конструкции вдополении к простому тексту:


  • RewriteRule обратные_связи: Это обратные связи вида

    $N

    (0 <= N<= 9) предоставляющие доступ к сгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteRule (единственной, следующей сразу затекущим набором директив RewriteCond).

  • RewriteCond обратные_связи: Это обратные связи вида

    %N

    (1 <= N<= 9) предоставляющие доступ ксгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteCond втекущем наборе условий.

  • RewriteMap расширения: Это расширения вида

    ${mapname:key|default}

    Смотрите документацию по RewriteMap для получения более подробной информации.

  • Переменные сервера: Это переменные вида

    %{NAME_OF_VARIABLE}

    где NAME_OF_VARIABLE может быть строкой взятой из следующего списка:


    HTTP заголовки: соединение & запрос:
    HTTP_USER_AGENT
    HTTP_REFERER
    HTTP_COOKIE
    HTTP_FORWARDED
    HTTP_HOST
    HTTP_PROXY_CONNECTION
    HTTP_ACCEPT
    REMOTE_ADDR
    REMOTE_HOST
    REMOTE_USER
    REMOTE_IDENT
    REQUEST_METHOD
    SCRIPT_FILENAME
    PATH_INFO
    QUERY_STRING
    AUTH_TYPE
    внутренние сервера: системные: специальные:
    DOCUMENT_ROOT
    SERVER_ADMIN
    SERVER_NAME
    SERVER_ADDR
    SERVER_PORT
    SERVER_PROTOCOL
    SERVER_SOFTWARE
    TIME_YEAR
    TIME_MON
    TIME_DAY
    TIME_HOUR
    TIME_MIN
    TIME_SEC
    TIME_WDAY
    TIME
    API_VERSION
    THE_REQUEST
    REQUEST_URI
    REQUEST_FILENAME
    IS_SUBREQ

    Эти переменные полностью соответствуют названным похожим образом MIME-заголовкам HTTP, и переменным сервера Apache или полям struct tm систем Unix. Большинство из них документрованны в других местах руководства или в спецификации CGI. Те, что являются для mod_rewrite специальными включают:

    IS_SUBREQ

    Будет содержать текст если запрос выполняется в текущий момент как подзапрос, в другом случае. Подзапросы могут быть сгенерированны модулями которым нужно иметь дело с дополнительными файлами или URI для того чтобы выполнить собственные задачи.
    API_VERSION
    Это версия API модуля Apache (внутренний интерфейс между сервером и модулем) в текущей сборке сервера, что определено в include/ap_mmn.h. API версия модуля соответствует используемой версии Apache (для версии Apache 1.3.14, к примеру это 19990320:10), однако это в основном интересно авторам модулей.
    THE_REQUEST
    Полная строка HTTP запроса отправленная браузером серверу (т.е., <GET /index.html HTTP/1.1>). Она не включает какие-либо дополнительные заголовки отправляемые браузером.
    REQUEST_URI
    Ресурс, запрошенный встроке HTTP запроса. (В примере выше, это было бы .)
    REQUEST_FILENAME
    Полный путь вфайловой системе сервера кфайлу или скрипту соответствующим этому запросу.

Специальные примечания:

  1. Переменные SCRIPT_FILENAME и REQUEST_FILENAME содержат одинаковые значения, т.е., значение поля filename внутренней структуры request_rec сервера Apache. Первое имя это просто широко известное имя переменной CGI в то время как второе это постоянная копия REQUEST_URI (содержащая значение поля uri структуры request_rec).

  2. Есть специальный формат: %{ENV:переменная} где переменная может быть любой переменной окружения. Это ищется вовнутренних структурах Apache и(если там нет) спомощью вызова getenv() из процесса Apache сервера.
  3. Есть специальный формат: %{HTTP:заголовок} где заголовок может быть любым именем HTTP MIME-заголовка. Это ищется вHTTP запросе. Пример: %{HTTP:Proxy-Connection} значение HTTP заголовка Proxy-Connection:.
  4. Есть специальный формат %{LA-U:переменная} опережающих запросов которые производятся внутренним (основанном наURL) подзапросом для определения конечного значения переменной. Используйте это когда вы хотите использовать переменную для преобразований, которая реально определяется позднее, в какой-либо фазе API, и таким образом недоступна на данном этапе. Для примера когда выхотите преобразовать соответственно переменной REMOTE_USER из контекста сервера (файл httpd.conf

    ) вы должны использовать %{LA-U:REMOTE_USER} потому что эта переменная устанавливается в фазах авторизации которые идут после фазы трансляции URL в которой иработает mod_rewrite. Сдругой стороны, попричине реализации работы mod_rewrite в контексте каталога (файл .htaccess) через Fixup фазу API и из-за того, фазы авторизации идут до этой фазы, вы просто можете там использовать %{REMOTE_USER}.
  5. Есть специальный формат: %{LA-F:переменная} который создает внутренний (основанный на имени файла) подзапрос для определения конечного значения переменной. В основном это тоже самое что и формат LA-U приведенный выше.

Условие это шаблон условия, т.е., какое-либо регулярное выражение применяемое к текущему экземпляру СравниваемаяСтрока, т.е., СравниваемаяСтрока просматривается на поиск соответствия Условие.

Помните: Условие это perl совместимое регулярное выражение с некоторыми дополнениями:

  1. Вы можете предварять строку шаблона префиксом ! (восклицательный знак) для указания несоответствия шаблону.
  2. Есть некоторые специальные варианты Условие. Вместо обычных строк с регулярными выражениями можно также использовать один из следующих вариантов:

    • <Условие (лексически меньше)
      Условие считается простой строкой и лексически сравнивается с СравниваемаяСтрока. Истинно если СравниваемаяСтрока лексически меньше чем Условие.
    • >Условие (лексически больше)
      Условие считается простой строкой и лексически сравнивается с СравниваемаяСтрока. Истинно если СравниваемаяСтрока лексически больше чем Условие.
    • =Условие (лексически равно)
      Условие считается простой строкой и лексически сравнивается с СравниваемаяСтрока. Истинно если СравниваемаяСтрока лексически равно Условие, т.е. эти две строки полностью одинаковы (символ всимвол). Если Условие имеет вид "" (два знака дюйма идущих подряд) это сравнивает СравниваемаяСтрока с пустой строкой.
    • -d (является ли каталогом)
      СравниваемаяСтрока считается путем, проверяется существование этого пути и то что этот путь является каталогом.
    • -f (является ли обычным файлом)
      СравниваемаяСтрока считается путем, проверяется существование этого пути иточто этот путь является обычным файлом.
    • -s (является лиобычным файлом с ненулевым размером)
      СравниваемаяСтрока считается путем, проверяется существование этого пути и то что этот путь является обычным файлом, размер которого больше нуля.

    • -l (является лисимволической ссылкой)
      СравниваемаяСтрока считается путем, проверяется существование этого пути и то что этот путь является символической ссылкой.
    • -F (проверка существования файла через подзапрос)
      Проверяет через все списки контроля доступа сервера, существующие в настоящий момент, является ли СравниваемаяСтрока существующим файлом, доступным по этому пути. Для этой проверки используется внутренний подзапрос, поэтому используйте эту опцию с осторожностью — это отрицательно сказывается напроизводительности сервера!
    • -U (проверка существования URL через подзапрос)
      Проверяет через все списки контроля доступа сервера, существующие в настоящий момент, является ли СравниваемаяСтрока существующим URL, доступным по этому пути. Для этой проверки используется внутренний подзапрос, поэтому используйте эту опцию с осторожностью — это отрицательно сказывается напроизводительности сервера!

    Замечание

    Все эти проверки также могут быть предварены префиксом восклицательный знак (‘!’) для инвертирования их значения.

Дополнительно вы можете устанавливать специальные флаги для Условие добавляя

[flags]

третьим аргументом в директиву RewriteCond. Flags список следующих флагов разделенных запятыми:


  • nocase|NC (регистронезависимо)
    Регистр не имеет значения, т.е., нет различий между ‘A-Z’ и’a-z’ как в дополнении СравниваемаяСтрока так и Условие. Этот флаг эффективен только для сравнений между СравниваемаяСтрока и Условие. Он не работает при проверках в файловой системе и в подзапросах.
  • ornext|OR (либо следующее условие)
    Используйте для комбинирования условий в правилах OR вместо AND. Типичный пример:
    RewriteCond %{REMOTE_HOST} ^host1.* [OR] RewriteCond %{REMOTE_HOST} ^host2.* [OR] RewriteCond %{REMOTE_HOST} ^host3.* RewriteRule ...some special stuff for any of these hosts... 

    Без этого флага вы должны были бы написать это условие/правило три раза.

htmlweb.ru

Чтобы объяснить это поведение, нам нужно сделать некоторые предположения о вашей файловой системе, а под «работой» вы подразумеваете, что файл обслуживается (вы не видите список каталогов)…

Файл .htaccess находится в корневом каталоге документа, а /mywebsite — физический каталог, содержащий файл index.php (или некоторый документ DirectoryIndex). В корне документа нет файла index.php


. Другими словами:

example.com/  .htaccess  mywebsite/  index.php 

В этом случае, когда вы запрашиваете example.com/mywebsite/, происходит следующее:

RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php 

/mywebsite/ — физический каталог, поэтому первое условие терпит неудачу и RewriteRule не обрабатывается.

mod_dir затем выполняет поиск DirectoryIndex, находит index.php и файл .htaccess перерабатывается. Это теперь отображается в физическом файле, поэтому второе условие терпит неудачу и RewriteRule не обрабатывается.

Конечным результатом является запрос example.com/mywebsite/index.php. Так же, как если бы не было файла .htaccess вообще.

RewriteRule ^(.*)$ index.php 

Однако в этом случае условий нет. RewriteRule обрабатывается безоговорочно и внутренне перезаписывает запрос example.com/index.php (строго говоря, <filesystem-path-to-document-root>/index.php), так как там находится файл .htaccess.

Однако в корне документа нет файла index.php; следовательно, 404.

Почему RewriteCond %{REQUEST_FILENAME} !-d


обязательный?

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

Условие !-f обычно более важно, поскольку вы часто не хотите, чтобы физические файлы обрабатывались передним контроллером. Это требуется, если вы хотите использовать статические ресурсы (например, CSS, JavaScript и изображения) из той же области в файловой системе. Однако вы можете опустить эту директиву, если хотите контролировать доступ к некоторым физическим файлам (возможно, раздел «загрузка» ) через передний контроллер.

qaru.site

Рассмотрим пример этих директив, взятый из файла .htaccess для некоторой cms. В качестве справочника будем смотреть на официальное описание работы mod_rewrite.

Options +FollowSymlinks
RewriteEngine On

RewriteCond %{HTTP_HOST} ^example.ru$ [NC]
RewriteRule ^(.*)$ http://www.example.ru/$1 [L,R=301]

RewriteBase /

RewriteRule ^.htaccess$ [F]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.(.*)$

RewriteCond %{REQUEST_URI} (.*)/$
RewriteRule ^(.*)/?$ /?$1&%{QUERY_STRING}

RewriteCond %{REQUEST_URI} !.(.*)$
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ /$1/ [R=301]

Options +FollowSymlinks переопределяет поведение сервера для символических ссылок. Обычно символические ссылки уже разрешены в файле конфигурации сервера httpd.conf, но если это не так, то эта директива необходима для работы mod_rewrite.

Второй строчкой идет «RewriteEngine On». Когда она включена все дальнейшие директивы тоже выполняются, установка ее в off отключает выполнение всех нижележащих директив. RewriteEngine не наследуется и поэтому ее надо включать во всех файлах httaccess, в которых имеются директивы mod_rewrite.

Следующие две директивы перенаправляют запрос с нашему сайту (example.ru), набранный без префикса «www» к нашему же сайту, но с префиксом «www». Флаг [L] в RewriteRule приводит к отказу от обработки следующих RewriteRule, а флаг [R=301] делает внешнее перенаправление с помощью 301 редиректа. «http://www.example.ru» явно указывает префикс перенаправления.

Далее в нашем примере идет директива «RewriteBase /». Такая установка отменяет базу перенаправления по умолчанию — физического адреса директории, где лежит файл htaccess. Tак как физический адрес обычно не совпадает с URL, то она обычно необходима.

Следующая одиночная директива «RewriteRule ^.htaccess$ [F]» запрещает доступ к файлу, совпадающему с регулярным выражением «^.htaccess$» с помощью флага [F]. Смысл регулярного выражения в скобках: ^ — начало строки; . — символ точка, так как точка является специальным символом, то его экранируют; $ — конец строки.

Следующая цепочка из трех директив «RewriteCond» отменяет перенаправление, если в запросе набран путь к файлу или директории, или путь содержит точку.

Следующая директива «RewriteCond %{REQUEST_URI} (.*)/$» разрешает перенаправление для адресов, оканчивающихся на «/».

Следующая за ними «RewriteRule ^(.*)/?$ /?$1&%{QUERY_STRING}» помещает путь обращения, удовлетворяющий перечисленным условиям в строку запроса. То есть, если будет набран запрос «http://www.example.ru/15/?m=1», что относительно корня сайта равно «15/?m=1», мы получим «/?15&m=1».
В этой директиве представлена хитрая игра знаком вопроса. В первом случае он является специальным символом в регулярном выражении и означает «один или ноль символов». Во втором появлении он означает начало строки запроса.

Последние три директивы перенаправляют все запросы, не имеющие точки внутри и не оканчивающиеся на «/» на тот же URL, но с «/» на конце. Так как редирект здесь также внешний, то цепочка перенаправлений будет выполнена вновь уже для этого URL.
Вообще говоря, это не совсем правильно и здесь правильнее было бы явно указать вместо слэша http://www.example.ru/ — RewriteRule ^(.*)$ http://www.example.ru/$1/ [R=301].

www.design-sites.ru

Псевдостатические ссылки

В настоящее время, использование модуля mod_rewrite является неким стандартом обработки статических ссылок в движках систем управления сайтом. Для выполнения преобразований запроса сначала производится замена ссылки скриптом, содержащим параметры запроса, а в дальнейшем — обратная замена. Задача модуля, исходя из заданных правил, рассмотреть url и откорректировать первоначальную ссылку на документ скрипта и настройки вызова. В итоге данный скрипт (или их комбинация) получает вызов от веб-сервера в стандартном для скриптов формате, в то время как в браузерах ссылка остается неизменной и как таковые переадресации отсутствуют. Допустим, скрипт фотогалереи сайта допускает использование параметра идентификатора раздел id и раздел page. В ссылках навигации в это время, значение параметра представляется через дефис и добавляется html-расширение. Ссылка для второй страницы следующая: /galery-p2.html, а чтобы получить эту страницу, необходимо обратиться к index.php с условием: id=galery&page=2.

Иногда используют другую методику разбора псевдостатики, если ссылки анализирует «основной» скрипт движка.

Вышеуказанное правило демонстрирует, как любое обращение к файлу попадает к скрипту index.php, а он разбирает и обрабатывает запрашиваемую ссылку.

Запросы и их переадресация

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

Воплощение переадресации домена на деле (.htaccess при замене домена, склейка)

Чтобы совместить или «склеить» домены, используется следующая подборка правил:

Данный метод самый приемлемый и в большинстве ситуаций, лучше остановиться на нем. Этот способ преобразования показывает «если имя указанного домена НЕ имеет в начале — newdomain.ru». Таким образом, группа правил привязывается именно к этому домену, в который направляются все запросы. Какое количество и какие именно домены служат алиасами – не имеет значения, все запросы к ним направляют к одному домену. Преобразовывающее правило предлагает «внутренний» URL, переадресовывая посетителя на этот же адрес, находясь внутри домена.

При необходимости перенаправить запрос olddomain.ru в newdomain.ru, сохраняя внутренний URL, проходит обработка любой страницы с переадресацией по первичному адресу в другом домене. Данный подход используется в случаях перемещения сайта на другой домен и хостинг, позволяет сохранить все категории внутреннего дерева. В строке RewriteCond задается метод преобразования. Корень сайта и его директория назначены базой преобразования (RewriteBase) и вся относительная ссылка от корневой папки ресурса, исключая символ корня / воспринимается правилом RewriteRule, как входной шаблон. Этот случай показывает, как берется любая цепочка разных символов, которую включает url и заменяет ее символами $1. Переадресация запроса на уникальный адрес Apache проводится, а после публикуется в заголовке HTTP статус 301 («Moved Permanently»), в поле Location: заголовка помещает сформированный адрес. В итоге, запрос http://www.olddomain.ru/services/page1.php?id=518 переадресуется на адрес http://newdomain.ru/services/page1.php?id=518

Доменное имя канонической формы: mod_rewrite (.htaccess)

Следующая частая ситуация – перелинковка для подтверждения канонической формы доменного имени (с www или без www). Получается, для отображения домена www.site.ru необходима следующая группа правил:

Это такой случай, где условие преобразования в точности говорит «когда имя хоста НЕ начинается с www». Выполняя данное требование (если запрошен http://site.ru/page1.html), срабатывает правило, которое предоставляет внутренний url для шаблона и перенаправит по аналогичному адресу другого домена с www. Когда мастера желают убрать www в адресе ресурса, применяется следующий код в .htaccess:

В этом случае, site.ru – и есть само доменное имя Вашего ресурса. Условие с переменной HTTP_HOST (доменное имя) сопоставляется с необходимым (!^site.ru [NC]), согласно выполнению условия и если HTTP_HOST не приравнивается к Вашему домену (например, site.ru, тогда и возможна переадресация на сам домен site.ru.

URL каталога в канонической форме

Как сделать переадресацию с Url’а без слеша на Url со слешем? (например, site1.ru/page ? site1.ru/page) Метод довольно простой:

Некорректные роботы под запретом

Поисковые системы индексируют всю доступную информацию, поэтому не рассматривает вариант скрытия папок или документов. Все мы знаем об увеличении спамерских ботов, их количество растет с каждым днем. Большинство из них не рассматривают стандарты исключений и даже не обращаются к файлу robots.txt. Однаако, можно зафиксировать их имя (User-agent). Преимуществ данного робота не обнаружить, а нагрузки на сервер очевидны. Чтобы сделать недоступным ресурс для такого некорректного бота, рекомендовано пользоваться следующим правилом:

Условие проверяет наличие в переменной окружения HTTP_USER_AGENT строки Vasin-Robot. Если такая строка обнаружена, сработает правило преобразования. Оно очень простое: по любому запросу ничего не пеобразовывать, выдать HTTP-заголовок с кодом статуса «403 Forbidden». Васин робот получит этот заголовок вместо любого запрошенного документа, никакие другие действия выполняться не будут. Если условие строки Someone’s-Robot обусловлено переменной окружения HTTP_USER_AGENT, правило преобразования вступает в силу. Данное правило не сложное: при поступлении любого запроса выдается HTTP-заголовок с кодом статуса «403 Forbidden». И на все запросы Someone’s-Robot получит этот заголовок вместо нужного ему документа, а другие действия выполнятся не будут.

Правила и их порядок

Сначала может показаться, что очередность следования правилам mod_rewrite ни к чему. Настройки и каждое правило считываются в порядке написания. Когда возникает первое совпадение URL с настройками шаблонных правил, запускается обработка запроса по данному правилу. Исходя из вышеизложенного, отметим, что все правила стоит применять как одно целое и соблюдать четкий принцип следования: -правило блокировки и внесения запрета -правило перенаправления -правило замены динамического URL При нарушении порядка правил возможны сбои в работе скриптов. Это относится и к правилу блокировки и внесения запрета. Только соблюдая очередность, можно получить удовлетворительный результат работы скриптов.

www.it-puzzle.ru

Для того что бы склеить веб-домен

Для того что бы избавиться раз и навсегда от www, и склеить домен без www (http://htaccess.net.ru т.е. в адресной строке больше ни когда не будет домена с www — http://www.htaccess.net.ru), нужно использовать следующий код:

Htaccess перенаправление — редиректом 301 — «документ перемещен навсегда» с легкостью решает эту задачу.

Что бы сделать наоборот — склеить сайт без www (http://htaccess.net.ru), с www (http://www.htaccess.net.ru — т.е. использовать в урлах только его) необходимо использовать следующий код .htaccess размещенный в корне домена:


Выставляем на суд общественности присланную нам конфигурацию — настройку .htaccess «/» — слеша, с подстановкой его в конце и так же с принудительным его убираем.

Убрать слэш в конце url, .htaccess убираем слэш в конце строки урла — ссылки


Добавить слэш в конце url, htaccess добавляем слэш в конце строки урла — ссылки


Посетители веб-сайта авторизуются при помощи стандартной авторизации ( AuthType BasicAuth ). Необходимо по ссылке / home показывать содержимое их домашних каталогов:


Есть два каталога /home/net/storag1 и /home/net/storage2, в которых нужно искать запрашиваемые файлы:


Закрыть доступ к веб-сайту в рабочее время:


Перенаправление пользователя с определенным юзер-агентом — браузером на определенную версию сайта (например, при заходе с айфона — перенаправлять направить пользователя на поддомен с специальной мобильной версией сайта:

Или же перенаправлять не на поддомен, а в специальный каталог сайта /iPhone-versia/, код .htaccess следующий:

В данном случае мы применили глобальную переменную HTTP заголовка «User-Agent», который отправляют все браузеры при заходе на любой ресурс (этот заголовок в ряде браузером можно изменять на любое значение, но в 99% это ни кто не делает, так как это снижает комфорт серфинга в интернете, так как, например ряд сайтов верстает версту -дизайн сайта под каждый браузер, с учетом его специфики выполнения спецификаций HTML5, CSS и других стандартов, которые разные браузеры часто выполняют со значительными отличиями.

Браузер iPhone имеет значение «User-Agent» следующее:


Перенаправление домашних каталогов для чужаков

Описание:

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

Решение:

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


Перенаправление несуществующих URL на другой веб-сервер

Описание:

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

Решение:

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

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

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


Редиректы в зависимости от времени

Описание:

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

Решение:

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

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


Управление содержанием — От старого с новому (внутреннее)

Описание:

Предположим что мы недавно переименовали страницу 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]):


Обратное динамическое зеркало

Описание:

Решение:


От статики к динамике

Описание:

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

Решение:

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


Регенерация содержания на лету

Описание:

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

Решение:

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

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


Перенаправление по языку определенному по веб-браузеру зашедшего

Описание:

Файл Htaccess перенаправит посетителя с определенным языком на определенную вами страницу с соответствующим содержанием.

Решение:

Оставляем естественное нужный язык (например zh -китайский), и ставим свою страницу вместо http://htaccess.net.ru/doc/additional_material/index.php:

Объем информации: bytes

www.htaccess.net.ru

Очень простой вопрос, но ответа не нашел.

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

Вот что у меня есть:

Options -Indexes  RewriteEngine on   RewriteCond %{REQUEST_FILENAME} !-f  RewriteCond %{REQUEST_FILENAME} !-l   RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]  

Правило применяется только для не существующих файлов. Но я хочу получить то, что пользователь набрал, потому что строка url обрабатывается с помощью php, который решает, что с ним делать.

EDIT ======================================================================================================================================================================== ============================================

Вопрос получил ответ, но выясняется, что это не было что мне нужно. Итак, здесь новый измененный Вопрос:

Весь сайт работает на Ajax. Значит, существует только один файл index.php, который содержит фрейм веб-сайта. Каждая другая страница/контент загружается через Ajax. Поэтому есть папка под названием «страницы», которая содержит все файлы php содержимого, которые загружаются в index.php. Чтобы сделать эту систему работать, мне нужно было сделать:

  1. Поймать ввод пользователь вводит в URL через .htaccess
  2. передать ввод-строку PHP, которая пытается понять, где пользователь хочет go, и передает адрес javascript
  3. javascript загружает контент с помощью ajax.

некоторый код:

.htaccess — смотри выше

PHP:

$pass = $_GET['url'];  $pass = str_replace(".php", "", $pass);  $pass = str_replace(".html", "", $pass);  $pass = str_replace("pages/", "", $pass);   $dirtest = "pages/" . $pass . ".php";  $isdir = file_exists($dirtest);   if ($pass == "") {   $pass = "news";  }else{   if (!$isdir){   $pass = "pageNotFound";   }  }  echo $pass;  

Ajax: Это большой файл, так что я не хочу, чтобы спам это здесь , но он в основном принимает $ pass и выполняет некоторые функции загрузки ajax.

И вот улов: Когда пользователь хочет получить доступ к ex: странице загрузки: он печатает в «(сайт)/скачать». Поскольку этот конкретный файл не существует в этом каталоге, .htaccess передает «загрузку» на php, который проверяет, есть ли в папке страниц файл download.php, и поскольку это верно, он передает «загрузку» в Ajax. Ajax загружает страницу/download.php внутри index.php. Так оно и должно быть. Но что делать, если пользователь вводит «(сайт)/pages/download». .htaccess замечает, что этот файл существует в этом каталоге и не передает какой-либо параметр в php, что ломает все.

Что мне нужно: Мне нужно как-то манипулировать запросом url, чтобы не разрешать прямой доступ к/pages /, но разрешать доступ, когда ajax вызывает его.

Если вам нужна дополнительные детали или явный код, здесь хранилище GitHub: GitHub

stackoverrun.com

Внимание, вопрос: Когда будет срабатывать правило 7: при выполнении всех трех условий или хотя бы одного. Данный вопрос возник в связи с тем что:

При выполнении хотя бы одного. Условия разделены через [OR] — логическое «или»

Внимание, вопрос: Что означает $1

$1 это переменная, куда попадает совпадение из регулярного выражения.

^resource/(.*)$
Само выражение представляет собой следующее:

^ - начало строки resource/ - слово resource и символ / ( - открываем захват подстроки .* - ищем любой символ ) - закрываем захват подстроки $ - конец строки

Подстрока, которая находится внутри круглых скобок (внутри захвата подстроки) в дальнейшем доступна через $1. Если в регулярном выражении несколько круглых скобок, то доступны $2, $3, $4 и т.д.
Под это регулярное выражение подходят все url, которые начинаются с resource/, например:

http://example.com/resource/ http://example.com/resource/0219381209380123/ http://example.com/resource/js/main.js/
Внимание, вопрос: Почему тут нет никаких условий. Ну и опять $1.

Условия — это регулярные выражения. Проверяется совпадение URL с регулярным выражением (написал выше как это происходит), и если регулярное выражение совпало с URL, то выполняется переадресация на вторую часть выражения. Дальше переадресации не выполняются, т.к. есть флаг [L] — означает Last — то есть «последнее».

Внимание, вопрос: Что вообще тут происходит? Т.е. мы преобразовываем абсолютно любой URL в…. Ничто?! Второго параметра то нет.

Ищутся URL, которые проходят первые три условия (которые написаны через OR) — то есть URL должен обращаться к файлу, либо к папке, либо к символьной ссылке. Затем проверяется совпадение URL по одному из четырех условий и выполняется переадресация.
Я не знаю, о чем думал автор, по идее, если удалить все строчки кроме index.php, все будет работать.

10. Тут, мне кажется, правило означает, перенаправление любого запроса на index.php.
Внимание, вопрос: Верно?

да

Почему условие есть только у одного правила, и почему это работает?

Условия можно писать как под одно правило, так и под несколько правил. Если условия выполняются, то выполнится то правило, где URL подходит под регулярное выражение. Дальше выполнение правил завершается, т.к. стоит флаг [L].
Флаг [NC] означает «без учета регистра»

toster.ru

В общем виде, в теории:

Правила

RewriteRule шаблон_поиска строка_замены [флаги]

В шаблоне поиска записывается регулярное выражение для поиска в запрашиваемом URL.
[spoiler title=»Некоторые правила PERL-совместимых регулярных выражений»]
Текст:
. любой символ
[ ] класс: [символы] любые символы класса, [^символы] любые символы кроме символов класса
| или: text1|text2 текст1 или текст2
^ начало строки, $ конец строки
Квалификаторы:
?    0 или 1 вхождение предыдущего символа или группы
*    0 или N вхождений  (N > 0)
+   1 или N вхождений (N > 1)
Группировка:
(текст) группа в левой части, которая в левой части  обозначается  $N (N — порядковый номер группы) (см. ниже пример 2),  или группировка для альтернативы text1|text2
Экранирование спецсимволов:
символ если нужно использовать символы, которые имеют специальное значение, такие как  . [ ] ( ) [/spoiler]
В строке замены могут использоваться текст, ссылки на подстроки из шаблона поиска и значения серверных переменных.
Серверные переменные в директивах модуля mod_rewrite записываются в формате
%{имя_переменной), где именем переменной может быть:
server_name – имя веб-сервера, например: www.сайт.ru
server_port – номер порта веб-сервера
document_root – каталог документов верхнего уровня для веб-сайта, например, /usr/host/mysite/html
[spoiler title=»Некоторые другие серверные переменные»]
http_forwarded – переадресованная ссылка
http_host – имя компьютера веб-сервера
http_referer – адрес страницы, с которой выполняется переход на текущую страницу
http_user_agent – веб-клиент, который запросил текущую страницу
remote_addr – IP-адрес посетителя
remote_host – имя компьютера посетителя
request_method – метод запроса при обращении к текущей странице
script_filename – физический путь к запрошенной странице, например: /usr/host/mysite/html/page.php
query_string – параметры запроса к странице, например, id=3&parent=4
request_uri – запрошенный URL. Содержит строку запроса после имени сервера, например, /company/test.php?id=3&parent=4
request_filename – то же самое, что и request_uri
time_year – текущий год, time_mon – месяц, time_day– день
time_hour – час, time_min – минута, time_sec – секунда
time_wday – день недели, time – текущее время
[/spoiler]

Условия

RewriteCond контрольная_строка шаблон_поиска [флаги]
Если шаблон поиска найден в контрольной строке (условие выполнено), выполняются директивы, указанные сразу за директивой RewriteCond, или управление переходит к следующему блоку директив.

Примеры:

1. Скрытое и видимое преобразование

RewriteEngine on RewriteBase / RewriteRule ^oldpage.html$ newpage.html [R]

— запрос страницы oldpage.html преобразуется в запрос к странице newpage.html, причем если не указан флаг [R], это будет незаметно посетителю (в адресной строке останется oldpage.html)!

2. Преобразование сайт.ru/~username/ ->  сайт.ru/users/username/

... RewriteRule /~([^/]+)?(/*)/ /users/$1/$2 [R]

Скобки ( ) в левой части обозначают группы по порядку, которые в правой части обозначены $1 и $2.

3. Преобразование в зависимости от типа браузера

RewriteEngine On RewriteBase / RewriteCond %{HTTP_USER_AGENT} Opera RewriteCond %{REQUEST_FILENAME} server.ru/$|server.ru/index.php RewriteRule ^(.*) index_opera.php?%{QUERY_STRING} [L] RewriteCond %{HTTP_USER_AGENT} Netscape13 RewriteCond %{REQUEST_FILENAME} server.ru/$|server.ru/index.php RewriteRule ^(.*) index_netscape.php?%{QUERY_STRING} [L]

Если выполнено первое условие RewriteCond — наличие в заголовке HTTP_USER_AGENT подстроки Opera -, проверяется следующее условие — запрос файла index.php или к корню сайта server.ru без указания имени файла. Если и это условие выполняется, выдается файл для браузера Opera – index_opera.php.
(Флаг [L] означает окончание выполнения директив.)
Если же первое условие не выполнено, управление переходит на следующий блок, который начинается с условия

RewriteCond %{HTTP_USER_AGENT} Netscape

и все происходит аналогично для браузера семейства Netscape

4. Преобразование в зависимости от времени суток

С 7:00 до 19:00 дневной файл page_day.php, а в остальное время ночной файл page_night.php:

RewriteEngine On RewriteBase / RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700 RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900 RewriteRule ^page.php$ page_day.php?%{QUERY_STRING} [L] RewriteRule ^page.php$ page_night.php?%{QUERY_STRING} [L]

5. Запрет для конкретного робота

Директивы файла robots.txt – это только рекомендации для роботов. Гарантированный запрет обеспечивают директивы в файле .htaccess, например:

RewriteEngine On RewriteBase / RewriteCond %{HTTP_USER_AGENT} ^robot RewriteCond %{REMOTE_ADDR} ^196.56.78.18 RewriteRule ^(.*) for_bad_robots.php

Здесь проверяется имя robot, переданное в заголовке user-Agent, а затем IP-адрес, с которого робот пришел на сайт. Если оба условия выполняются, происходит запрос к странице for_bad_robots.php.
Источники:
http://itif.ru/htaccess-dly-zend-framework/
http://web.ixit.ru/pdf/apache/apache_config.pdf
Подробнее: http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteoptions
Всего просмотров 2,593, сегодня 53

sserjoga.blogspot.com


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.