Ich richte eine Website ein aufOpenShift. Es läuft unter Apache 2.2.15, aber ich habe keinen Zugriff auf das Apache-Stammverzeichnis oder die Protokolle, also versuche ich, virtuelle Verzeichnisse in einer .htaccess-Datei im Stammverzeichnis meiner Site zu emulieren. Das meiste davon funktioniert gut, aber es gibt ein Umleitungsproblem, das ich nicht lösen kann.
Die Seite ist wie folgt aufgebaut:
app-root/repo- das Site-Stammverzeichnis, in dem sich die .htaccess-Datei befindet
app-root/repo/Domänenbeispiel
app-root/repo/Domänenbeispiel/main- Hauptwebsite (WordPress)
In WordPress befindet sich mein Blog unter www.example.com/blog, aber vor der Migration zu WordPress hatte ich mehrere Artikel in einer Subdomain blogs.example.com. Um Links beizubehalten, habe ich in .htaccess Umleitungsbefehle eingerichtet. Sie funktionierten bei meinem alten Shared-Hosting-Anbieter einwandfrei. Sie funktionierten sogar bei OpenShift einwandfrei.VorIch habe www.example.com als OpenShift-Alias hinzugefügt. Seitdem ich den Alias hinzugefügt habe, kann ich .htaccess jedoch nicht mehr zwingen, www. zurückzugeben, wenn der ursprüngliche Hostname mit Blogs beginnt.
Von den ApachenUmleitungsdokumentation:
Die neue URL sollte eine absolute URL sein, die mit einem Schema und einem Hostnamen beginnt. In Apache HTTP Server 2.2.6 und höher kann auch ein URL-Pfad verwendet werden, der mit einem Schrägstrich beginnt. In diesem Fall werden das Schema und der Hostname des aktuellen Servers hinzugefügt. Dann gibt jede Anfrage, die mit einem URL-Pfad beginnt, eine Umleitungsanfrage an den Client an der Position der Ziel-URL zurück.
Was ich erwarte:Wenn ich eine absolute URL als Ziel angebe, sollte die Umleitung diese URL an den Client zurückgeben. Der Client kann dann seine Anfrage unter Verwendung der richtigen URL erneut stellen.
Was passiert:Die Umleitung findet statt (ich sehe die 302 in Firebug), aber sie zeigt auf die Quelldomäne, nicht auf das Ziel. Es ist, als würde es den zweiten Teil ausführen (unter Verwendung des „Schemas und Hostnamens des aktuellen Servers“), obwohl ich eine absolute URL angegeben habe.
Hier ein Auszug meiner .htaccess:
Options +FollowSymLinks -MultiViews
RewriteEngine On
RewriteBase /
# This section from https://my.bluehost.com/cgi/help/347#redirect
RewriteCond %{HTTP_HOST} ^(www.)?example\.com$
RewriteCond %{REQUEST_URI} !^/domain_example/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /domain_example/main/$1
RewriteCond %{HTTP_HOST} ^(www.)?example\.com$
RewriteRule ^(/)?$ domain_example/main/index.php [L]
# blogs.example.com redirects
redirect 302 /mark/post/Check-Windows-Time-Settings.aspx http://www.example.com/blog/2010/05/check-windows-time-settings/
Mit dieser .htaccess, wenn ich browse zuhttp://blogs.example.com//mark/post/Check-Windows-Time-Settings.aspxund sehe mir die Antwort in Firebug an. Ich sehe, dass die 302-Umleitunghttp://blogs.example.com/blog/2010/05/check-windows-time-settings/. Aber das existiert nicht, also bekomme ich eine 404-Meldung „Nicht gefunden“.Warum geht es zu Blogs, wenn ich ihm sage, es soll zu www. gehen?
Ich habe mich gefragt, ob der OpenShift-Alias die Weiterleitung irgendwie überschreibt, aber laut der Weiterleitungsdokumentation:
Umleitungsdirektiven haben Vorrang vor Alias- und ScriptAlias-Direktiven, unabhängig von ihrer Reihenfolge in der Konfigurationsdatei.
Ich habe außerdem versucht, eine explizite Falle hinzuzufügen und einen Pfad neu zu schreiben, der mit blogs.example.com/blog/ beginnt (was die Umleitung anscheinend zurückgibt):
RewriteCond %{HTTP_HOST} ^blogs\.example\.com/blog/ [NC]
RewriteRule ^(.*)$ http://www.example.com/blog/$1 [L,R=302]
Ich bekomme immer noch die 404 Not Found-Meldung. Tatsächlich ist sogar die einfachste URL,http://blogs.example.com/blog/, ergibt eine 404.
Wie kann ich in dieser Situation Weiterleitungen zum Laufen bringen?
Update 27. Mai 2015 #1
Habe versucht, im Rewrite-Block die „Nicht“-Logik zu verwenden:
RewriteCond %{HTTP_HOST} !^www\.example\.com/blog/ [NC]
RewriteRule ^(.*)$ http://www.example.com/blog/$1 [L,R=302]
Dies führt zu einer unendlichen Umleitungsschleife, 20 Umleitungen, bevor es aufgibt. Jede Umleitung beginnt immer noch mithttp://blogs.example.comalso etwas verhindert immer noch, dass die RewriteRule das „www“ an den Anfang der URL schreibt.
Dieselben Ergebnisse, wenn ich die NOT-Logik mit einem beende $:
RewriteCond %{HTTP_HOST} !^www\.example\.com/blog/$ [NC]
RewriteRule ^(.*)$ http://www.example.com/blog/$1 [L,R=302]
Update 27. Mai 2015 #2
@Quasidynamic wies darauf hin, dass %(HTTP_HOST) nur den Hostnamen und nichts danach enthält. Also habe ich versucht, nur URLs auszuwählen, die mit beginnen www.example.com/blog:
RewriteCond %{HTTP_HOST} ^blogs\.example\.com$ [NC]
RewriteCond %{REQUEST_URI} ^/blog/$ [NC]
RewriteRule ^(.*)$ http://www.example.com/blog/$1 [R=302,L]
Keine Endlosschleife, aber die Umleitung geht immer noch an blogs., dann kann das Umschreiben es nicht an senden www..
Update 28. Mai 2015
Auf Anfrage von @Quasidynamic versuche ich diesen Block:
RewriteCond %{HTTP_HOST} ^blogs\.example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/blog/$1 [R=302,L]
blogs.example.comWie mittlerweile zu erwarten, wird beim Navigieren zu zu umgeleitet blogs.example.com/blog/. Da dies immer noch mit RewriteCond übereinstimmt, wird zu umgeleitet blogs.example.com/blog/blog/. Ad infinitum. Es geht nie, nie zu www.example.com, und das ist das Grundproblem, das ich von Anfang an hatte: Nachdem ich blogs.example.comals OpenShift-Subdomäne hinzugefügt habe, kann ich nicht mehr .htaccess verwenden, um zu umzuleiten, www.example.comegal, was ich versuche.
Antwort1
Wenn Ihr [alt] blogs.example.com und [Ziel] www.example.com/blog ist:
RewriteCond %{HTTP_HOST} blogs.example.com$ RewriteRule ^(.*)$ http://www.example.com/blog/$1 [R=301,L]
Sie waren nah dran, haben aber versucht, eine Zuordnung von /blog zur Anfrage herzustellen, die nicht vorhanden ist. So wie ich Ihre Situation verstehe, ist das nur auf der [Ziel-]Site vorhanden.
Verwenden Sie den Code 301 - „Status 301 bedeutet, dass die Ressource (Seite) dauerhaft an einen neuen Standort verschoben wurde. Der Client/Browser sollte nicht versuchen, den ursprünglichen Standort anzufordern, sondern von nun an den neuen Standort verwenden.“ von
https://stackoverflow.com/questions/1393280/http-redirect-301-permanent-vs-302-temporary