.htaccess-tarkastus: miksi sivusto palauttaa 500 ja mitkä säännöt eivät toimi
Raahaa tiedosto tähän — työkalu löytää BOMin, kuolleet direktiivit, säännöt joissa on suuri 500-virheen riski, sekä merkit ulkopuolisesta kajoamisesta. Tiedosto luetaan selaimessasi eikä sitä lähetetä minnekään.
Teksti liitettiin käsin, joten tavutason tarkistukset ohitettiin. Näet BOMin, CRLF:t ja näkymättömät merkit vetämällä itse tiedoston tähän.
Puhdas .htaccess ei paranna murtoa. Jos sivusto on vaarantunut, haitallinen koodi asuu PHP:ssä ja .htaccess on vain sen seuraus: dropper kirjoittaa tiedoston takaisin minuuteissa siitä, kun olet siivonnut sen. Järjestys on päinvastainen — etsi ensin suoritettava koodi, siivoa vasta sitten asetustiedosto.
Tähän ilmestyy lähdetiedosto rivinumeroineen.
Löydöksiä sisältävät rivit on merkitty merkillä !: punaiset ovat virheitä, keltaiset varoituksia. Näkymättömät ja tulostumattomat merkit näytetään pisteellä · — itse tiedostossa niiden kohdalla ei ole mitään.
Siivous poistaa BOM:n, muuntaa rivinvaihdot LF-muotoon, poistaa tulostumattomat merkit, korvaa sitovat välilyönnit tavallisilla ja lisää loppuun rivinvaihdon. Direktiivejä ei muuteta. Tiedosto tallennetaan nimellä htaccess-clean.txt — nimeä se .htaccess-tiedostoksi ennen palvelimelle vientiä.
# 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
Juuri tämän WordPress kirjoittaa itse. Sijoita omat sääntösi rivin # BEGIN WordPress yläpuolelle: kaikki merkkien välissä kirjoitetaan uudelleen aina, kun tallennat pysyvien linkkien asetukset.
# 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
Aliverkkotunnuksiin perustuvassa multisitessä lohko on sama, mutta kolmesta viimeisestä säännöstä puuttuu etuliite ^([_0-9a-zA-Z-]+/)?: RewriteRule ^(wp-(content|admin|includes).*) $1 [L] ja RewriteRule ^(.*\.php)$ $1 [L].
Lohkon vaihtaminen ei yksin palauta pysyviä linkkejä: muokkauksen jälkeen mene kohtaan Asetukset → Osoiterakenne ja paina ”Tallenna” — WordPress tarkistaa lohkon ja kirjoittaa sen tarvittaessa uudelleen.
Tiedosto luetaan selaimessasi — sen sisältöä ei lähetetä minnekään eikä tallenneta.
Miksi tiedosto eikä liitetty teksti
Yleisin syy 500-virheeseen .htaccess-tiedoston muokkauksen jälkeen ei näy tekstissä lainkaan. Se on BOM — kolme näkymätöntä tavua tiedoston alussa, jotka Windowsin Muistio lisää tallentaessaan UTF-8-muotoon. Apache pitää niitä ensimmäisen direktiivin osana eikä pysty jäsentämään sitä. Siksi työkalu ottaa vastaan juuri tiedoston: vain niin tavut voidaan lukea ja BOM, Windows-tyyliset rivinvaihdot sekä rivien sisällä olevat näkymättömät merkit havaita. Toinen ongelmaryhmä ovat direktiivit, jotka eivät tee mitään mutta näyttävät toimivilta. mod_gzip_on on Apache 1.3:n syntaksia; nykyisillä palvelimilla se ohitetaan hiljaisesti, ja ihmiset uskovat vuosia pakkauksen olevan päällä. Myöskään ExpiresByType-lohko, joka on kääritty mod_headers.c:n tarkistukseen mod_expires.c:n sijaan, ei toimi — eikä sitä ilman vihjettä huomaa. Kolmantena php_value ja php_flag. Ne toimivat vain, kun PHP on ladattu Apachen moduulina. Nykyaikaisilla PHP-FPM-webhotelleilla tällainen rivi joko ohitetaan tai se antaa heti 500:n. Ja erikseen tietoturvasta: jos tiedostosta löytyy sääntöjä, jotka ohjaavat kävijöitä sen mukaan, mistä hakukoneesta he tulivat, tai piilottavat uudelleenohjauksen ylläpitäjältä, se on tyypillinen murron merkki. Puhdas .htaccess ei kuitenkaan paranna murtoa: lähes aina jossain tiedostoissa asuu PHP-skripti, joka kirjoittaa sen takaisin.