Проблемы с выходом перенаправления .htaccess из бесконечного цикла

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

Проще говоря, я пытаюсь взять весь трафик, направляемый на мой сайт с сайта А, и перенаправить его на страницу Б в моем домене. Я получил перенаправление, чтобы работать отлично, но я не могу заставить его вырваться из бесконечного цикла. Будем очень благодарны любой помощи.

Далее следует код (хотя он был «анонимизирован» с конкретных страниц, которые я использовал):

<IfModule mod_rewrite.c>
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !filename\.html$
RewriteCond %{HTTP_REFERER} ^http://online\.webpage\.com.* [NC]
RewriteRule (.*) http://www.wallsofthecity.net/year/mo/filename.html [L]
</IfModule>

Как я уже сказал, RewriteRule работает прекрасно, но первый RewriteCond, кажется, не помечается, когда он находится на соответствующей странице, и просто продолжает перенаправлять людей, до тошноты. Я использовал этот сайт: http://rexswain.com/httpview.html, чтобы проверить свой код. , и хотя он был полезен, он не дал мне хороших ответов.

Спасибо за любую помощь, которую вы можете предоставить.

ОБНОВИТЬ:

Итак, вот файл .htacces целиком, так как это может упростить задачу:

<IfModule mod_rewrite.c>
RewriteEngine On

# Force an external redirect to this page for referrals from that site
# This page *must* exist to prevent a loop (which it does, I checked :P)
RewriteCond %{HTTP_REFERER} ^http://mikeb302000\.blogspot\.com.* [NC]
RewriteCond %{REQUEST_URI} !=/2010/04/cruisin-for-a-bruisin.html
RewriteRule . /2010/04/cruisin-for-a-bruisin.html [R,L]

# This scenario performs no rewrite, so it should actually just be handled by
# the RewriteConds below (they won't match), but I didn't test that
RewriteCond %{REQUEST_URI} ^/(stats|failed_auth\.html).*$ [NC]
RewriteRule . - [L]

Redirect permanent /index.xml http://www.wallsofthecity.net/feed/
Redirect permanent /rss.xml http://www.wallsofthecity.net/feed/
Redirect permanent /atom.xml http://www.wallsofthecity.net/feed/atom/
Redirect permanent /12_tribes http://www.wallsofthecity.net/category/12-tribes
Redirect permanent /as_i_say_not_do http://www.wallsofthecity.net/category/as-i-say-not-do
Redirect permanent /bigotry_exposed http://www.wallsofthecity.net/category/bigotry-exposed
Redirect permanent /commercial_appeal http://www.wallsofthecity.net/category/commercial-appeal
Redirect permanent /cowardice_on_parade http://www.wallsofthecity.net/category/cowardice-on-parade
Redirect permanent /crosscountry_jaunt http://www.wallsofthecity.net/category/crosscountry-jaunt
Redirect permanent /digital_real_estate http://www.wallsofthecity.net/category/digital-real-estate
Redirect permanent /fools_and_jesters http://www.wallsofthecity.net/category/fools-and-jesters
Redirect permanent /for_hire http://www.wallsofthecity.net/category/for-hire
Redirect permanent /me_myself_and_i http://www.wallsofthecity.net/category/me-myself-and-i
Redirect permanent /musings_of_a_madman http://www.wallsofthecity.net/category/musings-of-a-madman
Redirect permanent /one-line_review http://www.wallsofthecity.net/category/one-line-review
Redirect permanent /patron_polity_of_perforation http://www.wallsofthecity.net/category/patron-polity-of-perforation
Redirect permanent /peoples_republic_of_kalifornistan http://www.wallsofthecity.net/category/peoples-republic-of-kalifornistan
Redirect permanent /sensor_ping http://www.wallsofthecity.net/category/sensor-ping
Redirect permanent /serenity http://www.wallsofthecity.net/category/serenity
Redirect permanent /simon_jester http://www.wallsofthecity.net/category/simon-jester
Redirect permanent /the_funnies http://www.wallsofthecity.net/category/the-funnies
Redirect permanent /the_mat http://www.wallsofthecity.net/category/the-mat
Redirect permanent /things_that_go_boom http://www.wallsofthecity.net/category/things-that-go-boom
Redirect permanent /toysgizmosgadgets http://www.wallsofthecity.net/category/toysgizmosgadgets
Redirect permanent /urk http://www.wallsofthecity.net/category/urk
Redirect permanent /window_on_the_world http://www.wallsofthecity.net/category/window-on-the-world

</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Примечание: он по-прежнему не работает. Тестируйте :).


infinite-loop redirect .htaccess
person user378568    schedule 29.06.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

RewriteCond %{REQUEST_FILENAME} !^.*filename\.html$

Я думаю, что Apache не должен заставлять совпадение начинаться с начала строки, но если это произойдет (по какой-либо причине) и если это является причиной вашей проблемы, это изменение исправит ее.

