1. Модули Apache
2. директивы
3. Контекст сервера
4. изменения конфигурации
5. .htaccess
6. ModRewrite
7. пустая замена
8. Внутренние, неявные и явные перенаправления (от ModRewrite)
9. Внутренний редирект
10. Неявное перенаправление
11. Явный редирект
12. Ссылки назад
13. SEO Pitfall
14. RewriteLog
15. Строка запроса в ModRewrite
16. ModRewrite: еще немного классики
17. Принудительно указать правильный хост
18. Блокировка UserAgent
19. Другие модули
20. Управление файлами: FilesMatch (mod_core)
21. Производительность: установка тегов сущностей (mod_core)
22. Производительность: ExpireHeader set (mod_expires)
23. Перенаправления (mod_alias)
24. QueryString в RedirectMatch
25. Определить документ об ошибке

Если вы ходите по SEO-сцене, вы можете быстро и часто говорить о «htaccess»: просто добавьте это и «в htaccess», тогда с SEO это сработает. Потому что кажется, что даже самые запутанные структуры URL веб-приложения выглядят просто ослепительно. Или просто при переходе на новый домен переадресовывать старые URL, чтобы взять «сок» еще.

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

Если SEO говорит о htaccess, то, по моему опыту, это означает использование чрезвычайно популярного в SEO кругах модуля веб-сервера «ModRewrite», который делает возможной такую ​​магию. Но об этом позже. Перед этим я хотел бы попытаться выполнить некоторую образовательную работу, чтобы лучше понять htaccess, и я кратко рассмотрю некоторые основные концепции веб-сервера Apache.

теория:

Практические рекомендации

Модули Apache

Веб-сервер Apache, грубо говоря, состоит из различных модулей, которые делают их функции доступными для пользователя веб-сервера. Модули либо загружаются при запуске сервера, либо статически компилируются в ядро ​​сервера.

Примеры модулей включают в себя:

• mod_auth : модуль для управления аутентификациями для доступа к страницам
• mod_headers : «Настройка» HTTP-запроса и HTTP-заголовка ответа
• mod_proxy : перенастроить веб-сервер на «прокси» (глючит)
• и просто (drumroll) mod_rewrite : «Перезаписать», изменить URL; Также известный как mod_seo 😉

Mod_rewrite, столь популярный у SEO, является лишь одним из многих модулей веб-сервера Apache.

директивы

Эти модули предоставляют различные параметры конфигурации, которые можно вводить в файл конфигурации сервера в форме так называемых директив . Например, директива DocumentRoot. Его можно использовать для указания того, в каком физическом каталоге машины файлы должны быть доступны в Интернете:

DocumentRoot / usr / local / apache / htdocs

Конечно, существует множество таких директив (см. Ссылки). Знание того, какая директива предоставляется тем или иным модулем, не имеет значения, поскольку директивы могут, конечно, использоваться только в конфигурации, если ответственный модуль также присутствует и загружен. Чтобы избежать проблем при загрузке конфигурации, есть директива IfModule, которая, безусловно, удивила тех или иных, кто редактировал htaccess своего блога WordPress:

<IfModule mod_rewrite.c>
RewriteBase /
RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteRule. /index.php [L]
</ IfModule>

Так что в разделе выше просто сказано. Интерпретируйте эти директивы только в том случае, если модуль mod_rewrite также присутствует и загружен. Здесь, предположительно по историческим причинам, имя файла исходного кода, здесь mod_rewrite.c с указанием. Несколько сбивает с толку ...

Контекст сервера

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

• контекст сервера : основная конфигурация сервера
• Контекст VirtualHost : в основной конфигурации несколько хостов («доменов») могут быть настроены как VirtualHosts
• контекст каталога : конфигурации, которые играют в каталоге.
• и контекст htaccess

В контексте допускаются только определенные директивы. Это допускает определенную концепцию авторизации в конфигурации сервера и должна служить эксплуатационной безопасности: самые мощные директивы разрешены только в контексте сервера, к которому, например, имеет доступ только веб-мастер и т. Д.

изменения конфигурации

Общая конфигурация сервера, «http.conf» (и связанные, возможно, выгружаемые файлы, которые могут быть включены) интерпретируются при запуске сервера или перезагружаются явной директивой на сервер. Следовательно, изменения в конфигурации вступят в силу только после перезапуска сервера или просто путем «перезагрузки» конфигурации.

