2017-01-15 18 views
0

Environment Windows Server 2012 R2 64bit IIS 8 Plesk 12.5Слишком много переадресаций, прерывистая проблема - подозреваемого Rewrite Cache

веб-сайт работает WordPress отвечает прерываемому слишком много переадресаций, но только для определенной URL, и только приблизительно 30 минут. После этого запрашиваемая страница обслуживается как ожидалось. Остальная часть веб-сайта отвечает правильно в течение этого времени, используя те же правила перезаписи.

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

Failed Request Tracing показывает следующее для конкретного URL:

URL_REWRITE_START RequestURL/категория/Референдум-2/

REDIRECT_FROM_CACHE_ACTION CachedRedirectedURL HTTP: // www.website.com/category/ референдум-2/RedirectType Постоянная

URL_REWRITE_END RequestURL http://www.website.com/category/referendum-2/

Это, очевидно, начало бесконечного цикла переадресации.

Когда URL подается правильно Failed Request Tracing показывает:

URL_REWRITE_END RequestURL /index.php

Это, очевидно, верно для WordPress, /index.php обрабатывает все запросы внешнего интерфейса страницы.

Если к запрашиваемому URL добавлена ​​строка запроса, например./category/referendum-2 /? key = значение IIS правильно выполняет запрошенную страницу. Из-за этого я подозреваю, что запрос приводит к тому, что IIS пропускает кеш перезаписи, поскольку кеш вызывает цикл перенаправления.

Я видел сообщение в https://blogs.msdn.microsoft.com/danielvl/2010/01/07/registry-values-for-iis-url-rewrite/, в котором подробно описано, как отключить кеш перезаписи через реестр, но раздел реестра HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ InetStp \ Rewrite не существует. Я не хочу создавать ключ, чтобы увидеть, что происходит в производственной среде.

Может кто-нибудь предложить, если мои подозрения повторно. кеш перезаписи, являющийся причиной цикла перенаправления, является правильным?

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

Благодаря

ответ

0

проблема была решена путем добавления условия к правилу переадресации вызова, ответственного за бесконечный цикл перенаправления с параметром, который не может быть в кэше, таким образом, sidesteping кэш.

<rule name="Imported Rule 2" stopProcessing="true"> 
 
\t <match url=".*" ignoreCase="false" /> 
 
\t <conditions logicalGrouping="MatchAll"> 
 
\t \t <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" /> 
 
\t \t <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" /> 
 
\t </conditions> 
 
\t <action type="Rewrite" url="index.php" /> 
 
</rule>

Изменен

<rule name="Imported Rule 2" stopProcessing="true"> 
 
\t <match url=".*" ignoreCase="false" /> 
 
\t <conditions logicalGrouping="MatchAll"> 
 
\t \t <add input="{REMOTE_PORT}" pattern=".*" /> 
 
\t \t <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" /> 
 
\t \t <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" /> 
 
\t </conditions> 
 
\t <action type="Rewrite" url="index.php" /> 
 
</rule>

Лучшее решение могло бы быть, чтобы обновить frequentHitThreshold и frequentHitTimePeriod в applicationHost.config. Подробнее см. http://www.ckode.dk/server-configuration/tuning-iis-7-for-static-content/

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

  • Нет связанных вопросов^_^