.htaccess-granskning: varför webbplatsen svarar 500 och vilka regler som inte fungerar
Dra hit filen — verktyget hittar BOM, döda direktiv, regler med hög risk för fel 500 och tecken på utomstående ingrepp. Filen läses i din webbläsare och skickas ingenstans.
Texten klistrades in för hand, så byteskontrollerna hoppades över. Dra in själva filen för att se BOM, CRLF och osynliga tecken.
En ren .htaccess botar inte ett intrång. Är webbplatsen komprometterad bor skadekoden i PHP, och .htaccess är bara följden: droppern skriver tillbaka filen inom några minuter efter att du städat den. Ordningen är den omvända — hitta först den körbara koden, städa sedan i konfigurationen.
Här visas källfilen med radnummer.
Rader med fynd är markerade med !: röda är fel, bärnstensfärgade är varningar. Osynliga och icke utskrivbara tecken visas som en punkt · — i själva filen står det ingenting på deras plats.
Rensningen tar bort BOM, gör om radbrytningarna till LF, plockar bort icke-skrivbara tecken, byter ut hårda mellanslag mot vanliga och lägger till en radbrytning på slutet. Direktiven ändras inte. Filen sparas som htaccess-clean.txt — döp om den till .htaccess innan du laddar upp den till servern.
# 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
Precis detta skriver WordPress själv. Lägg dina egna regler ovanför raden # BEGIN WordPress: allt mellan markörerna skrivs om varje gång du sparar permalänkinställningarna.
# 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
För ett multisite på underdomäner är blocket detsamma, men utan prefixet ^([_0-9a-zA-Z-]+/)? i de tre sista reglerna: RewriteRule ^(wp-(content|admin|includes).*) $1 [L] och RewriteRule ^(.*\.php)$ $1 [L].
Att byta ut blocket återställer inte permalänkarna av sig självt: gå efter ändringen till Inställningar → Permalänkar och klicka på ”Spara” — WordPress kontrollerar blocket och skriver om det vid behov.
Filen läses i din webbläsare — innehållet skickas ingenstans och sparas inte.
Varför en fil och inte inklistrad text
Den vanligaste orsaken till ett 500-fel efter en redigering av .htaccess syns inte alls i texten. Det är BOM — tre osynliga byte i början av filen som Anteckningar i Windows lägger till vid sparande i UTF-8. Apache uppfattar dem som en del av det första direktivet och kan inte tolka det. Därför tar verktyget emot just filen: bara så går det att läsa bytena och se BOM, radbrytningar i Windows-stil och osynliga tecken inuti raderna. Den andra gruppen av problem är direktiv som inte gör något men ser fungerande ut. mod_gzip_on är syntax från Apache 1.3; på moderna servrar ignoreras det tyst medan man i åratal tror att komprimeringen är på. Ett ExpiresByType-block inlindat i en kontroll av mod_headers.c i stället för mod_expires.c fungerar inte heller — och utan en ledtråd märks det inte. För det tredje php_value och php_flag. De fungerar bara när PHP är inläst som Apache-modul. På moderna webbhotell med PHP-FPM ignoreras en sådan rad eller ger direkt en 500. Och separat om säkerhet: om filen innehåller regler som omdirigerar besökare beroende på vilken sökmotor de kom från, eller som döljer omdirigeringen för administratören, är det ett typiskt tecken på intrång. Men en ren .htaccess botar inte intrånget: nästan alltid ligger det ett PHP-skript någonstans i filerna som skriver tillbaka den.