.htaccess

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

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

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

Чтобы механизм htaccess работал в системе, его, возможно, все же необходимо активировать в контексте сервера. Это делается с помощью директив AllowOverride и Options .

<Directory "/ path / to / your / webfolder /">
Опции Все + MultiViews
AllowOverride All
</ Directory>

Использование этих директив требует некоторого привыкания. Как видите, конфигурация происходит в контексте каталога: для веб-каталога вы должны сначала сообщить серверу, какие параметры применяются к этому каталогу, в данном случае все . Список всех опций можно найти на http://httpd.apache.org/docs/2.2/mod/core.html#options , Опция MultiViews должна быть указана странным образом. Каждый из этих параметров представляет собой серию директив. Здесь также упоминается документация apache.

Какие из установленных параметров (и, следовательно, директив) затем разрешены в файле htaccess и могут быть перезаписаны, управляется AllowOverride , в данном случае также All . Конечно, все означает только те, которые также разрешены в контексте файла htaccess.

Поэтому какие директивы разрешены в htaccess, зависит от конфигурации контекста сервера вашего провайдера. Если директива синтаксически верна, но недопустима, сервер отвечает «500 Internal Server Error», так же как и синтаксически неправильно используемая директива. Поэтому проверьте ваш ErrorLog: найдите подсказку типа ".htaccess: Опции здесь не разрешены" или аналогичные. Спросите своего провайдера: возможно, он сможет смягчить, необходимую опцию для активации, особенно если многие клиенты просят об этом.

ModRewrite

Как уже упоминалось, есть несколько модулей со многими директивами, которые можно использовать в файле htaccess. Не все действительно заботятся о SEO. Но поскольку mod_rewrite является наиболее подходящим для SEO, я хочу начать с этого. Mod_rewrite сейчас широко обсуждается на соответствующих форумах, поэтому я однажды предполагал наличие базовых знаний и хотел бы сосредоточиться только на некоторых особенностях, которые приводили (снова и снова ко мне) в замешательство.

В этом контексте также на Оригинальная документация направлены. Это на английском языке, но, насколько мне известно, все еще самый полный и лучший документ по этому вопросу. Если вы не сразу все сразу поняли, не переживайте ;-). Многие вещи просто становятся понятными в конкретном приложении, такие как

пустая замена

Переписать двигатель на
RewriteRule. - [L]

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

Переписать двигатель на
RewriteCond% {REQUEST_FILENAME} -f
RewriteRule. - [L]

Это правило удаляет все следующие правила для физически существующих файлов в DocumentRoot и ниже: Если это физически существующий файл (-f), отключите его. Практично, и правило, которое мне нравится начинать с конфигурации ModRewrite: позвольте мне загружать файлы и сценарии на сервер, независимо от сложности правил, а затем выполнять их без полного набора правил. пройти.

Внутренние, неявные и явные перенаправления (от ModRewrite)

Это имеет большое значение, независимо от того, передаете ли вы URL «в режиме реального времени» или оставляете действие модулю, указав RewriteRule . Может также случиться так, что «перенаправление» выполняется только внутренне или принудительно внутри, что, в свою очередь, означает, что «реальное» перенаправление уже выполнено без явного указания на это. Это также может сбивать с толку, поэтому пример для уточнения:

Внутренний редирект

Переписать двигатель на
RewriteRule ^ old-script.php $ new-script.php [L]

Если вы вызываете URL / old-script.php , / new-script.php будет выполнен и выведен . Обязательным условием для этого является, конечно, наличие сценария new-script.php . Сервер отвечает просто с кодом состояния «200 OK», в адресной строке все еще / old-script.php , а в RewriteLog (см. Ниже) что-то вроде [ВНУТРЕННЕГО НАПРАВЛЕНИЯ]. Таким образом, «переписывание» внешне вообще не видно, просто внутреннее.

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

Неявное перенаправление

Добавьте это к серверу и протоколу к полному URL, неявно применяя перенаправление.

Переписать двигатель на
RewriteRule ^ old-script.php $ http://www.myhost.de/new-script.php [L]

Разница с первым примером не совсем незначительна: на данный момент сервер просто отправляет браузеру информацию о том, что ресурс «временно» где-то еще («302 перемещен временно»), а также дает новый адрес в поле заголовка. Переменная «Местоположение» с. Контент не будет передан. Если браузер следует этому, то http://www.myhost.de/new-script.php появится в его адресной строке. Новый пункт назначения был вызван браузером .

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

