.htaccess leitet nicht ordnungsgemäß zur Seite mit dem Präfix www um


9

Ich versuche, eine URL ohne www umzuleiten. zu www.version (example.com zu www.example.com). Ich benutze das übliche

RewriteCond %{HTTP_HOST} ^example\.com [nc]
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

Dies funktioniert bei allen meinen anderen Projekten. Auf dieser speziellen Site endet sie jedoch mit einer Umleitungsschleife. Hier ist der seltsame Teil: Ich habe versucht, die Nicht-WWW-Version zu locken, um zu sehen, welche Header sie sendet curl --get http://example.com --dump-header domain.header > domain.html. Die Header-Datei sah folgendermaßen aus:

HTTP/1.1 301 Moved Permanently
Date: Mon, 06 Jun 2011 14:45:16 GMT
Server: Apache/2.2.16 (Debian)
Location: http://example.com/
Vary: Accept-Encoding
Content-Length: 310
Content-Type: text/html; charset=iso-8859-1

Die resultierende HTML-Datei war jedoch folgende:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.example.com/">here</a>.</p>
<hr>
<address>Apache/2.2.16 (Debian) Server at example.com Port 80</address>
</body></html>

(Beachten Sie den Adressunterschied zwischen den Dateien.) Weiß jemand, wie man das behebt (und was zum Teufel es verursacht)? Alle anderen Anweisungen zum Umschreiben von URLs funktionieren einwandfrei.

BEARBEITEN: Das Umschreibungsprotokoll enthielt Folgendes: (Auf die Site wird von vielen Personen zugegriffen, sodass das Umschreibungsprotokoll ziemlich lang wurde. Ich bin nicht 100% sicher, ob dies der richtige Teil ist.)

192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (3) [perdir /var/www/oup/81/] strip per-dir prefix: /var/www/oup/81/ ->
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (3) [perdir /var/www/oup/81/] applying pattern '(.*)' to uri ''
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (2) [perdir /var/www/oup/81/] rewrite '' -> 'http://www.example.com/'
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (2) [perdir /var/www/oup/81/] explicitly forcing redirect with http://www.example.com/
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (1) [perdir /var/www/oup/81/] escaping http://www.example.com/ for redirect
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (1) [perdir /var/www/oup/81/] redirect to http://www.example.com/ [REDIRECT/301]

Die Zugriffsprotokollzeile (wahrscheinlich die richtige):

192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] "GET / HTTP/1.1" 301 555 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.77 Safari/534.24"

Die Definition des virtuellen Hosts:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName example.com
        ServerAlias example.com www.example.com
        DocumentRoot /var/www/example/
        <Directory />
                Options FollowSymLinks
                AllowOverride All
        </Directory>
        <Directory /var/www/example/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride All
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

EDIT2: Okay, ich habe gerade herausgefunden, dass wenn ich das tue (zurückgetreten und versucht, dies ohne .htaccess umzuleiten):

//if clause determining that we're running on example.com and not www.example.com
header('HTTP/1.1 301 Moved Permanently');
header('Location: http://www.example.com' . $_SERVER['REQUEST_URI']);
header('Connection: close');

Es verursacht genau die gleiche Umleitungsschleife. Ernsthaft, was zur Hölle? Hat jemand eine Idee, was dies möglicherweise verursachen könnte?


Haben Sie Apache selbst kompiliert oder? Es sollte unmöglich sein, dass sich der Location-Header von den Angaben auf der Seite unterscheidet, da sie in diesem Fall aus derselben Variablen stammen. Das ist also ziemlich seltsam. Ich gehe davon aus, dass die Anfragen direkt an Apache weitergeleitet werden, richtig, da sitzt kein anderer Server dazwischen?
Tim Stone

Ich habe Apache nicht selbst kompiliert und es gibt keinen anderen Server dazwischen.

wahrscheinlich ist Ihr NS-Server nicht richtig konfiguriert
venimus

4
Es ist nicht erforderlich, den Servernamen im ServerAlias-Eintrag zu wiederholen.
Chris

können Sie den gesamten Inhalt der Datei hier setzen
rückgängig gemacht

Antworten:


2

