apache-httpd

A .htaccess rewrite szabályait használva (is) tudunk szép, ésszerű, kereső és felhasználóbarát hivatkozásokat, linkeket készíteni, ami egyébként alapkövetelmény kell, hogy legyen egy weboldalnál.

Miért célszerű elhagyni? Leírom programozói-üzemeltetői meglátásom szerint.

Elmondhatjuk, hogy üzemeltetés szempontjából a fejlesztők nagy része megszokta, hogy Apache a webszerver kiszolgáló. Ennek megfelelően a legtöbben a rövidített hivatkozások tekintetében csak erre koncentrálnak, és a rövidítések kezelését lokális .htaccess útján oldják meg.

A .htaccess elérése – Apache webszerverről van szó – „on the fly” módon történik, minden módosítás azonnali hatást vált ki, így fejlesztői oldalról még könnyebb dolgunk van. Pontosan ez a kényelmes mód adja az Apache „lassúságát” is. A .htaccess file-t ugyanis minden file elérésnél az útvonal összes könyvtárszintjén keresi és betölti, ha megtalálja. Ez jelentős időveszteséget generál.

Tegyük fel, hogy performancia-javítás miatt szeretnénk áttérni más webszerverre, legyen ez mondjuk egy Nginx php-fpm-el, vagy HHVM-mel. A rewrite szabályok megtartásához szükség lesz átírni úgy, hogy az Nginx is tudja alkalmazni. Ezt egyébként viszonylag könnyen meg lehet tenni. Az egyetlen gond az, hogy az Nginx nem tudja – legalább – reload nélkül alkalmazni a szabályokat, ami ugye fejlesztői szempontból rögtön jelentős kényelmetlenséget jelent, amennyiben nincs elérésünk/jogosultságunk az Nginx újratöltésére, újraindítására.

Mi lehet a jó megoldás? Ha megnézünk egy wordpress-t, látni fogjuk, hogy nincs a .htaccess-ben semmiféle rewrite szabály, mégis képes rövidített linkek használatára. A jó megoldás az, ha webszervertől független módon írjuk meg az alkalmazásunkat. Ez lehetővé teszi, hogy webszervertől független legyen a weboldal, aminek több előnye van, mint hátránya.

A webszervert egyetlen – különösebb – dologra fogjuk kérni: minden, általa „nem található, pl. /kategoriak/” hivatkozást adjon át a programunknak.

Páldául Nginx esetén így:

...
 location ~ /.*/$ {
        try_files $uri /index.php?q=$request_uri;
    }
...

Azaz, minden olyan hivatkozást, ami /…../ formátumú, elküld az index.php felé a $_GET[‘q’] változóban. Innen már csak egy lépés, hogy levezéreljük, mire és hogyan viselkedik az alkalmazás.

Apache esetén ugyanerre a .htacces-ben egyetlen rewrite szabályt használhatunk:

...
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php?q=%{REQUEST_URI} [L]
...

Akárcsak egy wordpress esetében, ott is nagyjából ennyi sor a .htaccess (igaz, nem pont ugyanez).

Ha így építünk oldalakat, alkalmazást, lehetővé tesszük, hogy bármikor könnyedén elmozdítható legyen az Apache kiszolgálása alól, ami nem hátrány, inkább előny. Bármikor adódhat üzemeltetetési oldalról olyan igény (nyilván nem a pici látogatottságú oldalakra gondolok), ahol terhelésmentesítés, optimalizálás miatt nem az Apache szolgálja ki az oldalunk kéréseit.

Apró megjegyzés, hogy ez a blog oldal sem egy ideje Apache alatt megy, hanem Nginx – php-fpm párossal. Az átállás sima volt, köszönhetően annak, hogy a wordpress eleve így készült már a kezdetek óta, mármint nem kötötte magát .htaccess-ben tárolt rewrite szabályokhoz.

0.00 avg. rating (0% score) - 0 votes

Leave a comment

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük