Zu viele Umleitungen, intermittierende Ausgabe - Verdächtiger Rewrite Cache

Question

Environment Windows Server 2012 R2 64bit IIS 8 Plesk 12.5

Eine Website läuft Wordpress zu viele Umleitungen intermittierend mit reagiert aber nur für bestimmte URLs und nur etwa 30 Protokoll. Danach wird die angeforderte Seite wie erwartet bedient. Der Rest der Website reagiert während dieser Zeit korrekt und verwendet dieselben Umschreibungsregeln.

Eine URL ist besonders betroffen als andere. Es kann wichtig sein zu beachten, dass es auf der Homepage der Website angezeigt wird und über soziale Kanäle geschoben wird.

Anforderungsfehler Tracing zeigt das folgende für eine bestimmte URL:

URL_REWRITE_START RequestURL/Kategorie/Referendum-2/

REDIRECT_FROM_CACHE_ACTION CachedRedirectedURL http: // www.website.com/category/ Abstimmung-2/RedirectType Permanent

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

Dies ist offensichtlich der Beginn einer unendlichen Umleitungsschleife.

Wenn die URL korrekt Anforderungsfehler Tracing zeigt serviert:

URL_REWRITE_END RequestURL /index.php

Das ist offensichtlich richtig für Wordpress, /index.php behandelt alle Frontend-Seite Anfragen.

Wenn der angeforderten URL ein Querystring hinzugefügt wird, z./category/referendum-2 /? key = Wert IIS bedient die angeforderte Seite korrekt. Aus diesem Grund vermute ich, dass der Querystring bewirkt, dass IIS den Rewrite-Cache überspringt, was bedeutet, dass der Cache die Redirect-Schleife verursacht.

Ich habe den Beitrag bei https://blogs.msdn.microsoft.com/danielvl/2010/01/07/registry-values-for-iis-url-rewrite/ ausführlich beschrieben, wie der Umschreib-Cache über die Registrierung deaktiviert wird, aber der Registrierungsschlüssel HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ InetStp \ Rewrite nicht existiert. Ich bin nicht scharf darauf, den Schlüssel zu erstellen, um zu sehen, was in einer Produktionsumgebung passiert.

Kann jemand vorschlagen, wenn mein Verdacht re. der Umschreibe-Cache, der die Ursache für die Umleitungsschleife ist, sind korrekt?

Wenn ja, wie kann ich fortfahren, um das Problem zu lösen? Ich habe Schwierigkeiten, Details über den Redirect-Cache zu finden oder was das Verhalten so verursacht.

Dank

Answer 1

Ausgabe wurde durch Zugabe einer Bedingung für die Weiterleitung der Regel verantwortlich für den Aufruf der unendliche Umleitung Schleife mit einem Parameter aufgelöst, die nicht so den Cache sidesteping zwischengespeichert werden kann.

<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>

zu

Changed

<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>

Eine bessere Lösung könnte die frequentHitThreshold und frequentHitTimePeriod in applicationHost.config zu aktualisieren sein. Einzelheiten siehe http://www.ckode.dk/server-configuration/tuning-iis-7-for-static-content/