Im Zuge der finalen Vorbereitungen zur Bereitstellung von PHP7 wurde am 29. Juni 2016 ein Update der Apache-Webserver durchgeführt. Dadurch hat sich das Verhalten in .htaccess-Dateien teilweise geändert. Welche Anpassungen dadurch nötig sind, haben wir in diesem Blogartikel zusammengefasst.
In der neuen Apache-Version können Redirect-, Redirect Permanent- und RedirectMatch-Regeln nicht mehr mit Flags wie z.B. ([R=301,L]) versehen werden.
Benötigen Sie eine Flag, müssen Sie die Regel durch eine RewriteRule ersetzen:
So wird aus…
Redirect ^/verzeichnis/(.*) https://www.domainname.tld/$1 [R=301,L]
…folgende Regel:
RewriteRule ^verzeichnis/(.*) https://www.domainname.tld/$1 [R=301,L]
Bei einfachen Redirects können Sie den Fehler beheben, indem Sie die Flag entfernen:
Folgender Redirect…
Redirect /dateiname.php https://www.domainname.tld/verzeichnis/dateiname/ [L,R=301]
…wird zu:
Redirect Permanent /dateiname.php https://www.domainname.tld/verzeichnis/dateiname/
Das Flag R=301 entspricht dem „Redirect Permanent“.
Fehlerhafte .htaccess-Dateien finden
Mit folgendem SSH-Befehl können Sie fehlerhafte .htaccess-Datei auf Ihrem Webspace finden:
grep --include=*.htaccess -rnw '.' -ie "Redirect.*\[.*\]" >> redirect_parameter.txt
Danke an den Leserkommentar von Andreas mit dem Hinweis dazu!
Entschuldigung
An dieser Stelle möchten wir uns bei Ihnen entschuldigen, dass Sie keine Vorab-Information erhalten haben. Wir haben das Update in Vorbereitungen für die Bereitstellung von PHP7 durchgeführt, damit wir Ihnen künftig die neuste Version anbieten können.
Wir haben verstanden, dass Sie eine Information gewünscht hätten und möchten Ihnen versichern, dass wir unsere Kommunikation zu solchen Themen (also z.B. Konfigurationsänderungen und Systemupdates wie in diesem Fall) künftig anpassen möchten und Sie per E-Mail informieren werden.
Weitere Artikel zum Thema:
Ist ja nicht unwichtig – warum gabs hier keinen Newsletter?
Der Fehler tritt nur bei wenigen Ausnahmen aus, die meisten .htaccess-Dateien beinhalten diese falschen Anweisungen nicht. Sind Sie betroffen?
Das weiß ich noch nicht…
In Bereich meines Auftrags nicht. Ich arbeite freiberuflich für ein paar andere Menschen, die bei df hosten – da kommen schon ein paar .htaccess-Files zusammen.
Mir geht es aber nicht mal darum, welche Arbeit anfallen wird, sondern ab wann df eine Newsletterbenachrichtigung als relevant erachtet.
Wenn Sie möchten, schicken Sie gern über „Kundenservice“ im Kundenmenü ein Ticket an die Technik, dann sehen wir uns das auf Ihrem Webspace an!
@Anna, 30. Juni, 16:23
Ich sehe schon, wir verstehen uns gänzlich falsch. Ich erledige Aufträge, die unter Anderem auch für Kunden von mir erfüllt werden, die selbst bei df hosten.
Das hat also nichts mit meinem Webspace bei df zu tun, der ist so übersichtlich, dass ich den selbst auf meine Einträge in .htaccess-Dateien prüfen kann.
Nein – bis jetzt habe ich keine Kenntnis davon, dass bei einem meiner Kunden ein Problem entstanden wäre – und wenn, werde ich wegen dieses Beitrags wissen was zu tun ist. Auch mal Danke an dieser Stelle an Sie.
Aber – ich werde redundant: Mir könnte ja entgangen sein, dass ich über diese Neuerung rechtzeitig benachrichtigt wurde – dann: Bitte nichts für ungut.
Andererseits: Mich hat ein Kunde mit der Nase auf diesen Blogbeitrag gestoßen. Wenn df Neuerungen einführt, aber versäumt seine Kunden z.B. wie gewohnt in einem Newsletter davon zu informieren, dann interessiert mich doch immens, wie tief Eingriffe auf den Servern sein müssen, bis bei df dazu eine gewisse Notwendigkeit verspürt, dies auch über Newsletter zu kommunizieren.
Lieber Peter, wenn kein Fehler aufgetreten ist, weshalb werden sie dann so komisch (ich verwende explizit kein schlimmeres Wort, auch wenn es mir auf der Zunge liegt)? Probleme treten sowieso nur auf wenn sie manuell auf Php 7 umgraden. Und auch dann nur wenn sie Redirects verwenden die nicht kompatibel sind.
@Tobias: Das ist nicht ganz richtig. Die potenziellen Probleme entstehen (oder entstanden – diese Diskussion ist ja schon ein paar Tage alt) durch das Apache-Update, nicht durch den Umstieg auf PHP 7 – PHP hat mit .htaccess-Dateien absolut nichts zu tun und wird erst später bei der Abarbeitung eines Requests gestartet, sofern notwendig.
Über den Ton kann man sich streiten – wobei Peter sich meiner Ansicht nach hier aber noch recht zivilisiert verhält. In der Sache würde ich ihm aber auf jeden Fall Recht geben. Ich bin Reseller und zudem im Forum sehr aktiv, bin hierüber damals aber trotzdem mehr zufällig gestolpert. Das ist nicht die Art von Aufklärung, die ich mir bei Änderungen, die eine Site erheblich beeinträchtigen können, wünsche.
Gruß,
Jan
@Tobias (vom 22. Nov. 16)
Sie haben hier zwei Mißverständnisse:
Zum Einen, was PHP und Serverkonfiguration betrifft und zum Anderen wenn Sie in meine Worte etwas hineininterpretieren, was Sie dazu anhalten müsste, ein „explizit schlimmes Wort“ als Antwort zu unterdrücken.
Um was es mir hier eigentlich ging, habe ich oft genug beschrieben. Domainfactory zeigte sich hier kritikfähig und hat bewiesen dass dieses Forum wahr genommen und verstanden wird. Sie leider nicht.
Mit folgendem Befehl lassen sich alle fehlerhaften .htaccess-Files auf dem Server finden:
nohup grep --include=*.htaccess -rnw '.' -ie "Redirect.*\[.*\]" >> redirect_parameter.txt &(Bei uns als ebenfalls betroffener Kunde erfolgreich getestet, Code bisher von dF nicht bestätigt)
Grüße
Andreas
Danke Andreas, wir haben den Beitrag oben aktualisiert! 🙂
Kurze Frage: verstehe ich es richtig, dass das geänderte .htaccess-Verhalten nur Installationen betrifft, welche auch PHP in der Version 7 unterstützen?
Wir haben einige 5.5.x-Installationen, und dort scheinen die Weiterleitungen zumindest wie gewohnt zu funktionieren.
Danke!
Nein, das Webserverupdate betrifft alle .htaccess-Dateien. Es wurde im Zuge der Vorbereitungen für die Einführung von PHP7 in unserem System durchgeführt. Mit dem oben genannten Befehl zur Überprüfung Ihres Webspaces oder den in Andreas‘ Kommentar können Sie ausfindig machen, ob Sie .htaccess-Dateien mit diesen Anweisungen nutzen.
Hallo!
Irgendwie ist das nicht so ganz eindeutig formuliert. D.h. dass man alle Installationen die eine htaccess im Einsatz haben, egal welche PHP-Version da im Einsatz ist prüfen muss?
Viele Grüße aus Karlsruhe,
Dirk
So hab ich es verstanden – es betrifft den neune Apache unabhängig davon, welche PHP-Version angesprochen wird.
Deshalb finde ich es so krass, einfach nur zufällig über diesen Artikel zu stolpern.
Oder habe ich was verpasst und ist tatsächlich doch jemand durch einen Newsletter auf die Umstellung aufmerksam geworden?
Hallo Dirk,
Sie können Ihre Dateien mit dem oben genannten Befehl prüfen. Oder – das gilt natürlich für alle – einfach kurz ein Ticket über Kundenservice im Kundenmenü an unsere Technik schicken, dann prüfen wir das für Sie!
man sollte aber bedenken, dass dieser Befehl nur auftragsweit funktioniert, sobald Quotas im Spiel sind, muss dass pro Quota ausgeführt werden, was es schnell sehr aufwendig machen kann
Völlig klar. Kunden oder Resellern mit sehr vielen Quotas ohne Superuser würde ich empfehlen sich an die Technik zu wenden. Ich würde mal annehmen, dass die Technik in begründeten Einzelfällen diesen Befehl auch als Root über ein komplettes Auftrags-Home ausführt.
Grüße
Andreas
Ja, machen wir natürlich gern.
Ärgerlich, dass es vorab keine Information gab.
So waren seit gestern einige Seiten nicht erreichbar für die munter weiter AdWords geschaltet und gezahlt wurden was heute morgen nur zufällig auffiel.
Die Daten mussten nun händisch gesucht und geändert werden…
Danke hier auch an den Support von df für schnelle und gute Arbeit nach der Ticketgenerierung.
Trotzdem sehr ärgerlich das es hier keine Vorabinfo gab. War ja wohl kein kleines Update.
Tut uns leid, dass Sie davon so negativ betroffen waren. Läuft nun wieder alles oder können wir noch weiterhelfen?
Ich denke soweit läuft alles….
Gibt es weitere Aspekte die aufgrund des Updates zu prüfen wären (Formulare, Scripte etc)?
Nein, da ist uns generell nichts bekannt. Haben Sie mit dem oben genannten Befehl Ihren Webspace durchsucht?
Ehrlich gesagt bin ich ob der verwendeten Syntax ein wenig verwirrt… Laut Apache-Doku kann Redirect keine regulären Ausdrücke verarbeiten, dafür ist RedirectMatch da. Der HTTP-Status wird hinter dem Namen der Direktive angegeben, also z. B. „Redirect permanent“ oder (Spezialfall) „RedirectPermanent“. Flags in eckigen Klammern gibt es dort laut Doku nicht.
Zumindest bisher kann ein regulärer Ausdruck einer RewriteRule hier bei DF nicht mit ^/ beginnen, da dies niemals einen Match ergibt. Der führende Slash, der im REQUEST_URI noch vorhanden ist, wurde bisher vor der Prüfung in einer RewriteRule „abgeschnitten“. Bestenfalls konnte die RegEx mit ^/? beginnen.
Sind das alles undokumentierte Fähigkeiten von mod_alias (http://httpd.apache.org/docs/2.4/mod/mod_alias.html) bzw. Änderungen im Verhalten von RewriteRules bei DF oder ist da ggf. einiges durcheinandergeraten?
Gruß,
Jan
Hi Jan,
wir hatten in einem Fall folgenden Befehl hinterlegt:
RedirectMatch (?i)^/AGB$ /agb.html [L,R=301,NC]Dieser hat so für uns funktioniert. Dass es sich dabei um eine „außerordentliche“ Konfiguration gehandelt hat ist zumindest mir in dem Fall nicht aufgefallen.
Grüße
Andreas
Nun, zumindest habt Ihr RedirectMatch mit einer RegEx genutzt, nicht Redirect… 😉
Zumindest meinen mittleren Absatz solltet Ihr schnell überprüfen, ansonsten kann es sein, dass bei denen, die auf
RewriteRule ^/irgendwas ...umstellen, nichts mehr richtig funktioniert…
Danke für den Hinweis, Jan. Wir haben die Zeile angepasst!
Ich hätte eine Benachrichtigung per E-Mail auch begrüßt, auch wenn ich nicht betroffen gewesen wäre. Solch eine Veränderung kann eine ganze Webseite lahm legen. Btw. aktuell komme ich nicht auf status.df.eu (Weiterleitungsfehler sagt Firefox).
Gruß,
Sepp
P.S.: Es wäre nicht schlecht, wenn man vor solchen Updates rechtzeitig vorgewarnt würde. In der Vergangenheit war das der Fall.
Danke für das Feedback, Sepp. Es tut uns leid, dass Sie – alle, die das hier angemerkt haben – die Information vermisst haben. Für die Zukunft wird das natürlich wieder erfolgen!
Bei der Statusseite gibt es leider gerade eine technische Störung, auch da vielen Dank für den Hinweis!
In diesem Zusammenhang wäre noch ein Hinweis wünschenswert gewesen, zwischen welchen Apache-Version denn gewechselt wird/wurde (und somit welche neuen Features durch die Kunden genutzt werden können). Scheinbar handelt es sich direkt um die neueste Version 2.4.20 aus dem April. 😉
Dann freuen wir uns doch darauf, demnächst PHP 7.0.8 produktiv bei df einsetzen zu können sowie PHP 7.1.0 Alpha 2 im Test.
Es wird für den Apache die Version 2.4.20 jetzt eingesetzt 🙂
sorry df, aber das geht garnicht und ist unprofessionell und super schlampig. ich bin per facebook ad zufällig auf diesen artikel gestossen und kann es nicht glauben. ohne vorabinfo (per mail) am tag der umstellung davon zu erfahren. bin ab heute auf urlaub und hab keinen zugriff auf meine kundenwebsites. wer macht nun die umstellungen ? ich kann gar nicht sagen wieviele und welche sites davon betroffen sind. bin seit über 10 jahren ihr kunde, das netvt mich aber nun extrem.
Volles Verständnis. Falls dF Dir nicht kzfr. helfen kann, übergib es evtl. einem der aktiven Reseller?
Z. B. könnten da wohl helfen.
Grüße
Andreas
danke andreas, nur wer zahlt das ?
Sie können gern kurz eine Mail an technik@df.eu senden und wir prüfen dann für Sie, ob Sie die genannten Anweisungen verwenden.
ich habe bereits an herrn kaufmann geschrieben.
Ein neuer Tiefpunkt der Kommunikationsstrategie von domainfactory.
Wann bitte gedenkt ihr denn nun die Kunden über diese für einige sicherlich wichtige Änderung zu informieren?
Bis heute haben weder wir, noch die von uns betreuten Kunden eine Information hierzu von euch bekommen.
Wenn ich lese, dass nun Apache 2.4 eingesetzt wird, frage ich mich natürlich was dann mit den durch .htaccess Einträge geschützten Verzeichnissen ist. Siehe: https://httpd.apache.org/docs/2.4/de/upgrading.html#run-time
Laut Upgrade-Doku ändert sich die Syntax. Müssen wir hier also aktiv werden, oder gibt es einen abwärtskompatiblen Workaround?
Apache 2.4 wird bereits seit längerer Zeit eingesetzt, siehe https://www.df.eu/blog/update-der-apache-webserver-auf-die-version-2-4/. Auch über die nötigen Änderungen wurde gebloggt und sicherlich im Forum informiert, und einen Newsletter gab’s auch. Das war im Februasr 2015… 😉
Februar natürlich, nicht Februasr. 😀
Das ist dann wohl an mir vorbeigegangen. Danke für den Hinweis! In der Tat habe ich den NL vom 12.02.15 bekommen. Darin wurde auch meine oben gestellte Frage beantwortet.
Bleibt festzuhalten: Für das Update damals gab es vorab eine Ankündigung. (Das Update wurde erst ein paar Tage nach dem NL eingespielt.) Zudem gab es die Möglichkeit zur Terminabstimmung im Einzelfall. Und das obwohl durch das Update selber keine Inkompatibilitäten zu erwarten waren.
Jetzt wurde ein Update durchgeführt, bei dem klar war, dass es in einigen Fällen Inkompatibilitäten geben wird. Jetzt wurde aber nicht vorab informiert und selbst im Nachhinein wurden die Kunden noch immer nicht per NL informiert.
Auch nochmal hier der Hinweis: Wir möchten uns für die versäumte Kommunikation entschuldigen und haben dazu den Blogartikel auch nochmal aktualisiert!
Wirklich schade, dass man die Websever nicht pro-aktiv durchsucht und die betroffenen Kunden (vorab) anschreibt…
Schade…
Grüße
Theo
Hallo Anna,
soeben habe ich mit einem Techniker gesprochen und das Problem genannt bekommen:
.htaccess soll ich herstellen und dabei möchte ich gerne sowas wie ein Muster haben für die .htaccess, welche ich in die Root aller meiner Seiten stellen muss, damit alle von mir eingerichteten Seiten den Zugang nur SSL-verschlüsselt machen können.
Beispielsweise ist der Aufruf (Firefox, Edge, MS-IE) von mikes-lernstudio.de unverschlüsselt und erst mit https://mikes-lernstudio.de SSL-verschlüsselt.
Vielen Dank für Ihre Hilfe zum Abstellen dieses Problems.
Michael Nagel
PD Dipl.-Ing. (FH)
Hallo Anna,
ich glaube ich habs (.htaccess):
# Erzwinge https://
RewriteEngine On
RewriteCond %{HTTP_HOST} !www\.mikes-lernstudio\.de$
RewriteRule ^(.*)$ https://www.mikes-lernstudio.de/$1 [L,R=301,QSA]
… habe ich in die Root meiner Subdomain mikes-lernstudio.de eingestellt
Viele Grüße
Michael Nagel
http://www.mikes-lernstudio.de funktioniert nicht … kein SSL-Tunnel
mikes-lernstudio.de funktioniert mit SSL-Tunnel.
In der Root meiner Domain mikes-lernstudio.de steht eine .htaccess … ich habe viel zu lange rumexperimentiert … alle mir logischen Einträge vorgenommen, aber es will und will nicht … können Sie mir hier unkompliziert helfen?
Egal, was ein Besucher meiner Seite eingibt, es soll immer SSL-verschlüsselt stattfinden.
Vielen Dank