Az Apache HTTPD egyik jellemzője, hogy ".htaccess" fájlokban is lehet bizonyos szerverkonfigurációs paramétereket módosítani. Ezek a fájlok bármely könyvtárba letehetők és az adott könyvtárszinten belül érvényesek csak. Sok alkalmazás eleve tartalmaz egy vagy akár több .htaccess-t, de előfordulhat, hogy te magad szeretnél egyes paramétereken, a szerver viselkedésén változtatni. De hova érdemes és adott esetben hova lehet tenni ezeket a változtatásokat? Tényleg csak egy jó megoldás létezik, vagy árnyaltabb a probléma? Erre próbálok választ adni a cikkben.
Tartalomjegyzék
Ellentmondások a gyakorlat és elmélet között
[Tartalom]
Valójában ezt a cikket is ez a probléma ihlette. Először is a cikkek, alkalmazás dokumentációk nagy része .htaccess fájlokat és azok módosítását említi, arra ad példát. Ha megkérdezel valakit, hogyan kell URL rewrite-ot, azaz a tényleges fájlhierarchiától eltérő webes URL-eket megvalósítani, Apache HTTPD esetén valószínűleg a "htaccess rewrite" keresőkifejezést fogják javasolni.
Ezzel szemben még a hivatalos dokumentáció is a htaccess fájlok elkerülését javasolja, mivel az lassítja a szervert.
"You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance."
Ez igazából nem is ellentmondás, hiszen már a dokumentáció is megemlít egy feltételt, ami nem más, mint: "ha van hozzáférésed a szerver konfigurációs fájljához". Vannak olyan konfigurációk, amiket nem is lehet htaccess-ben módosítani. Hogy egy adott direktíva vagy blokk használható-e htaccess-ben, azt a dokumentációban mindig meg lehet találni a "Context" címke melett, de a kérdések továbbra is megmaradnak:
-
Hibát követek el azzal, ha mégis htaccess-ben módosítok paramétereket?
-
Miért beszél mindenki leginkább htaccess-ről? Mindenki amatőr?
Röviden azért, mert biztosra mennek. A legtöbb esetben működni fog a htaccess, az optimalizálás pedig egy következő lépés, egy következő szint. De lássunk néhány konkrétabb érvet.
Okok, figyelembe veendő szempontok
Nagyobb célközönség elérése
[Tartalom]
A leírások általában minél nagyobb közönségnek készülnek, a htaccess pedig, ahogy azt már említettem, nagyobb eséllyel fog működni. Aki pedig már kicsit jobban ért hozzá, át tudja tenni a webszerver konfigurációba.
.htaccess-szel szállított alkalmazások
[Tartalom]
Van sok opensource alkalmazás, CMS, blogmotor, ami szintén minél nagyobb közönségnek készül, minél egyszerűbb telepítési lehetőséggel. Egyszerűbb és biztosabb htaccess-be tenni a konfigurációt, mint kiírni a felhasználónak a telepítéskor, hogy na, akkor most lépegess be a szerver konfigurációs fájljai közé és írd át ezt meg azt. De előfordulhat, hogy azért megemlítik egy README-ben, hogy azt hogyan tudnád megtenni.
Népszerű gyakorlatok terjedése
[Tartalom]
Mivel a cikkek htaccess-ről beszélnek és a CMS-ek htaccess-szel jönnek ki, az újonc fejlesztők is ezt látják legtöbbet, ezt tanulják és szokják meg. A kérdésekre így nagyobb eséllyel adnak könyvtárszintű konfigurációt javasló választ. Onnan már viszonylag könnyű továbblépni, de egyáltalán nem biztos, hogy szükséges.
Kényelem és gyors eredmény
[Tartalom]
A .htaccess-ben beállított paraméterek azonnal érvénybe lépnek, nem kell újraindítani a szervert vagy újratölteni a konfigurációt, mivel a szerver minden alkalommal be fogja olvasni ezeket a fájlokat. A hivatalos dokumentáció által említett szerverlassulást is ez okozza, hiszen nem is csak az aktuális, kért könyvtárban, hanem az afelettti mappaszinteken is meg fogja nézni a szerver, hogy van-e konfigurációs fájl. Feltéve persze, hogy az AllowOverride direktíva értéke nem "None".
Az újraindítás nélküli érvénybelépés ezek mellett elhanyagolható előny. Sőt, ha valaki elég bátor, hogy production szerveren módosítson konfigurációt és elír valamit, semmi sem fog szólni neki, hogy hibás a htaccess, míg a szerver konfigurációs fájlja a szolgáltatás újraindításakor vagy a konfigurációk manuális újratöltésekor (reload) lesznek alkalmazva. Létezik az "apachectl configtest" parancs az ellenőrzésére, de az "apachectl graceful" vagy "systemctl reload apache2" esetén is automatikusan lefut és a szerver jelzi, hogy nem tud reloadolni érvénytelen konfiguráció miatt. Ez lehet szintaktikai hiba vagy egy nem létező modulra hivatkozás akár.
Speciális körülmények, bugok
[Tartalom]
A központi konfigurációs fájlban (és most értsük ide a virtuális hosztok konfigurációját akkor is, ha külön fájlban vannak) minden beállítható, ami a htaccess-ben is, de számtalan olyan hibajelentést lehet találni a neten, ahol egyes modulok hibája vagy azok szerencsétlen együttállása miatt a reload is a szerver teljes leállásához vezetett. Márpedig a naplóbejegyzések rotációja (logrotate) miattt szokás a reload-ot cron-ból is futtatni. De ha még a saját módosítások miatt is rendszeresen leállna a szerver, nem örülnének a látogatók.
Ha tehát van egy olyan bug a szerveren, ami miattt problémás a szerverkonfigurációk újratöltése, kénytelen az adminisztrátor is a .htaccess-hez fordulni.
A konfigurációk egyszerűbb hordozhatósága
[Tartalom]
Egyik érv lehet a .htaccess mellett még, hogy egyszerűbben hordozhatók. Valójában a webszerver konfigurációs fájl is betehető a szoftverrel a git repository-ba. Sőt, a módosítása, újratöltése is automatizálható például Ansible segítségével). Itt még mindig az a kérdés, milyen és mekkora közönségnek készül a szoftver. A legnépszerűbb programokat úgy készítik, hogy a legkevésbé tapasztalt felhasználó is telepíteni tudja. Ha van adminisztrátori hozzáférésed a szerverhez és tudod, hogy lesz lehetőséged és képességed olyan eszközöket alkalmazni, amivel a konfiguráció újratölthető és számítanak is az ebből adódó biztonsági és teljesítménybeli előnyök, valószínűleg félre fogod dobni a .htaccess-t.
Ha viszont biztosra akarsz menni, hogy az általad írt program akár egy ingyenes tárhelyen is működni fog, vagy az egyszerű copy-paste híve vagy, illetve még tanulod csak a szerverkonfigurációt, a htaccess is rendben lesz.
htaccess-től való erős függés
[Tartalom]
Nem fogsz mindent magad leprogramozni, ha már megoldották előtted. Ekkor viszont a megoldás erősen függ attól, hogy a szoftver fejlesztője mennyire támaszkodik egy-egy lehetőségre. Ha a programot nem te írtad, hanem egy komoly programot letöltöttél a netről, ami tele van htaccess-szel (oké, a komolyság megkérdőjelezhető, ha tele van), és az újabb verziók újabb htaccess-t tartalmazhatnak, egyszerűbb az adminnak is htaccess-ben módosítani valamit, főleg, ha nem olyan profi a konfigurációban.
Személyes példám, hogy szerver konfigurációban próbáltam hozzáadni egy új url rewrite-ot, de a program htaccess-sze mindenhogyan felülírta, befolyásolta és a szabályom amúgy jó lett volna, de így nem működött. Ilyenkor esetleg indokolt lehet az adminnak is htaccessnél maradni, ha nem akar nagyon belenyúlni az eredeti programba és betolni mindent a szerverbeállításokba. Idővel pedig lesznek jobb megoldások és megkezdhető az optimalizálás.
Olyan is van, amikor a szoftver maga ad lehetőséget a saját konfigurálására, amihez htaccesst használ. Vagyis PHP-ból legenerálja a htaccesst. Ezt nem nagyon tudná megtenni szerverkonfiggal.
Konklúzió
[Tartalom]
Azt szokták javasolni, hogy ne csak ne használj htaccess-t, de tiltsd is le annak keresését a szerveren, mert az felgyorsítja a weblapot. Nem teszteltem le, mennyire. De a fenti okok miatt, akinek csak egy blog kell gyorsan napi 10-20 látogatónak, ez nem fog számítani. Ráadásul le se tilthatja a htaccess-t, ha az alkalmazás nagyon támaszkodik rá.
Manapság egyébként a Docker konténerek idején akár a szoftverrel együtt is kijöhet a szerverkonfiguráció készre állítva, de a Docker konténer sem lesz opció mindenkinek. És a célközönség ugye...
Szóval általában van a széles körben alkalmazható megoldás és van a profi azoknak, akiknek már van képességük és motivációjuk az optimálisabb és akár biztonságosabb megoldást választani. De utóbbiről kevesebb helyen fogsz olvasni, mert aki már van olyan szinten, úgyis utána fog nézni és fog találni forrást.
Ne félj attól, ha néhányan majd csúnyán néznek rád, mert "már az elején meg kellene tanulni a helyes irányt" és anélkül majd mennyivel kevesebbre fognak tartani. A helyes irány megtanulása nem azt jelenti, hogy már az első lépésed is a tökéletes lépés lesz. Ismerve az irányokat és a saját korlátaidat megfelelő döntést tudsz hozni arról, hogy például elvállalj-e egy komoly feladatot felelősen, vagy kisebb lépésekben törekedj a csúcsra, csak a szemed tartsd a célon.
