2016-11-09 4 views
0

Сервера Apache 2.4.18, PHP версии 7.0 ...mod_rewrite странно бесконечные рекурсии

Введение: На стороне PHP я rawurlencode ($ имени) при создании HTML ссылки.

REQUEST_URI выглядит следующим образом:

/lang/cat1/cat2/product with bla (this/that) -- works 
/lang/cat1/cat2/product with bla (this/ that) -- infinite internal redirect 

Разница только в одном пространстве это/что против это/что

VirtualHost: 
# I have tried different combinations of 
AllowEncodedSlashes On 
AllowEncodedSlashes NoDecode. 

htaccess: 
<IfModule mod_rewrite.c> 
Options +FollowSymLinks -MultiViews  #different combinations 
RewriteEngine On 


# tried different combinations 
#RewriteCond %{REQUEST_URI} !^/?file\.php$ 
#RewriteCond %{ENV:REDIRECT_STATUS} ^$ 
#RewriteCond %{ENV:REDIRECT_STATUS} !200 
RewriteRule .? file.php [L] # END 
</IfModule> 

Все, что я хочу, это стандартный фронт-контроллер, ВСЕ запросы должны идти в file.php. Это работает в 99,99% случаев. Но ruri с bla/ в нем идет к бесконечным рекурсиям.

Вопросы: Почему это происходит?
Как его решить?

+0

[Включить ведение журнала] (http://httpd.apache.org/docs/current/mod/mod_rewrite.html#logging) на уровнях 'trace8', если вы можете, а затем проверить свои журналы ошибок на посмотрите, что на самом деле происходит. – Walf

+0

DId это. Журнал был полон «рекурсий» – CoR

ответ

0

Вам необходимо раскомментировать свое последнее условие перезаписи.

Try:

<IfModule mod_rewrite.c> 
Options +FollowSymLinks -MultiViews  #different combinations 
RewriteEngine On 


# tried different combinations 
#RewriteCond %{REQUEST_URI} !^/?file\.php$ 
#RewriteCond %{ENV:REDIRECT_STATUS} ^$ 
RewriteCond %{ENV:REDIRECT_STATUS} !200 


# END 
</IfModule> 

В противном случае ваше правило будет перенаправлять /file.php к себе.

На апача 2.4 вы можете просто использовать END флаг для завершения обработки перезаписи:

RewriteEngine on 

RewriteRule .? file.php [END] 
+0

Спасибо. Но я пробовал ВСЕ сочетания комментирования и безрассудства! – CoR

+0

У вас есть другие правила? – starkeen

+0

Да, у меня было много. Затем я удалил их ВСЕ! Я оставил только код, который я показал здесь. И да, я пробовал почти все комбинации [END] [END, L] [L, END], [NE], .... :(Это работало нормально на Apache 2.2 ... – CoR

0

Я нашел решение на другом форуме.
Решение было болезненно простым. Но может помочь кому-то.

Один парень грустно: Be brave, understand that there is nothing wrong with your htaccess! But you still have recursions. So bug is somewhere in php code.

Это разрушила мою HTAccess фиксации позволяет мне погружаться в бизнес и код Fw. Ошибка была обнаружена несколько часов спустя. Одна из функций url имела преждевременный rawurldecode(). Прохладный для ленивой программы, не так классно, если у вас есть продукты с закодированными/именами.

Но ответ на вопрос «Раньше это работало?». также вводил в заблуждение. «Да, конечно. Должно быть, из-за обидной миграции».
Riiight;)

+0

Вы все равно должны устранить источники рекурсия. Главное правило должно быть чем-то вроде «RewriteRule^(?! file \ .php (?: $ | /)) file.php [NS, END]', чтобы предотвратить совпадение уже переписанных URL-адресов. – Walf

+0

Да, исходное правило перезаписи было полностью прекращено. Последнее правило с L или END отлично работает. Ошибка была в преждевременной расшифрованной строке url! Это нарушает целую логику, заставляя fw перенаправлять на «правильный» url, который был преждевременно декодирован, что приводит к перенаправлению на «правильный» URL-адрес, поэтому на. – CoR

+0

Нет, не совсем, просто работает.Рекурсия все еще происходит на этапе перезаписи. Если у Apache не было предела (чтобы остановить такие правила, как эти взломанные серверы), ваше правило никогда не будет служить файлу. Тут вы тратите обработку по каждому запросу. Если бы у вас было лучшее правило для начала, ваши журналы были бы более ясными. – Walf

Смежные вопросы