В качестве альтернативы просто полностью отмените первое условие перезаписи и измените правило перезаписи на

RewriteRule !year/mo/filename.html http://www.wallsofthecity.net/year/mo/filename.html
person David Z    schedule 29.06.2010
comment
Спасибо за попытку, Дэвид, но ни один из них, кажется, не работает. Если это дает какую-либо информацию вам или кому-либо еще, вышеуказанный инструмент указывает, что заголовки возвращают Location:wallsofthecity.net/year/mo/filename.html для каждого повторного перенаправления, и этот адрес местоположения перенаправляет браузеры... даже если браузеры уже могут быть на этой странице. ... Что меня смущает :). - person user378568; 29.06.2010
comment
@linoge: я подумал, что это будет то, что происходит, хотя это кажется немного странным, поскольку Apache должен удалить часть http://www.wallsofthecity.net. В любом случае, я должен задаться вопросом, есть ли другие RewriteRule, которые мешают этим. - person David Z; 29.06.2010
comment
О, подождите, я обновил свой RewriteRule, удалив косую черту в шаблоне, поскольку вы не включаете ее в файлы .htaccess. Попробуйте обновленную версию и посмотрите, работает ли она. (Если нет, то какую версию Apache вы используете?) - person David Z; 29.06.2010
comment
После этой последовательности есть правила перезаписи, но не раньше, и должен ли тег [L] мешать файлу .htaccess двигаться дальше? Снял ведущую косую черту, без радости. При условии полного адреса, никакой радости. И Dreamhost, в своей бесконечной мудрости, похоже, установил для ServerTokens значение Prod, поэтому я не совсем уверен, какую версию Apache я использую :). - person user378568; 29.06.2010
comment
[L] останавливает применение каких-либо дальнейших правил к текущему запросу, но если Apache создает внешнее перенаправление (именно это похоже на то, что вы делаете) или подзапрос, весь процесс начинается снова с самого начала, поэтому флаг [L] может не быть всей историей. Должно быть что-то происходит где-то в конфигурации, потому что измененный RewriteRule, который я вам дал, практически является эквивалентом mod_rewrite для while (a) a=false; (я имею в виду, что он не должен вызывать цикл сам по себе, и должно быть очевидно, что он может это сделать). т). Было бы полезно, если бы у нас был фактический URL-адрес для запуска тестов. - person David Z; 29.06.2010
comment
Да, и чтобы найти версию Apache, проверьте веб-сайт поддержки Dreamhost или попробуйте запустить httpd -v в командной строке. (Возможно, вам придется попробовать некоторые варианты, такие как /usr/sbin/httpd -v или /usr/sbin/apache2 -v и т. д.) - person David Z; 29.06.2010
comment
Ах... Не знал, что флаг [L] не завершает все упражнение - на самом деле в .htaccess было три других экземпляра mod_rewrite, и это могло быть проблемой. ... Вот только я объединил все это в одно, и оно все равно не работает. Фактические URL-адреса и конкретная информация из всего файла .htaccess приведены выше, хотя я все еще не могу выманить версию Apache из Dreamhost. На их странице поддержки указано, что у них установлено много версий, хотя это может быть бесполезно. - person user378568; 30.06.2010
comment
вздох... хорошо, я подумаю об этом и прокомментирую здесь, если у меня появятся новые идеи. Такого рода проблемы довольно сложно отлаживать удаленно - обычно в конце концов это достигается путем проб и ошибок в сочетании с подробными ссылками на документацию mod_rewrite. - person David Z; 30.06.2010
comment
Это то, чего я боялся - я провел последние несколько дней, меняя отдельные символы, чтобы увидеть, помогло ли это, сохраняя, проверяя, меняя что-то еще, сохраняя, проверяя ... Спасибо за ту помощь, которую вы оказали - я был надеясь, что я сделал что-то глупое и очевидное, честно :). - person user378568; 30.06.2010
comment
Хорошо, что ж... Мне удалось подключиться к вашему сайту и воспроизвести проблему. Он не предлагал никакого волшебного решения, но я бы посоветовал вам проверить все журналы, к которым у вас есть доступ, и посмотреть, есть ли там какая-либо соответствующая информация. Может быть, спросите людей Dreamhost, есть ли способ, которым они могут включить регистрацию перезаписи. Кроме того, вы можете попробовать просто удалить строку RewriteBase и посмотреть, изменит ли это что-нибудь. - person David Z; 30.06.2010
comment
Вот самые последние журналы, касающиеся перенаправления: 69.36.187.33 - - [29/Jun/2010:15:38:32 -0700] GET / HTTP/1.1 302 533 mikeb302000.blogspot.com Mozilla/4.0 (совместимо; MSIE 8.0; Windows NT 6.0; Trident/4.0;) 69.36.187.33 - - [29/Jun/2010:15 :38:32 -0700] GET /2010/04/cruisin-for-a-bruisin.html HTTP/1.1 200 533 mikeb302000 .blogspot.com Mozilla/4.0 (совместимо; MSIE 8.0; Windows NT 6.0; Trident/4.0;) Журналы ошибок для перенаправлений не создавались, и удаление RewriteBase, похоже, ничего не дало. Я пропингую DH и посмотрю, что они скажут. - person user378568; 30.06.2010
comment
Это странно... опубликованная вами выдержка из журнала показывает, что запрос для /2010/04/cruisin-for-a-bruisin.html вернул код состояния 200 (ОК), а не 302 (временное перенаправление), что говорит о том, что это сработало, но опять же, я просто снова попробовал свой тест, и проблема осталась. Возможно, люди из Dreamhost смогут это понять, поскольку у них есть доступ ко всем конфигурациям сервера и они могут видеть, есть ли что-то еще, что может мешать вашим правилам перезаписи. - person David Z; 30.06.2010
comment
Так что Dreamhost не был таким уж полезным, но они подтвердили, что используют Apache 2.2. Кроме того, они не предложили никаких полезных предложений, кроме того, что отладка кода - это не наша работа :). - person user378568; 01.07.2010