Was mir seltsam vorkommt, ist die Location: http://domain.cz/von CURL gemeldete Kopfzeile. Sie leiten niemals zu dieser Domain weiter. Das Umleitungsprotokoll enthält auch keine Erwähnung.

Irgendwie Locationscheint der Header geändert zu werden, nachdem Modrewrite seine Arbeit erledigt hat, und da Sie versucht haben, den Header auch mit PHP zu ändern, wird der LocationHeader anscheinend geändert, nachdem die Anforderung verarbeitet wurde. Die einzige Erklärung, die mir einfällt, ist, dass Sie den Speicherort-Header irgendwo mit mod_header ändern.

Haben Sie alle Konfigurationsdateien (httpd.conf, die enthaltenen .conf-Dateien und die .htaccess-Datei) überprüft, wenn Sie irgendwo eine ähnliche Zeile gefunden haben:

Header set Location (...)

oder

Header edit Location (...)

Ich habe so etwas nicht gefunden.

2
Stellen Sie eine direkte Verbindung zu Apache her oder gibt es dazwischen einen Caching- oder Proxyserver, der die Header ändern könnte? Die ProxyPassReverse-Direktive kann auch den Speicherortheader ändern ( httpd.apache.org/docs/2.0/mod/mod_proxy.html#ProxyPassReverse ).

Dazwischen könnte es einen Proxy geben, ich werde es mir ansehen, sobald ich morgen zur Arbeit komme.

@ Jakob Egger - Ich habe nirgendwo die ProxyPassReverse-Direktive gefunden.
Chiffre

1

Zusätzlich zum Aktivieren des Umschreibprotokolls (wenn Sie Zugriff auf die Änderung der httpd.conf haben) sollten Sie die Anwendung, die sich auf dieser Site befindet, aus der Gleichung entfernen. Entfernen / benennen Sie die Standard-index.php (oder die Indexseite, die Ihre App bedient) vorübergehend um, um sicherzustellen, dass dies nicht verursacht wird.

Es gibt viele Berichte über Anwendungen (z. B. WordPress), die dazu führen, dass diese Apache-Standardumleitungsseite angezeigt wird, wenn sie falsch konfiguriert sind.

Überprüfen Sie auch den Rest der Apache-Konfiguration, um festzustellen, ob andere Umleitungsanweisungen vorliegen, die möglicherweise in Konflikt stehen.


Die Anwendung ist in Ordnung, ich habe es auf einem anderen Server und einer anderen Domäne versucht (die gesamte App kopiert) und es hat in Ordnung funktioniert. Ich denke, es ist etwas in der Apache-Konfiguration, aber ich kann nicht herausfinden, was.

Die App ist möglicherweise in Ordnung, steht jedoch möglicherweise auch im Widerspruch zum Setup auf diesem Server. Es hört sich so an, als ob Ihre App derzeit in Produktion ist, sodass ich sehen kann, dass das Deaktivieren nicht ideal ist. Zum Spaß können Sie am Ende der Umleitung eine Abfragezeichenfolge als Flag hinzufügen, um die Erkennung zu erleichtern - also / $ 1? Nowww = 1 oder ähnliches.
Gavin C

Nein, es ist NICHT in Produktion.

Oh cool, dann kann es nicht schaden, die Indexdatei aus dem Weg zu räumen, um sie zu 100% als Teil des Problems auszuschließen :)
Gavin C

Oh, verdammt, was bedeutete , dass ich zu schreiben war , dass tis in Produktion ist, weiß nicht , wie diese happenned :-)

0

Können Sie diesen alternativen mod_rewrite-Code ausprobieren:

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Dies schlug genauso fehl.

Können Sie RewriteLog aktivieren und sehen, was es ausspuckt?
Anubhava

Und wie genau kann ich das machen? :-)

Siehe hier: httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewritelog Das einzige ist, dass diese Direktive in die Apache-Konfiguration geht, NICHT in .htaccess.
Anubhava

1
Ich habe dieselbe Regel (wie meine Antwort oben) in meine Apache-Installation kopiert und denselben Curl-Befehl ausgeführt, den Sie in Ihrer Frage haben, und Location: http://www.domain.com/als Teil meiner Header erhalten, sodass in meinem Fall sowohl Header als auch HTML dieselbe Domain anzeigen, d www.domain.com. H. Können Sie in Ihrer obigen Frage auch relevante access.log-Zeilen einfügen?
Anubhava

