RSS

Компьютерная терминология    1_9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  .....  A  Б  В  Г  Д  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч

mod_rewrite



Бесплатная консультация специалиста
Loading…
 
редирект дублей одной и той же страницы на основной ее адрес:

---------------
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^site.ru
RewriteRule (.*) http://www.site.ru/$1 [R=301,L]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/
RewriteRule ^index\.html$ http://www.site.ru/ [R=301,L]
--------------
Таким образом, мы получим редирект всех страниц-дублей на www.site.ru/


Меняем расширение html на php

Иногда бывает так, что у Вас статичный веб-сайт, а Вам необходимо, чтобы на нем срабатывал какой-нибудь php-скрипт. Для этого Вам необходимо сказать серверу, чтобы он обрабатывал эту страницу как php-файл.

AddHandler application/x-httpd-php .html

Этот прием можно использовать и для других расширений файлов:

AddHandler application/x-httpd-php .xml
AddHandler application/x-httpd-php .asp
Задаем собственные страницы ошибок

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

Задать же собственную страницу ошибок можно следующим образом:

ErrorDocument 404 http://www.site.ru/404.php
Индексация директорий и поддиректорий

Чтобы избежать индексации поисковыми системами директорий и поддиректорий, необходимо прописать такую строку, к примеру:

DirectoryIndex index.php3


Переадресация страниц

Простое правило, позволяющее переадресовывать с одной страницы на другую:

redirect 301 /old-page.php http://www.site.ru/new-page.php
Переадресация Вашего фида на Feedburner

Если Вы хотите, чтобы на Ваш RSS-фид подписывались через Feedburner, то используйте следующий код:

RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^your-feed\.xml$ http://feeds.feedburner.com/your-feed [R,L]
 


Защита изображений от скачивания

RewriteEngine on
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)?site\. [NC]
RewriteCond %{HTTP_REFERER} !google\. [NC]
RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]
RewriteCond %{HTTP_REFERER} !msn\. [NC]
RewriteCond %{HTTP_REFERER} !yahoo\. [NC]
RewriteCond %{REQUEST_URI} !^/hotlinker\.gif$
RewriteRule \.(gif|jpg|png)$ /hotlinker.gif [NC,L]

hotlinker.gif – изображение, которое будет отображаться  вместо истинных изображений.
 


Создание ЧПУ (человеко-понятных урлов) с помощью mod_rewrite

C его помощью можно преобразовать, например, www.site.ru/product.php?id=123 в www.site.ru/product/123 следующим образом:

RewriteEngine on
RewriteRule ^product/([^/\.]+)/?$ product.php?id=$1 [L]

В другом примере преобразуем www.site.ru/script.php?product=123 в www.site.ru/cat/product/123/:

RewriteRule cat/(.*)/(.*)/$ /script.php?$1=$2
Избавляемся от QUERY_STRING

Некоторые веб-мастера делают ссылки вида www.site.ru/index.php?source=blogstorm, чтобы знать, откуда идут посетители. Из-за этого появляется дублированный контент, от которого надо избавляться:

RewriteCond %{QUERY_STRING} ^source= RewriteRule (.*) /$1? [R=301,L]


Директивы сложного перенаправления (mod_rewrite)

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

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

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

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

$N

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

%N

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

%{NAME_OF_VARIABLE}

где NAME_OF_VARIABLE может быть одной из ниже приведенных переменных

 
Ниже приводится список всех доступных переменных %{NAME_OF_VARIABLE} с их кратким описанием.
 