Явный редирект

Приятно то, что с ModRewrite вы можете явно указать, что вы хотите перенаправить и как.

Переписать двигатель на
RewriteRule ^ old-script.php $ new-script.php [L, R = 301]

Теперь попробуйте переслать URL-адрес, как указано выше, но с явно указанным кодом состояния «301 перемещен навсегда».

Обратите внимание, что в примере в правиле замены указано только имя сценария new-script.php . Однако для создания правильного заголовка ответа для перенаправления должен быть возвращен полный URL-адрес. Вот почему mod_rewrite добавляет URL к текущему имени сервера и протоколу.

Это, в свою очередь, может привести к нежелательным результатам, если настроенное имя сервера отличается от имени хоста: Пример конфигурации хоста Apache, прослушивающего порт 80:

<VirtualHost *: 80>
DocumentRoot / path / to / my / webfolder
Имя_сервера www.domain.com
Псевдоним сервера www.domain-2.de
# ...
</ VirtualHost>

Раздел определяет «VirtualHost» для домена www.domain.de. Поэтому имя виртуального сервера «ServerName» - www.domain.de, однако псевдоним также определен для имени сервера www.domain-2.de. Таким образом, сервер должен отвечать на запросы имени www.domain-2.de, с небольшой, но незначительной разницей:

Вызов mod_rewrite: значение равно http : //www.domain.com% {SERVER_NAME} www.domain.com% {HTTP_HOST} www.domain.com http : //www.domain-2.de% {SERVER_NAME} www .domain.com% {HTTP_HOST} www.domain-2.de

При вызове http://www.domain-2.de/old-script.php правило из вышеприведенного примера и эта конфигурация хоста будет перенаправлять на http://www.domain.de/new-script.php , Конечно, это можно предотвратить, если имя хоста также указано в пересылке.

Ссылки назад

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

Переписать Engine On
RewriteRule ^ / (. +) /.+. Html $ /index.php?id=$1

Если шаблон - это скобка вокруг подшаблона, как здесь (. +), Правило соответствия может использовать ссылку для сопоставления шаблона в скобках , соответствия, с $. Указанное число в примере 1 относится к первому совпадению. Вы можете использовать не более 6 ссылок.

RewriteRule ^ / (. +) / (. +). Html $ /index.php?id=$1&name=$2

Это, например, полезно или необходимо для размещения управляющей информации динамического приложения в «симпатичном» URL. Таким образом, URL http://www.domain.de/234/tolle-seite.html можно, например, сопоставить с http://www.domain.de/index.php?id=234 и, следовательно, с управляющей информацией 234 в параметре id. перешел на index.php .

SEO Pitfall

Конечно, приложение также должно обеспечить вывод строки «great page» в URL в выходных данных. Технически эта информация является пустой тратой, поскольку она не учитывается сценарием обработки. Например, http://www.domain.de/234/elender-versager.html также соответствует правилу, указанному в примере.

В более сложных приложениях с плохим управлением URL «дублированный контент» в смысле нескольких URL уже запрограммирован: избыточные «говорящие» части слишком быстро попадают в вывод. Ничего не заметно, потому что они ничего не контролируют ... Вы должны использовать это только в том случае, если приложение также может повторно проверить URL-адрес по запросу, при необходимости, чтобы перенаправить на нужную страницу или выполнить подходящую каноническую День, чтобы установить.

RewriteLog

Для устранения неполадок ModRewrite существует директива, которая на самом деле довольно проста.

RewriteLog /path/to/my/log/file/log.txt
RewriteLogLevel 10

RewriteLog определяет файл журнала, RewriteLogLevel 10 записывает внутренние шаги обработки на самом разговорчивом уровне 10 в файл.

Кто знает, сколько раз эти две строки уже были написаны в .htaccess? К сожалению, напрасно, потому что эта директива недоступна в файле htaccess. Если вы не верите этому, взгляните на ErrorLog:

RewriteLog не разрешен здесь "

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

Получите локальную установку веб-сервера, где у вас есть все права на активацию RewriteLog и тестирование файла .htaccess.

Строка запроса в ModRewrite

