.htaccess-gjennomgang: hvorfor nettstedet svarer 500 og hvilke regler som ikke virker
Dra filen hit — verktøyet finner BOM, døde direktiver, regler med høy risiko for feil 500 og tegn på inngrep utenfra. Filen leses i nettleseren din og sendes ingen steder.
Teksten ble limt inn manuelt, så bytekontrollene ble hoppet over. Dra inn selve filen for å se BOM, CRLF og usynlige tegn.
En ren .htaccess kurerer ikke et innbrudd. Er nettstedet kompromittert, bor skadekoden i PHP, og .htaccess er bare følgen: dropperen skriver filen tilbake i løpet av minutter etter at du har ryddet den. Rekkefølgen er motsatt — finn først den kjørbare koden, rydd deretter i konfigurasjonen.
Her vises kildefilen med linjenumre.
Linjer med funn er merket med !: røde er feil, ravgule er advarsler. Usynlige og ikke-skrivbare tegn vises som et punktum · — i selve filen står det ingenting på deres plass.
Rensingen fjerner BOM, gjør om linjeskiftene til LF, fjerner ikke-skrivbare tegn, bytter harde mellomrom mot vanlige og legger til et linjeskift til slutt. Direktivene endres ikke. Filen lagres som htaccess-clean.txt — gi den nytt navn til .htaccess før du laster den opp til serveren.
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Nøyaktig dette skriver WordPress selv. Legg dine egne regler over linjen # BEGIN WordPress: alt mellom markørene skrives om hver gang du lagrer permalenkeinnstillingene.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
For et multisite på underdomener er blokken den samme, men uten prefikset ^([_0-9a-zA-Z-]+/)? i de tre siste reglene: RewriteRule ^(wp-(content|admin|includes).*) $1 [L] og RewriteRule ^(.*\.php)$ $1 [L].
Å bytte ut blokken gjenoppretter ikke permalenkene av seg selv: gå etter endringen til Innstillinger → Permalenker og klikk «Lagre» — WordPress sjekker blokken og skriver den om ved behov.
Filen leses i nettleseren din — innholdet sendes ingen steder og lagres ikke.
Hvorfor en fil og ikke innlimt tekst
Den vanligste årsaken til en 500-feil etter redigering av .htaccess synes ikke i teksten i det hele tatt. Det er BOM — tre usynlige byte i starten av filen, lagt til av Notisblokk i Windows ved lagring i UTF-8. Apache oppfatter dem som en del av det første direktivet og klarer ikke å tolke det. Derfor tar verktøyet imot selve filen: bare slik kan bytene leses og BOM, linjeskift i Windows-stil og usynlige tegn inne i linjene oppdages. Den andre gruppen problemer er direktiver som ikke gjør noe, men som ser ut til å virke. mod_gzip_on er syntaks fra Apache 1.3; på moderne servere ignoreres den stille, mens folk i årevis tror at komprimeringen er på. En ExpiresByType-blokk pakket inn i en sjekk av mod_headers.c i stedet for mod_expires.c virker heller ikke — og uten et hint merkes det ikke. For det tredje php_value og php_flag. De virker bare når PHP er lastet inn som Apache-modul. På moderne webhotell med PHP-FPM blir en slik linje enten ignorert eller gir umiddelbart en 500. Og litt for seg om sikkerhet: hvis filen inneholder regler som omdirigerer besøkende avhengig av hvilken søkemotor de kom fra, eller som skjuler omdirigeringen for administratoren, er det et typisk tegn på innbrudd. Men en ren .htaccess kurerer ikke innbruddet: nesten alltid ligger det et PHP-skript et sted i filene som skriver den tilbake.