HTTP_USER_AGENTСодержит информацию о типе и версии браузера и операционной системы посетителя.
HTTP_REFERERПриводится адрес страницы, с которой посетитель пришёл на данную страницу.
HTTP_COOKIEСписок COOKIE передаваемых браузером
HTTP_FORWARDEDСтраница непосредственно с которой перешел пользователь
HTTP_HOSTАдрес сервера
HTTP_ACCEPTОписываются предпочтения клиента относительно типа документа.
REMOTE_ADDRIP-адрес посетителя.
REMOTE_HOSTадрес посетителя в нормальной форме
REMOTE_IDENTИмя удаленного пользователя. Имеет формат имя.хост
REMOTE_USERТо-же, что и REMOTE_IDENT, но содержит только имя
REQUEST_METHODПозволяет определить тип запроса (GET или POST). Должен обязательно анализироваться, т.к. определяет дальнейший способ обработки информации
SCRIPT_FILENAMEПолный путь к вебстранице на сервере.
PATH_INFOСодержит в себе все, что передавалось в скрипт.
QUERY_STRINGСодержит строчку, переданную в качестве запроса при вызове CGI скрипта.
AUTH_TYPEИспользуется для идентификации пользователя
DOCUMENT_ROOTCодержит путь к корневой директории сервера.
SERVER_ADMINПочтовый адрес владельца сервера, указанный при установке.
SERVER_NAMEАдрес сервера
SERVER_ADDRIP-адрес вашего сайта.
SERVER_PORTПорт на котором работает Apache.
SERVER_PROTOCOLВерсия HTTP протокола.
SERVER_SOFTWAREНазвание сервера, например, Apache/1.3.2 (Unix)
TIME_YEAR
TIME_MON
TIME_DAY
TIME_HOUR
TIME_MIN
TIME_SEC
TIME_WDAY
TIME
Переменные предназначены для работы со временем в разных форматах.

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

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

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

 
  • Вы можете предварять строку шаблона префиксом '!' для указания несоответствия шаблону.
  • '<Условие' (лексически меньше)
  • '>Условие' (лексически больше)
  • '=Условие' (лексически равно)
  • '-d' (является ли каталогом)
  • '-f' (является ли обычным файлом)
  • '-s' (является ли обычным файлом с ненулевым размером)
  • '-l' (является ли символической ссылкой)
  • '-F' (проверка существования файла через подзапрос)
  • '-U' (проверка существования URL через подзапрос)

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

    RewriteEngine включает или выключает работу механизма преобразования. Если она установлена в положение off этот модуль совсем не работает. Отметьте, что по-умолчанию, настройки преобразований не наследуются. Это означает что вы должны иметь RewriteEngine on директиву для каждого виртуального хоста в котором вы хотите использовать этот модуль.
    Синтаксис RewriteEngine выглядит следующим образом:
     

    RewriteEngine on | off
    # По умолчанию RewriteEngine off

     
    Используйте для комбинирования условий в правилах OR вместо AND. Типичный пример - перенавравление запросов на поддомены в отдельные каталоги.
     

    RewriteEngine on
    RewriteCond %{REMOTE_HOST} ^mysubdomain1.* [OR]
    RewriteCond %{REMOTE_HOST} ^mysubdomain2.* [OR]
    RewriteCond %{REMOTE_HOST} ^mysubdomain3.*
    RewriteRule ^(.*)$ ^mysubdomain_public_html/$1
    RewriteCond %{REMOTE_HOST} ^mysubdomain4.*
    RewriteRule ^(.*)$ ^mysubdomain4_public_html/$1
    

     
    Для выдачи главной страницы какого-либо сайта согласно «User-Agent:» заголовку запроса, вы можете использовать следующие директивы:
     

    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
    RewriteRule ^/$ /homepage.max.html [L]
    RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
    RewriteRule ^/$ /homepage.min.html [L]
    RewriteRule ^/$ /homepage.std.html [L]


    Для выдачи разных сайтов для разных браузеров согласно «User-Agent:» заголовку запроса, вы можете использовать следующие директивы:
     

    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
    RewriteRule ^(.*)$ /mozilla/$1 [L]
    RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
    RewriteRule ^(.*)$ /lynx/$1 [L]
    RewriteRule ^(.*)$ /default/$1 [L]


    Общий синтаксис директивы RewriteRule выглядит следующим образом:
     

    RewriteRule Шаблон Подстановка [flag]
    # flag - необязательное поле указывающее дополнительные опции


    В подстановке вы можете использовать, в том числе, и специальные флаги путем добавления в качестве третьего аргумента директивы RewriteRule. Флаги — это разделённый запятыми, следующий список флагов:

    'redirect|R [=code]'
    (вызывает редирект)
    Префикс в Подстановке вида http://thishost[:thisport]/ (создающий новый URL из какого-либо URI) запускает внешний редирект (перенаправление). Если нет никакого кода в подстановке ответ будет с HTTP статусом 302 (ВРЕМЕННО ПЕРЕМЕЩЕН). Для остановки процесса преобразования, вам также нужно написать флаг 'L'.

    'forbidden|F [=code]'
    (делает URL запрещенным)
    Это делает текущий URL запрещённым, например, клиенту немедленно отправляется ответ с HTTP статусом 403 (ЗАПРЕЩЕНО). Используйте этот флаг в сочетании с соответствующими RewriteConds для блокирования URL по некоторым критериям.

    'gone|G [=code]'
    (делает URL «мёртвым»)
    Этот флаг делает текущий URL «мертвым», т.е., немедленно отправляется HTTP ответ со статусом 410 (GONE). Используйте этот флаг для маркировки «мертвыми» не существующие более страницы.

    'proxy|P [=code]'
    (вызвает прокси)
    Этот флаг помечает подстановочную часть как внутренний запрос прокси и немедленно (т.е., процесс преобразования здесь останавливается) пропускает его через прокси модуль. Используйте этот флаг для того, чтобы добиться более мощной реализации диркетивы ProxyPass, интегрирующей некоторое содержимое на удаленных серверах, в пространство имён локального сервера.

    'last|L [=code]'
    (последнее правило)
    Остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований. Используйте этот флаг для того, чтобы не преобразовывать текущий URL другими, следующими за этим, правилами преобразований.

    'next|N [=code]'
    (следуюший раунд)
    Перезапустить процесс преобразований (начав с первого правила). В этом случае URL снова сопоставляется неким условиям, но не оригинальный URL, а URL вышедший из последнего правила преобразования.Используйте этот флаг для перезапуска процесса преобразований, т.е., безусловному переходу на начало цикла.

    'chain|C [=code]'
    (связь со следующим правилом)
    Этот флаг связывает текущее правило со следующим (которое, в свою очередь, может быть связано со следующим за ним, и т.д.). Это имеет следующий эффект: если есть соответствие правилу, процесс продолжается как обычно, т.е., флаг не производит никакого эффекта. Если правило не соответствует условию, все следующие, связанные правила, пропускаются.

    'type|T=MIME-тип [=code]'
    (принудительно установить MIME тип)
    Принудительно установить MIME-тип целевого файла в MIME-тип. К примеру, это можно использовать для имитации mod_alias директивы ScriptAlias которая принудительно устанавливает для всех файлов внутри отображаемого каталога MIME тип равный «application/x-httpd-cgi».

    'nosubreq|NS [=code]'
    (используется только в случае не внутреннего подзапроса)
    Этот флаг дает команду механизму преобразований пропустить директиву если текущий подзапрос является внутренним подзапросом. К примеру, внутренние подзапросы в Apache происходят тогда, когда mod_include пытается получить информацию о возможных файлах по-умолчанию для каталогов (index.xxx). При подзапросах это не всегда полезно и даже иногда вызывает проблему в работе набора директив преобразований. Используйте этот флаг для исключения некоторых правил.

    'nocase|NC [=code]'
    (не учитывать регистр)
    Это делает Шаблон нечуствительным к регистру, т.е., нет различий между 'A-Z' и 'a-z' когда Шаблон применяется к текущему URL.

    'qsappend|QSA [=code]'
    (добавлять строку запроса)
    Этот флаг указывает механизму преобразований на добавление, а не замену, строки запроса из URL к существующей, в строке подстановки. Используйте это когда вы хотите добавлять дополнительные данные в строку запроса с помощью директив преобразований.

    'noescape|NE [=code]'
    (не экранировать URI при выводе)
    Этот флаг не даёт mod_rewrite применять обычные правила экранирования URI к результату преобразования. Обычно, специальные символы (такие как '%', '$', ';', и так далее) будут экранированы их шестнадцатиричными подстановками ('%25', '%24', и '%3B', соответственно); этот флаг не дает это делать.

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

    При наличии в файле .htaccess каких либо директив модуля mod_rewrite не наследуется ничего, а состояние по умолчанию выставляется таким же, как в главном конфигурационном файле веб-сервера (по умолчанию "off"). Поэтому, если нужны правила преобразования для конкретного каталога, то нужно еще раз вставить директиву "RewriteEngine on" в .htaccess для конкретного каталога.

    При наследовании правил из верхних каталогов и добавлении к ним новых свойственных только данному каталогу - необходимо выставить в начале следующее: "RewriteEngine on" и "RewriteOptions inherit" - последняя директива сообщает серверу о продолжении.

    При наследовании правил из верхних каталогов и добавлении к ним новых свойственных только данному каталогу - необходимо выставить в начале следующее: "RewriteEngine on" и "RewriteOptions inherit" - последняя директива сообщает серверу о продолжении.


    Преобразование динамических URL в статические

    Создание с помощью mod_rewrite ссылок "понятных" для поисковиков.

    Mod_rewrite не может изменить URL в браузере пользователя

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

    Как изменить динамический URL на статический

    Вот алгоритм, который надо выполнить для создания статических URL на динамическом сайте:
    Рассматривая вышесказанное, можно догадаться, что оба формата: и динамический, и статический URL должны содержать в себе всю информацию, необходимую для преобразования в другой формат. И запомните, что осторожный выбор "дизайна" статических URL в будущем может уберечь вас от многих проблем, а также уменьшить количество циклов процессора, которое может сильно вырасти при неумелой реализации такого преобразования.

    Важное предупреждение

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

    Рабочий пример

    Старый динамический формат URL: index\.php?product=widget&color=blue&size=small&texture=fuzzy&maker=widgetco
    Новый статический формат URL: /product/widget/blue/small/fuzzy/widgetco
    Код mod_rewrite, используемый в .htaccess:
    # Запуск mod_rewrite
    Options +FollowSymLinks
    RewriteEngine on
    #
    # Внутренние преобразования статических URL в динамические
    RewriteRule ^product/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/?$
    /index.php?product=$1&color=$2&size=$3&texture=$4&maker=$5 [L]
    #
    # Внешний редирект клиента со старых динамических URL на новые статические
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\
    /index\.php\?product=([^&]+)&color=([^&]+)&size=([^&]+)&texture=([^&]+)&maker=([^\ ]+)\ HTTP/
    RewriteRule ^index\.php$ http://example.com/product/%1/%2/%3/%4/%5? [R=301,L]
    Заметьте, что слово "product" всегда присутствует и в статическом, и в динамическом формате. В этом случае mod_rewrite проще определить запросы, где необходимо применять приведенные выше правила. Другие методы, такие как проверка на существование файла, также можно использовать, но они менее эффективны и более подвержены ошибкам сравнения.

    Различия между использованием .htaccess и httpd.conf

    Если вы будете использовать правила mod_rewrite в контейнере <directory> конфигурационного файла httpd.conf, то вам потребуется добавить в регулярные выражения обеих директив RewriteRule слеш (/). Например, придеться изменить "RewriteRule ^index\.php$" на "RewriteRule ^/index\.php$". Также запомните, что вам надо перезапустить сервер, чтобы внесенные изменения в файле конфигурации начали действовать.

    Как это работает

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

    Размещение правил mod_rewrite

    Чтобы приведенный код работал надлежащим образом, он должен быть размещен в файле .htaccess в том же каталоге, где и /index.php. Также он может быть помещен в контейнер <directory> в файле httpd.conf, который ссылается на этот каталог.

    Регулярные выражения

    Тут я приведу только одно замечание по поводу регулярных выражений, использованных выше. Я избегаю использования очень простых и популярных, но очень неэффективных конструкций "(.*)/(.*)". Ибо использование множества конструкций ".*" в регулярных выражениях очень неэффективно.
    Причины этому две. Первое - ".*" означает "подставить любое число любых символов". И второе - конструкция ".*" очень "прожорливая", что означает, что в шаблон подставится максимально возможное количество символов. А это в свою очередь означает, что, перед тем как запрошенный URL совпадет или не совпадет с регулярным выражением, произойдет множество подстановок, количество которых равно (количеству символов между "/" и концом запрашиваемого URL минус 2) умноженное на (количество "(.*)" минус один). Легко сделать регулярное выражение со множеством "(.*)", разбор которого потребует десятки или даже сотни проходов.
    Давайте взглянем на короткий пример. Обратная связь $1 содержит символы, подставляемые в первую "(.*)", а $2 - символы, подставляемые во вторую:
    Запрошенный URL: http://example.com/abc/def
    Локальный путь: abc/def
    Шаблон правила: ^(.*)/(.*)$
    № проходаЗначение $1Значение $2Результат
    1 …abc/def .- ……не совпадает
    2 …abc/de .f ……не совпадает
    3 …abc/d ..ef …..не совпадает
    4 …abc/ …def ….не совпадает
    5 …abc ….def ….совпадает
    Я осмелюсь предположить, что множество сайтов проводят каждый год обновление серверов, но эту ошибку оставляют.
    Вместо этой конструкции я использую "([^/]+)", "([^&]+)" и "([^\ ]+)". В грубом переводе они соответственно означают "подставить один или несколько символов не равных слешу", "подставить один или несколько символов не равных &" и "подставить один или несколько символов не равных пробелу". Разница заключается в том, что каждая из этих конструкций будет "потреблять" один или более символов из запрошенного URL, увеличивая количество на один, тем самым, позволяя парсеру регулярных выражений проверить запрошенный URL за один проход слева-направо.

    Частые проблемы

    Самой частой проблемой, встречающейся при реализации преобразований URL из динамических в статические - это когда "ломаются" относительные ссылки внутри вашей страницы (на изображения, на CSS файлы и внешние JavaScript). Проблема в том, что клиент (например браузер) сам обрабатывает относительные ссылки. Например, если вы обрабатываете URL product/widget/blue/fuzzy/widgetco, то браузер увидит страницу "widgetco" и будет обрабатывать относительные ссылки этой страницы относительно "виртуального" каталога /product/widget/blue/fuzzy/. Есть два простых решения этой проблемы. Первое - это использовать серверо-относительные ссылки (или абсолютные ссылки), или использовать дополнительные mod_rewrite правила для преобразования URL картинок, CSS файлов и т.п. Вот пример использования серверно-относительной ссылки <img src="/logo.gif">, которая заменяет странично-относительную ссылку <img src="logo.gif">.

    Проблемы при тестировании

    Как для .htaccess, так и для httpd.conf перед тестированием любых изменений не забывайте очищать кеш браузера. Иначе ваш браузер обработает одну из ранее запрошенных страниц из кеша. Понятно, что в этом случае, новый код не выполнится.

    Некоторые сайты ссылаются на ваш, добавляя строку запроса. Например, можно сослаться на ваш сайт, используя эту ссылку http://www.site.com/index.php?source=seoblog, просто для того, чтобы знать откуда приходит трафик. Это становится причиной появления дублирующегося содержания для вашего сайта, поэтому вам нужно настроить перенаправление на вашу домашнюю страницу:

    RewriteCond %{QUERY_STRING} ^source= RewriteRule (.*) /$1? [R=301,L]


    Если вы хотите запретить другим веб-сайтам напрямую ссылаться на изображения, расположенные на вашем сайте, но позволить поисковикам Google, Yahoo и MSN индексировать их, вам необходимо воспользоваться следующим кодом:

    RewriteEngine on
    RewriteCond %{HTTP_REFERER} .
    RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)?site\. [NC]
    RewriteCond %{HTTP_REFERER} !google\. [NC]
    RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]
    RewriteCond %{HTTP_REFERER} !msn\. [NC]
    RewriteCond %{HTTP_REFERER} !yahoo\. [NC]
    RewriteCond %{REQUEST_URI} !^/hotlinker\.gif$
    RewriteRule \.(gif|jpg|png)$ /hotlinker.gif [NC,L]
    Изображение hotlinker.gif - это изображение, которое создано вами.


    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
    RewriteRule ^(.*) $1? [L]
    </IfModule>
    или:
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{QUERY_STRING} ^[^=]*$
    RewriteCond %{QUERY_STRING} %2d|\- [NC]
    RewriteRule .? - [F,L]
    </IfModule>
    Проверяется QUERY_STRING:
    В первом случае, если значение параметра QUERY_STRING начинается с "-" и после него идёт любой символ кроме "=", то QUERY_STRING обрезается.
    Во втором случае, если в строке не встречается сивол "=" и если встречается знак "-", то выдаётся ответ 403 - Forbidden.
    A. Требуется переименовать php в html через RewriteRule
    Требуется переименовать:
    имя_папки/имена_файлов.php в имя_папки/имена_файлов.html
    Q. RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.+)\.html $1.php [L]
    Запрос /file.html на серверу будет заменятся на file.php
    Работать будет только при запросе несуществующих html файлов

    seo & website usability inet os faq hardware faq memory video cpu hdd mainboard faq printer & scaner modem mobiles hackzone

    Технологии поискового маркетинга
    Практика поискового маркетинга
    Flash
    Тэги
    XML
    DHTML
    PHP
    MySQL
    WebMail
    .NET
    VBScript
    CGI
    Графические форматы Интернета
    WEB-сайт шаг за шагом
    CMS faq
    FRAME faq
    CSS faq
    SSI faq
    RSS faq
    WAP faq
    Web-Designed
    Webhints
    Файл настроек .htaccess
    Настройка robots.txt
    Windows 10 | Registry Windows 10 | Windows7: Общие настройки | Windows7: Реестр | Windows7: Реестр faq | Windows7: Настроки сети | Windows7: Безопасность | Windows7: Брандмауэр | Windows7: Режим совместимости | Windows7: Пароль администратора |  |  |  |  | Память | SDRAM | DDR2 | DDR3 | Quad Band Memory (QBM) | SRAM | FeRAM | Словарь терминов | Video | nVIDIA faq | ATI faq  | Интегрированное видео faq | TV tuners faq | Терминология | Форматы графических файлов | Работа с цифровым видео(faq) | Кодеки faq | DVD faq | DigitalVideo faq | Video faq (Архив) | CPU | HDD & Flash faq | Как уберечь винчестер | HDD faq | Cable faq | SCSI адаптеры & faq | SSD | Mainboard faq | Printer & Scaner | Горячая линия бесплатной юридической консультации | Благотворительность

    На главную | Cookie policy | Sitemap

     ©  2004