0

Könnten Sie versuchen, [NC] anstelle von [nc] zu verwenden, könnte so einfach sein


Und doch ist es nicht :-) (bereits ausprobiert, hat nicht funktioniert)

0

Ich hoffe, Sie haben Serverzugriff. Die Umleitungszeile wurde hinzugefügt, nachdem der angegebene Site-Dokumentordner gefolgt wurde

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain\.cz [NC]
RewriteRule ^/(.*) http://www.domain.cz/$1 [L,R=301]

Wenn Sie keinen Zugriff für den Server haben, fügen Sie diese Zeile bei httaccess hinzu, indem Sie den Teil starten / ändern.

Möglicherweise haben Sie vor der Umleitung noch nicht "RewriteEngine on" hinzugefügt.


Ich habe hinzugefügt RewriteEngine on, wie gesagt, es funktioniert auf einem anderen Server richtig, nur nicht auf diesem.

AllowOverride All erlaubt von allen, diese Zeilen in Ihre Server-Konfigurationsdatei

0

Versuchen:

RewriteCond %{HTTP_HOST} ^domain.cz [NC]
RewriteRule (.*) http://www.domain.cz/$1 [R=301,L]

0

Stellen Sie sicher, dass Options +FollowSymLinksSie in einem Verzeichniskontext arbeiten.

Andernfalls versuchen Sie Folgendes, wenn Sie namensbasierte virtuelle Hosts verwenden:

<VirtualHost *:80>
  ServerName domain.cz
  Redirect / http://www.domain.cz/
</VirtualHost>

<VirtualHost *:80>
  ServerName www.domain.cz
  # whatever else
</VirtualHost>

Ich habe die Frage mit der Definition des VirtualHost aktualisiert.

Haben Sie die oben genannte mehrfache VirtualHost-Lösung ausprobiert oder möchten Sie mod_rewrite verwenden?
Chris

Bei firts wollte ich nicht mehrere VirtualHosts verwenden, aber unter den gegebenen Umständen habe ich es trotzdem versucht und es hat nicht geholfen.

0

Nachdem Sie alle Antworten gelesen haben, können Sie die Datei de / etc / hosts überprüfen ... möglicherweise stammen alle Ihre Überprüfungen von Ihrem Computer. Versuchen Sie, von einem anderen Ort aus darauf zuzugreifen.


Nein, nichts in Hosts über diese Domain.

0

Ich habe eine zweite Idee. Das von Ihnen gepostete Serverprotokoll zeigt eine Adresse von "192.168.1.221", eine Adresse aus dem lokalen Netzwerk. Zeigen alle Protokolleinträge dieselbe IP-Adresse? In diesem Fall besteht ein Proxy zwischen Ihnen und dem Server. Dieser Proxy verwendet ProxyPassReverseoder Header editzum Ändern des LocationHeaders.

Dies ist eine übliche Einrichtung, um das Problem zu umgehen, wenn der Back-End-Server seinen eigenen Hostnamen Locationanstelle des Hostnamens des externen Proxyservers in den Header einfügt.

Wenn es wirklich einen Proxyserver gibt, müssen Sie die Konfiguration des Proxyservers und nicht die Konfiguration des Backend-Servers ändern, da der Proxy die Informationen immer überschreibt.

Dies bedeutet, dass wir die ganze Zeit auf den falschen Server gesucht haben: Das Problem ist mit dem Proxyserver!


Morgen rufe ich den technischen Support des Unternehmens an, das diesen Server betreibt. Ich denke das muss es sein, ich werde es dich wissen lassen.
Chiffre

0

Könnten nicht druckbare Zeichen wie null in der .htaccessDatei sein.

hexdump -C .htaccess

0

Ich glaube, Sie vermissen ein $ -Zeichen nach Ihrer Umschreibungsbedingung. Bitte versuche:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain.cz$
RewriteRule ^(.*)$ http://www.domain.cz/$1 [R=301,L]
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.