Любой, кто считает, что он должен переадресовывать URL-адреса на основе значений в QueryString, должен быть предупрежден здесь, потому что QueryString («все после знака вопроса») URL-адреса не используется директивой RewriteRule для сопоставления с образцом . Следующий вариант использования: Мы хотим отобразить все URL-адреса, имеющие QueryString с параметром param1 и числом в качестве значения, в новый формат. По какой-то причине.

http://www.server.de/pfad/datei.html?param1=1343&param2=a

Так например

http://www.server.de/index.php?p=1343

вперед.

RewriteRule "param1 = ([0-9] +)" /index.php?p=$1

Любой, кто думает, что может решить это или что-то подобное, ошибается. Если у вас есть доступ к вашему RewriteLog, вы найдете в нем что-то. Звоните: http://www.server.de/pfad/datei.html?param1=1&param2=2.

... применение шаблона param1 = ([0-9] +) к uri, path / file.html '

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

RewriteCond% {QUERY_STRING} param1 = [0-9] +
RewriteRule path / file.html /index.php?param3=3 [L, QSA]

Также невозможно передать отдельные значения QueryString в сценарий обработки через обратные ссылки. Значение параметра param1 нельзя передать в переменную p (как в нашем случае использования) (спасибо за ваши сообщения, если вы видите здесь другие возможности). Только весь QueryString может быть добавлен, что делается путем указания QSA (QueryStringAppend). С описанным правилом будет

/pfad/datei.html?param1=1&param2=2

в

/index.php?param3=3&param1=1&param2=2

Но у вас также есть проблема, если вы больше не хотите передавать QueryString на перенаправленный URL-адрес. Опция QSA RewriteRule фактически предназначена для размещения дополнительных параметров в пересылке, как в примере. Если вы не укажете его, QueryString будет добавлен из запроса. С помощью этой конструкции можно так быстро создать бесконечный редирект!

RewriteCond% {QUERY_STRING} param1 = [0-9] +
RewriteRule. * Http://www.domain.de/ [L]

Хотя QSA не указан, QueryString добавляется. Не рекомендуется

http://www.domain.de/blabla/?param1=1

продолжает вести

http://www.domain.de/?param1=1

и правила будут проходить через следующий запрос с самого начала. Опять же, соответствуйте условию и продолжайте идти, и вот так ... Но вот фокус! Прикрепление вопросительного знака к замене RewriteRule «делает работу»:

RewriteCond% {QUERY_STRING} param1 = [0-9] +
RewriteRule. * Http://www.domain.de/? [L]

Как ни странно, вопросительный знак, вероятно, будет поглощен ModRewrite, потому что он исчез после перенаправления! Хорошо знать.

ModRewrite: еще немного классики

перезаписать robots.txt

В DocumentRoot веб-каталога есть несколько файлов, которые по соглашению должны иметь уникальное имя. Типичным примером SEO является robots.txt. Если вы запустите приложение, которое обслуживает несколько доменов или поддоменов через один и тот же DocumentRoot, у вас изначально будет только один физический файл robots.txt, доступный для всех доменов. Там может помочь mod_rewrite.

UseCase: мы должны предоставить отдельный файл robots.txt для домена www.domain.de и поддоменов sub1.domain.de и 2.domain.de ...

RewriteRule ^ robots.txt $ robots /% {HTTP_HOST} -robots.txt

Таким образом, вы можете довольно удобно, а именно в виде текстового файла, отдельные файлы «robots.txt» управлять доменом в подкаталоге robots / DocumentRoot.

1. роботы / www.domain.de-robots.txt
2. роботы / sub1.domain.de-robots.txt
3. роботы / sub2.domain.de-robots.txt
4. ...

Конечно, это работает так же хорошо с файлами favicon.ico или XML, которые, как известно, должны быть в DocumentRoot.

Принудительно указать правильный хост

RewriteCond% {HTTP_HOST}! ^ Www.domain.com $
RewriteRule ^ (. *) $ Http://www.domain.de/$1 [QSA, L, R = 301]

Блокировка UserAgent

Перейти Googlebot якобы сойти с ума: Googlebot заблокировать доступ к каталогу "nobotshere":

RewriteCond% {HTTP_USER_AGENT} робот Google
RewriteCond% {REQUEST_URI} ^ / nobotshere /.*
RewriteRule. - [F]

Другие модули

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

Управление файлами: FilesMatch (mod_core)