arrow_upward
0
arrow_downward

Редактировать: давайте попробуем вместо этого (удалено предыдущее, чтобы ограничить длину сообщения):

Внешнее перенаправление:

RewriteEngine On

# Force an external redirect to this page for referrals from that site
# This page *must* exist to prevent a loop (which it does, I checked :P)
RewriteCond %{HTTP_REFERER} ^http://mikeb302000\.blogspot\.com.* [NC]
RewriteCond %{REQUEST_URI} !=/2010/04/cruisin-for-a-bruisin.html
RewriteRule . /2010/04/cruisin-for-a-bruisin.html [R,L]

# This scenario performs no rewrite, so it should actually just be handled by
# the RewriteConds below (they won't match), but I didn't test that
RewriteCond %{REQUEST_URI} ^/(stats|failed_auth\.html).*$ [NC]
RewriteRule . - [L]

# With an external redirect, the first RewriteCond catches our referrer redirect
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# These are always evaluated after mod_rewrite stuff, but use the original
# REQUEST_URI unless we explicitly passed it through to handlers later in
# the chain (via the PT flag)
Redirect permanent ... (trimmed)

Внутреннее перенаправление:

RewriteEngine On

# Force an external redirect to this page for referrals from that site
# This page *must* exist to prevent a loop (which it does, I checked :P)
RewriteCond %{HTTP_REFERER} ^http://mikeb302000\.blogspot\.com.* [NC]
RewriteCond %{REQUEST_URI} !=/2010/04/cruisin-for-a-bruisin.html
RewriteRule . /2010/04/cruisin-for-a-bruisin.html [L]

# This scenario performs no rewrite, so it should actually just be handled by
# the RewriteConds below (they won't match), but I didn't test that
RewriteCond %{REQUEST_URI} ^/(stats|failed_auth\.html).*$ [NC]
RewriteRule . - [L]

# With an internal redirect, we have to do an extra check to prevent this rewrite
# with our referrer redirect
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond $0 !-f
RewriteRule .* /index.php [L]

# These are always evaluated after mod_rewrite stuff, but use the original
# REQUEST_URI unless we explicitly passed it through to handlers later in
# the chain (via the PT flag)
Redirect permanent ... (trimmed)

Изменить (еще раз):

Давайте также попробуем провести небольшую диагностику... Можете ли вы поместить это над другими вашими правилами в файле .htaccess?

