Átírások és átirányítások

Az átírásokat és átirányításokat egyben tárgyalom, mert a htaccess-be beírt kódjuk igen kis módosítással gyakorlatilag ugyanaz. A magyar szóhasználatban általában az átirányítást, az angolban inkább az átírást (rewrite) használjuk gyakrabban, és sokszor a másik fogalmat is beleértjük. Ugyanakkor fontos, hogy megértsük a kettő közötti különbséget, és hogy tudjuk, mindkettőre lehetőségünk van.

Az átírásnál a felhasználó nem látja, hogy mi zajlik a háttérben. A böngészőben az általa beírt link nem változik meg, az átírás a szerveren "belül" történik.

Az átrányításnál a felhasználó látja, hogy átirányítás történik. A böngésző címsorában a link átíródik az új, átirányított címre.

Nézzünk egy példát arra, hogy a gyakorlatban ez mit is jelent. Az alábbi példánál az index2.html és az index3.html is az index1.html-re van irányítva, de az index2.html átírással, az index3.html átirányítással. Nyissuk meg mindkét linket, és nézzük meg, mi történik!

/redirect1/index2.html
/redirect1/index3.html

Látható, hogy az első esetben a böngésző úgy mutatja, hogy az index2.html-t nyitottuk meg, pedig valójában ilyenkor is az index1.html nyílt meg. A második esetben hiába volt a linkben index3.html a böngésző címsora index1.html-t mutat.

Átírások alkalmazása

Az átírások legjelentősebb használati köre a felhasználó- és keresőbarát linkek létrehozása. Régebben az egyes url-ek meglehetősen csúnyák, és nehezen megjegyezhetőek voltak.

Kisebb statikus oldalaknál régebben az terjedt el, hogy magának a html-nek adtak szép nevet, így volt alma.html, barack.html stb. Ez nem túl szép megoldás, már csak azért sem, mert a szerver oldali nyelvek terjedésével a végződések köre jelentősen kibővült, lehetett volna pl. .htm, .html, php, .asp stb, így a végződés sem könnyen megjegyezhető.

Bár elvileg nagyon szép url-eket létre lehet hozni olyan módszerrel, hogy mindent külön könyvtárba teszünk, mindegyikben egy darab index.html-el, és csak a könyvtárakat hivatkozzuk, ez már 5-10 aloldal esetén sem túl praktikus, 50-100 aloldalnál meg egyenesen lehetetlen.

A szerver oldali programozási nyelvek elterjedésével és az oldalak nagyra duzzadásával egyenesen lehetetlen volt minden aloldalnak külön html vagy php file-t létrehozni. 50-100 aloldalnál már egy kisebb módosítást is rengeteg oldalon kellett volna átvezetni. A legkézenfekvőbb módszer a nagy oldalak kezelésére pár sablon karbantartása, ahol a tartalom adatbázisból jön. Ennek praktikussága miatt igen gyorsan létrejöttek azok az oldalak, ahol az oldalak szerkezete olyan, hogy az url-ek pl. index.php?id=alma, index.php?id=barack mintájúak. Itt csak egy php file van, ami paraméterként kapja meg, hogy konkrétan mire is keresnek, és a belső programozás dönti el, hogy milyen oldal jelenik meg a felhasználó előtt. Ez a fajta megoldás szinte minden szempontból előnyös: kevés sablont kell hozzá karbantartani, adatbázisból minden könnyen előállítható. Különösen alkalmas ez a módszer olyan oldalak üzemeltetésére, ahol igen nagyszámú, adatbázisból előállítandó aloldal van, pl. egy webáruház üzemeltetésére, ahol gyakorlatilag az aloldalak teljesen azonosak, csak éppen az adott terméktől függően pár dolog változik. Egy igen nagy gond van ezzel a megoldással: nem szépek az url-ek. Ráadásul az elterjedt keresők tudják, hogy egy ? mögött millió hasonló aloldal is lehet, így gyakran figyelmen kívül hagyják a ? utáni részt.

Erre a problémára kínálnak megoldást a különféle átírások. Lehetővé teszik, hogy egy beírt url tetszőlegesen nézzen ki, és azt feldolgozzhassuk, és bármilyen kívánt belső aloldalt megjelenítsünk anélkül, hogy a felhasználó bármit is észrevenne a belső folyamatokból

Ilyen átírás lehet pl, hogy a /gyumolcs/barack/ hívás a gyumolcs.php?id=barack belső átírást alkalmazza. Általánosságban nem kell minden gyümölcsre ezt külön megadni, hanem egy sorban is meg lehet, hogy a /gyumolcs/valami/ automatikusan gyumolcs.php?id=valami legyen. Azaz elég a htaccessben 1 sort beállítani, és egyetlen php-t fenntartani az összes gyümölcsre.

Az is beállítható pl, hogy kis statikus oldalnál hozzátegye automatikusan a html-t, azat pl a /barack/ hívás automatikusan a barack.html-t hívja meg.

Átirányítások alkalmazása

Az átirányításoknál az átírással ellentétben a felhasználó látja, hogy átirányították, és másik oldal nyílik meg, mint amit a böngészőbe beírt. Ez egyben azt is jelenti, hogy akkor alkalmazzunk átirányítást, ha ez a szándékunk: a felhasználó vegye észre, hogy az eredeti oldal helyett másikat kap.

Megszűnt oldalak átirányítása

Az átirányítások tipikus alkalmazási módja a megszűnt aloldalak átirányítása. Az oldal megszűnhetett több okból is, pl. azért, mert egy olyan hirdetés volt rajta, ami időközben lejárt, aktualitását vesztette, vagy azért, mert oldalainkat jobbá tettük, átalakítottuk, pl. az átírásoknál említett módon felhasználóbarát, olvasható linkeket alakítottunk ki.

Ezekben az esetekben ha a felhasználó a régi linkre kattint, akkor egy 404-es (nem található) hibát kapna, és még akkor is, ha egyedi hibaoldalt állítottunk be, fennáll a veszélye, hogy azonnal otthagyja az oldalunkat.

Természetesen viszonylag ritkán fordul elő, hogy a felhasználó véletlenül egy régi, megszűnt oldal linkjét gépeli be. Az ilyen jellegű hívások két esetben lehetnek: ha könyvjelzőben mentette el az (al)oldalunkat, illetve ha valamilyen másik weboldal a régi aloldalunkat hivatkozza. Ilyenkor mindenképpen érdemes átirányítást használni, különben a bejövő linkekből közvetlenül jövő látogatókat elvesztenénk. A keresőkben való helyezéseknél is sokat számít, ha nem megszűnt, hanem átirányított oldalra mutatnak a bejövő linkjeink.

Alternatív elérési utak átirányítása

Szintén gyakori átirányítási eset az, ha egy oldalunk többféle módon is elérhető, de nem szeretnénk felesleges duplikációt az oldalainkban. Ennek tipikus esete a honlap www-vel, illetve www nélküli változata. Amennyiben nem történik átirányítás, akkor általában olyanok a szerverbeállítások, hogy mindkét változatban el lehet érni az oldalunkat, ami a keresőkben duplikációt okozhat. Célszerű kiválasztani az egyiket, a másikat pedig erre átirányítani.