С помощью директивы FilesMatch каждый в основном контролирует свои файлы в веб-каталоге. Регулярные выражения также допускаются.

Например: .ini, .cnf и .conf - Блокировка файлов для веб-доступа:

<FilesMatch ". (Ini | co? Nf) $">
отрицать все
</ FilesMatch>

Производительность: установка тегов сущностей (mod_core)

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

FileTag INode MTime Размер

Тег File File может использоваться для передачи «компонентов», которые используются для вычисления тега ET. Здесь также поддерживается индикация All , что является примером того же.

Стоит упомянуть, возможно, использование значения INode : INode представляет «номер» файла в файловой системе Unix, значение inode уникально в файловой системе. Проблема возникает, если вы хотите доставить один и тот же файл с разных серверов. Если значение индекса включено в расчет электронного тега, значение тега eTag отличается в зависимости от сервера, который его доставил. Чем больше у вас серверов, тем более контрпродуктивным будет использование электронного тега. Средство здесь просто не указывать индекс или отключать электронные теги:

FileTag Нет

Производительность: ExpireHeader set (mod_expires)

По крайней мере, так же важно в оптимизации производительности отправлять так называемый Expired заголовок для ресурсов, если вы можете себе это позволить. Значение указывает, когда ресурс должен быть действительным. Это позволяет браузерам и прокси-серверам кэшировать файл. Есть несколько возможностей. Вот комбинация с директивой FilesMatch:

Отправьте заголовок с истекшим сроком для «измененной даты файла + 4 недели в будущем», действителен для всех файлов с расширением .css и .js

<filesmatch ". (css | js) $">
ExpiresActive on
ExpiresDefault "Модифицированный плюс 4 недели"
</ Спичка Файл>

Спецификация времени здесь может быть изменена или доступна , что относится к файлу. На практике фраза «навсегда» может быть полезной, что, к сожалению, не поддерживается. Любой, кто потерял отслеживание расширений файлов своих файлов JavaScript или CSS, может отправить ExpiredHeader на основе MIME-типа. Конечно, профессионал знает, что типы MIME также отображаются с использованием расширения файла.

ExpiresActive on
ExpiresByType text / css "доступ плюс 4 недели"
Приложение ExpiresByType / x-javascript "модифицированный плюс 4 недели"

Чтобы это работало, вы должны точно знать, какой тип MIME отправляет сервер, потому что иногда он может быть другим. В Apache MIME-типы и связанные с ними расширения хранятся по умолчанию в файле mime.types. В зависимости от версии, для файлов JavaScript существуют разные значения, например

application / x-javascript js
текст / javascript js

Если вам повезло, что вы можете изменить FileInfos в своем файле htaccess, вы также можете переопределить mime-тип ваших файлов Javascript, чтобы убедиться:

AddType text / my-javasript .js

С помощью AddType вы можете добавлять новые Mime-типы, а также перезаписывать существующие Mime-типы: в этом примере предварительно настроенное расширение файла .js с типом text / my-javascript будет перезаписано. То, что это работает, можно увидеть, если теперь вызывает файл с расширением .js через браузер: это ожидает, что проблема интерпретирует специфический тип Mime, и отвечает на вопрос, должен ли файл быть загружен или подобным.

Перенаправления (mod_alias)

Другие модули Apache также предоставляют возможность перенаправления. Здесь, по-видимому, также по историческим причинам, есть 4 очень похожих директивы из модуля mod_alias с форматами:

• Перенаправить [статус] URL-путь URL
• RedirectPermanent URL-путь URL
• RedirectTemp URL-путь URL
• RedirectMatch [статус] регулярное выражение URL

На самом деле вам нужен только RedirectMatch, потому что вы можете передать код состояния (301/302/303/410), и он поддерживает регулярное выражение в качестве шаблона для запроса. Обратные ссылки также могут быть использованы здесь.

RedirectMatch. * Oldscript. * Http://www.new-domain.de/

Это прекрасно работает, если, например, в DocumentRoot домена www.old-domain.de сценарий с именем oldscript.php и файл htaccess находятся с этой директивой. Затем http://www.old-domain.de/oldscript.php ведет по адресу http://www.new-domain.de/ . Все идет нормально.