RewriteCond %{QUERY_STRING} diagnostic
RewriteRule . /?ref=%{HTTP_REFERER}&uri=%{REQUEST_URI}&matchable=$0 [R,L]
person Tim Stone    schedule 29.06.2010
comment
вздох Кажется, это тоже не работает. Поможет ли / имеет ли значение, что эта веб-страница размещена на Dreamhost? Есть ли какая-то глобальная функция/переменная, на которую я должен обратить внимание/искать? - person user378568; 29.06.2010
comment
Хм... Насколько я знаю, в Dreamhost нет ничего особенно причудливого, но лично я им никогда не пользовался, так что не могу сказать наверняка. Просто чтобы быть уверенным, где находится ваш файл .htaccess, и это единственное место, где есть RewriteRule? Где-то должно быть объяснение, хех. - person Tim Stone; 29.06.2010
comment
Файл .htaccess находится в корневом каталоге веб-страницы. После приведенного выше кода идет целая длинная строка постоянных команд Redirect в отдельном объявлении RewriteEngine On (чтобы компенсировать переход с MovableType на Wordpress и разрыв ссылок), а затем этот код: RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] Должен ли первый тег [L] не останавливать файл .htaccess до этого? (Там есть разрывы строк, я просто не могу заставить их придерживаться.) - person user378568; 29.06.2010
comment
Ах я вижу. Действительно ли path/to/filename.html указывает на реальный файл, или вы предполагаете, что он будет обрабатываться WordPress? L останавливает применение правил перезаписи до того, как mod_rewrite отправит новый URL-адрес в качестве внутреннего перенаправления в Apache. Поскольку ваше внутреннее перенаправление указывает на ту же иерархию каталогов, .hatccess снова оценивается при обработке этого нового запроса. - person Tim Stone; 29.06.2010
comment
Он указывает на честный файл, хотя, похоже, он не приносит мне много пользы. Теперь, когда я знаю, что [L] останавливается только внутри каждого вызова mod_rewrite, я сжал три отдельные функции mod_rewrite... но даже это не кажется эффективным решением. - person user378568; 30.06.2010
comment
Хорошо, это также работает на моем тестовом сервере (и я заметил определенную причину, по которой раньше это вызывало бесконечный цикл, так что будем надеяться, что на этот раз это работает лучше...) - person Tim Stone; 30.06.2010
comment
Хорошо, теперь я в некоторой растерянности... Я только что проверил два из них, и хотя первый ничего не делает (например, без перенаправления, без бесконечного цикла, ничего), последний в конечном итоге превращается в ошибка 500. И я понятия не имею, почему. Это превращается в большую боль, чем оно, вероятно, того стоит... извините :(. - person user378568; 01.07.2010
comment
Серьезно? Я начинаю думать, что Dreamhost может быть порталом в ад... Но это интересно, так что я готов продолжать в том же духе, пока вы. Я видел, что у вас есть доступ к журналам доступа, вы также можете получить доступ к журналам ошибок? Мне любопытно посмотреть, как ему удалось не соответствовать правилам в первом, поскольку, похоже, именно это и произошло, поэтому, если бы вы могли попытаться найти записи из того места, где вы его тестировали, это могло бы помочь. - person Tim Stone; 01.07.2010
comment
Я также добавил вещь, которая может помочь диагностировать, что происходит. Это позволит мне увидеть, какие переменные, которые мы проверяем, назначены, но никоим образом не должно нарушать нормальный трафик. - person Tim Stone; 01.07.2010
comment
Ну, если ты за это, то я за :). Без приведенного выше кода отладки вот отчет об ошибке для второго фрагмента кода: [Среда, 30 июня, 17:48:52 2010] [ошибка] [клиент 69.36.187.33] Запрос превысил ограничение в 10 внутренних перенаправлений из-за вероятной конфигурации. ошибка. Используйте «LimitInternalRecursion», чтобы увеличить лимит, если это необходимо. Используйте отладку LogLevel, чтобы получить обратную трассировку. Источник ссылки: mikeb302000.blogspot.com. С этим установленным кодом отладки, что я должен искать? - person user378568; 01.07.2010
comment
Можете ли вы заменить .htaccess в своем вопросе на то, что есть сейчас, с кодом отладки и всем остальным? Я пошел дальше и создал ссылку для запуска диагностического материала, как если бы я пришел с сайта, который вы хотите перенаправить, и, похоже, что-то не так в том, что происходит, когда он все обрабатывает. После того, как вы скопируете его в свой вопрос, вы можете удалить часть отладки, она нам больше не понадобится, а затем я разберусь, как, черт возьми, это могло происходить. - person Tim Stone; 01.07.2010
comment
Итак, я заметил, что если вы перейдете на wallsofthecity.net/2010/04 (с косая черта, которую SO скрывает... это существующий каталог), он перенаправляет вас на wallsofthecity.net/2010 /04, который обрабатывается WordPress. Но в вашем файле .htaccess определенно нет ничего, что делало бы это (это не происходит на моем тестовом сервере с тем же файлом), поэтому это должно происходить где-то еще. Есть ли где-нибудь в панели управления DH такие вещи? В этот момент я думаю, что что-то внешнее по отношению к файлу должно быть каким-то образом задействовано. - person Tim Stone; 03.07.2010
comment
Хм. Проведя небольшое исследование, я обнаружил, что это продукт определенного плагина кэширования, который я установил на WP. Отключение этого, кажется, не решает проблему. Аналогичным образом, отключение другого плагина, который останавливает перенаправление, похоже, также не решило проблему. Обновлена ​​копия-вставка выше, но приведенный выше код просто обслуживает домашнюю страницу (по запросу), независимо от реферера. Я думаю, мы сужаем его... :) - person user378568; 03.07.2010
comment
И прежде чем вы спросите, да, я отключил все соответствующие плагины, которые могли бы внести свой вклад, и это все равно не работало. - person user378568; 03.07.2010