.htaccess-Empfehlungen
Ich habe eine persönliche Website, die hauptsächlich zum Spaß verwendet wird. Ich lade Bilder, Videos und Texte hoch, die ich teilen möchte. Ein HTML-Übermittlungsformular akzeptiert Fragen und Zeichenfolgenübermittlungen von Benutzern, die eine phpmyadminDatenbanktabelle zur Speicherung verwenden.
Das folgende Snippet ist meine aktuelle .htaccessDatei.https://gtmetrix.com/ stellt fest, dass Weiterleitungen die Hauptursache für die Verlangsamung des Ladens meiner Seiten sind, ich bin mir jedoch nicht sicher, wie ich sie optimieren soll.
RewriteEngine On
#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www.MYDOMAIN.com [NC]
RewriteRule ^(.*)$ https://MYDOMAIN.com/$1 [L,R=301]
#URL EXTENSION REMOVAL
RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
RewriteRule ^ /%1 [NC,L,R]
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^ %{REQUEST_URI}.html [NC,L]
#HOTLINKING PROTECTION
#NOTE: having |html| and |htm| included prevented access of the site through browser search, so i removed them.
RewriteCond %{HTTP_REFERER} !^https://(www\.)?MYDOMAIN\.com(/.*)*$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(css|flv|gif|ico|jpe|jpeg|jpg|js|mp3|mp4|php|png|pdf|swf|txt)$ - [F]
#CONTENT SECURITY POLICY
<FilesMatch "\.(html|php)$">
Header set Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: 'unsafe-inline'; media-src 'self' data: 'unsafe-inline'; connect-src 'self';"
</FilesMatch>
#REDIRECT FOR DATE PAGE
Redirect /date /storage/date-202010
#REDIRECT FOR HOME PAGE
Redirect /home /
#CUSTOM ERROR PAGES
ErrorDocument 400 /allerror.php
ErrorDocument 401 /allerror.php
ErrorDocument 403 /allerror.php
ErrorDocument 404 /allerror.php
ErrorDocument 405 /allerror.php
ErrorDocument 408 /allerror.php
ErrorDocument 500 /allerror.php
ErrorDocument 502 /allerror.php
ErrorDocument 504 /allerror.php
#PREVENT DIRECTORY BROWSING
Options All -Indexes
#FILE CACHING
#cache html and htm files for one day
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>
#cache css, javascript and text files for one week
<FilesMatch "\.(js|css|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
#cache flash and images for one month
<FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|mp4|png)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
#disable cache for script files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
#BLOCKS FILE TYPES FOR USERS
<FilesMatch "\.(htaccess|htpasswd|ini|log|sh|inc|bak)$">
Order Allow,Deny
Deny from all
</FilesMatch>
AKTUALISIEREN
Ich habe einen neuen Beitrag erstellt, der ein HSTS und viele der von Herrn White empfohlenen Änderungen integriert. Das Kopfgeld wurde vergeben. Bitte richten Sie weitere Rückmeldungen an den neuen Beitrag .
Antworten
https://gtmetrix.com/stellt fest, dass Weiterleitungen der größte Schuldige bei der Verlangsamung meiner Seitenladevorgänge sind
Der "Vorschlag" von gtmetrix.com in dieser Hinsicht ist wohl "falsch" (oder besser gesagt nicht annähernd so ernst, wie es impliziert), vorausgesetzt, Sie verlinken bereits konsistent auf die kanonische URL * 1 auf Ihrer Website (und Sie haben keine anderen Weiterleitungen in Ihren Bewerbungscode). Diese Weiterleitungen betreffen wahrscheinlich nur einen "sehr kleinen Teil" Ihrer Website-Besucher bei ihrem ersten Besuch.
( * 1 Kanonische URL ist HTTPS + nicht www + keine .htmlErweiterung.)
Sie haben 3 externe Weiterleitungen in dem .htaccessCode, den Sie gepostet haben:
#REDIRECT TO SECURE HTTPS CONNECTION RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] #FORCE WWW TO NON-WWW RewriteCond %{HTTP_HOST} ^www.example.com [NC] RewriteRule ^(.*)$ https://example.com/$1 [L,R=301] #URL EXTENSION REMOVAL RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC] RewriteRule ^ /%1 [NC,L,R]
Wenn Sie HSTS implementiert haben, müssen Sie auf demselben Host von HTTP zu HTTPS umleiten, bevor Sie die WWW-Subdomain kanonisieren - wie oben in der ersten Regel beschrieben. Dies ist eine Anforderung von HSTS und der "Preload-Liste". Daher können Sie in diesem Szenario nicht vermeiden, mindestens zwei Weiterleitungen (im schlimmsten Fall) zu haben.
Wenn Sie jedoch nicht beabsichtigen, HSTS zu implementieren, können Sie die ersten beiden Weiterleitungen zu einer kombinieren. Dies können Sie tun, indem Sie einfach die Reihenfolge der ersten beiden Regeln umkehren. Zum Beispiel:
#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]
#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Die erste Regel, die www zu Nicht-www umleitet, leitet auch zu HTTPS um, sodass die zweite Umleitung niemals ausgeführt werden muss. Es gibt also immer nur eine Weiterleitung, um HTTPS und Nicht-WWW zu kanonisieren.
Ich habe auch das redundante Erfassungsuntermuster (dh (.*)) im RewriteRule Muster "HTTP to HTTPS" entfernt , da Sie stattdessen die REQUEST_URIServervariable verwenden. Und die andere "www to non-www" -Umleitung wurde geändert, um konsistent zu sein. Beachten Sie, dass die REQUEST_URIServervariable den vollständigen URL-Pfad einschließlich des Schrägstrichpräfixes enthält, während die erfasste Rückreferenz das Schrägstrichpräfix weglässt.
Die beiden oben genannten Regeln könnten zu einer einzigen (geringfügig komplexeren) Regel zusammengefasst werden, dies hat jedoch keinen Vorteil.
Die Regeln könnten auch "allgemeiner" gestaltet werden, ohne dass der kanonische Hostname explizit angegeben werden muss. Wie Sie dies implementieren und ob dies leicht möglich ist, hängt jedoch davon ab, ob Sie andere Subdomains haben oder nicht. Aber auch dies dient keinem "Vorteil", außer dass es kopierbarer / einfügbarer ist. Im Allgemeinen ist es vorzuziehen, hier explizit zu sein - weniger fehleranfällig.
#URL EXTENSION REMOVAL RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC] RewriteRule ^ /%1 [NC,L,R]
Sie können auch verhindern, dass die .html"Umleitung zum Entfernen von Erweiterungen" eine zusätzliche Umleitung auslöst, indem Sie diese Umleitung zuerst (vor den beiden oben genannten kanonischen Weiterleitungen) einschließen und als Teil der Umleitung direkt zu HTTPS und Nicht-www (kanonisches Schema + Hostname) umleiten.
UPDATE: Dies sollte auch eine 301 (permanente) Weiterleitung sein, keine 302 (temporäre) Weiterleitung, die es derzeit ist. Eine 301-Umleitung wird standardmäßig vom Browser zwischengespeichert, um unnötige Roundtrips zum Server zu vermeiden. Wenn Sie den Statuscode nicht explizit in das RFlag aufnehmen, wird standardmäßig 302 verwendet.
Das NCFlag ist in der RewriteRuleDirektive ebenfalls nicht erforderlich , da Sie hier nichts abgleichen, bei dem zwischen Groß- und Kleinschreibung unterschieden wird.
Diese Regel zum Entfernen der .htmlErweiterung funktioniert wahrscheinlich in Ordnung für Ihre URLs. Sie ist jedoch nicht unbedingt korrekt und könnte möglicherweise effizienter gestaltet werden. Der Grund für die Überprüfung anhand der THE_REQUESTServervariablen im Gegensatz zum RewriteRule Muster oder der REQUEST_URIServervariablen besteht darin, eine potenzielle Umleitungsschleife zu vermeiden, indem verhindert wird, dass umgeschriebene Anforderungen umgeleitet werden. Dies liegt daran, THE_REQUESTdass sich nach dem Umschreiben der Anforderung nichts ändert - sie enthält die erste Zeile der HTTP-Anforderungsheader. THE_REQUESTEnthält jedoch auch die Abfragezeichenfolge, sodass eine legitime Anforderung, die einen .htmlTeil der Abfragezeichenfolge enthält , möglicherweise falsch umgeleitet wird.
Beispiel: Anforderung example.com/?p1=foo.html&p2=bar(die Startseite mit einer Abfragezeichenfolge und URL-Parametern, die den Wert enthalten foo.html) und diese werden fälschlicherweise umgeleitet example.com/?p1=foo, wodurch die Abfragezeichenfolge abgeschnitten wird.
Der reguläre Ausdruck stimmt /([^.]+)\.htmlauch nicht mit einer URL überein, die Punkte als Teil des URL-Pfads an anderen Stellen als der Dateierweiterung enthält. z.B. Eine Anfrage für /foo.bar.htmlwürde nicht umgeleitet. Dies kann jedoch für die URLs auf Ihrer Website vollkommen in Ordnung sein.
Um diese "falschen" Weiterleitungen zu vermeiden, können Sie stattdessen den URL-Pfad aus dem RewriteRule Muster erfassen und entweder eine einfachere Bedingung verwenden und dagegen prüfen THE_REQUEST(um eine Schleife zu vermeiden) oder REDIRECT_STATUSstattdessen die Umgebungsvariable verwenden, die bei direkten Anforderungen immer leer ist.
Zum Beispiel:
#URL EXTENSION REMOVAL
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule (.+)\.html$ https://example.com/$1 [NC,R=301,L]
Dies erfasst den URL-Pfad vor der .htmlDateierweiterung anhand des RewriteRule Musters (das natürlich die Abfragezeichenfolge ausschließt). Die einfache Bedingung, die die REDIRECT_STATUSenv var überprüft, verhindert eine Umleitungsschleife.
Wenn wir die oben genannten Punkte zusammenbringen, haben wir:
#URL EXTENSION REMOVAL
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule (.+)\.html$ https://example.com/$1 [NC,R=301,L]
#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]
#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Das NCFlag war in der Umleitung "URL-Erweiterungsentfernung" nicht erforderlich.
Dies löst jetzt höchstens eine Umleitung aus, unabhängig davon, ob eine Anforderung für HTTP, www oder die .htmlErweiterung eingeht . Wie bereits erwähnt, geht dies jedoch zu Lasten der Nichterfüllung der Anforderungen für HSTS.
Und es sollte beachtet werden, dass es in realer Hinsicht möglicherweise keinen wahrnehmbaren Unterschied zwischen 1, 2 oder sogar 3 Weiterleitungen gibt. Zumal es die überwiegende Mehrheit der Besucher sowieso nicht betrifft.
Zusätzlich:
#REDIRECT FOR DATE PAGE Redirect /date /storage/date-202010 #REDIRECT FOR HOME PAGE Redirect /home /
Im Allgemeinen sollten Sie vermeiden, Weiterleitungen von mod_alias ( Redirect/ RedirectMatch) und mod_rewrite ( RewriteRule) zu mischen . Die beiden Module werden unabhängig und zu unterschiedlichen Zeiten während der Anforderung ausgeführt, trotz der offensichtlichen Reihenfolge der Anweisungen in der .htaccessDatei. mod_rewrite wird zuerst ausgeführt. So können Sie unerwartete Konflikte bekommen.
Beachten Sie auch, dass dies Redirectmit dem Präfix übereinstimmt und alles nach dem Abgleich an das Ende der Ziel-URL angehängt wird. z.B. /date/foowürde /storage/date-202010/foodurch die erste Regel umgeleitet werden. Diese speziellen Weiterleitungen sind auch 302 (temporäre) Weiterleitungen. Es sieht so aus, als ob sie 301 (permanent) sein sollten?
In diesem Fall spielt es jedoch wahrscheinlich keine Rolle, ob Sie Redirectoder verwenden. RewriteRuleWenn Sie jedoch mod_rewrite für einige Weiterleitungen verwenden, verwenden Sie in der Regel mod_rewrite für alle Weiterleitungen. Zum Beispiel:
#REDIRECT FOR DATE PAGE
RewriteRule ^date$ /storage/date-202010 [R=301,L]
#REDIRECT FOR HOME PAGE
RewriteRule ^home$ / [R=301,L]
#BLOCKS FILE TYPES FOR USERS <FilesMatch "\.(htaccess|htpasswd|ini|log|sh|inc|bak)$"> Order Allow,Deny Deny from all </FilesMatch>
Sie in den Kommentaren erwähnt , dass Sie Apache verwenden 2.4, jedoch Order, Allowund Denysind Apache 2.2 - Richtlinien und sind früher als veraltet auf Apache 2.4. Sie funktionieren immer noch, jedoch nur aus Gründen der Abwärtskompatibilität und sollten so schnell wie möglich aktualisiert werden.
Beachten Sie, dass Sie alle Instanzen auf Ihrem System aktualisieren müssen, da sich die neueren Anweisungen nicht unbedingt gut mischen lassen.
Unter Apache 2.4 würden Sie Requirestattdessen die Direktive verwenden:
#BLOCKS FILE TYPES FOR USERS
<FilesMatch "\.(ht[ap]|ini|log|sh|inc|bak)$">
Require all denied
</FilesMatch>
Beachten Sie, dass die Apache-Serverkonfiguration bereits den direkten Zugriff auf .htaccessund .htpasswdDateien blockieren sollte , aber besser, um sicher zu gehen, denke ich.
ErrorDocument 500 /allerror.php
Die 500 definiert ErrorDocument spät in .htaccessist wahrscheinlich zu spät höchstens 500 (Internal Server Error) Antworten (das Ergebnis von fangen Fehlkonfigurationen ). Es gibt wahrscheinlich nicht viel, was Sie dagegen tun können, aber es wäre vorzuziehen, dies früher in der Serverkonfiguration (oder im <VirtualHost>Container) zu definieren , um "nützlicher" zu sein.