Тем не менее, можно получить его проблемы с этой директивой. Предположим, что в DocumentRoot старого домена www.old-domain.de есть также файл CSS с именем lib.css . С помощью описанного RedirectMatch можно попытаться, например, также переслать http://www.old-domain.de/lib/oldscript.php и при определенных обстоятельствах может быть чрезвычайно удивлен.

Не найден
Запрашиваемый URL /lib/oldscript.php не найден на этом сервере.

Сервер отвечает 404. Странно: (. * Oldscript. *) Только что сработал!

Переговоры по контенту - это волшебное слово здесь и сейчас, дорогие друзья поисковой оптимизации, оно становится немного уродливым. Apache предоставляет функцию, которая позволяет находить файлы без указания расширения файла, своего рода автозаполнение для файлов. Это также называется MultiViews . Это может быть очень полезно, например, если вы хотите отобразить файл индекса, например, index.html , на разные языковые версии в зависимости от языковых настроек, отправленных браузером в запросе, таких как index.html.es , index.html.en или index .html.fr и т. д.

Но это также может привести к неожиданным результатам. Необходимым условием для этого является то, что функция активирована и включена, что обычно является значением по умолчанию. При вызове http://www.old-domain.de/lib/oldscript.php в файле журнала может отображаться следующее.

Согласование: обнаружен запрос на сопоставление файла (ов): / path / to / htdocs / lib (нельзя согласовать ни один).

Кстати, проблема также существует при попытке решить эту проблему с помощью mod_rewrite.

RewriteRule (. * Oldscript. *) Http://www.new-domain.de/

Таким образом, можно отправить http://www.old-domain.de/oldscript.php еще на http://www.new-domain.de/ . Но в условиях, описанных выше (MultiViews включен, lib.css существует), переадресация с http://www.old-domain.de/lib/oldscript.php больше не работает, она вызывает ошибку 404. Следующее может быть в RewriteLog:

.. [perdir / path / to / htdocs /] добавить постфикс с информацией о пути: /path/to/htdocs/lib.css -> /path/to/htdocs/lib.css/oldscript.php
....

Прежде чем ModRewrite вообще вступит в игру , MultiViews превосходит и уже добавляет / lib в /lib.css . Конечно, ModRewrite может получить только неверный результат.

Любой, кто уже отметил такие «явления», может помочь со следующим утверждением:

Опции -multiviews

Это отключит MultiViews и Redirect будет работать, даже если на сервере нет файла oldscript.php. Однако предварительным условием для этого является то, что он также может переопределить эту функцию в .htaccess.

Те, кто не уверен, что они имеют MultiViews, могут легко проверить это. Как описано, поместите lib.css в веб-каталог, а затем отправьте запрос через браузер www.domain.de/lib . Если MultiViews активирован, содержимое должно быть выведено из lib.css, в противном случае сервер ответит «404 Not found» (если нет даже каталога / lib).

QueryString в RedirectMatch

Также с помощью директивы RedirectMatch, очевидно, может подавить передачу строки запроса, указав знак вопроса.

RedirectMatch. * Oldscript. * Http://www.new-domain.de/?

www.old-domain.de/oldscript.php?foo=bar
затем продолжайте
www.new-domain.de/?
Примечательно, что знак вопроса остается здесь. Не очень приятно и с точки зрения SEO, скорее всего, нежелательно. 😉

Определить документ об ошибке

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

ErrorDocument 404 /404.php

Это можно использовать для определения скрипта, здесь 404.php, как ErrorHandler. Если сервер не может обслуживать запрос и поэтому хочет ответить кодом состояния «404 НЕ НАЙДЕН», управление передается сценарию. Выходные данные ResponseHeader и, следовательно, код состояния оставляются программе. В сценарии, в свою очередь, легко можно переслать запрос с другим кодом состояния . например, 301.

Это дает вам гораздо больше возможностей разбить входящий запрос и снабдить его сложной логикой и т. Д. Для пересылки. Однако, если переадресация не может быть определена, сценарий должен обеспечить возвращение «правильного» кода состояния 404. В противном случае речь идет о так называемых «мягких ошибках 404», как называет это Google.

<? Php
// анализируем запрос и получаем цель перенаправления
// ...
if ($ redirect) {
заголовок («HTTP / 1.1 301 перемещен навсегда»);
заголовок ("Location: $ location");
// ...
}
заголовок («HTTP / 1.1 404 Not Found»);
// вывод содержимого со страницы 404:
// ...
?>

слева

Похожие

Комментарии