Weblabor

Manapság egyre ritkábbak az olyan oldalak, melyeket nem dinamikusan állítanának elő készítőik. Sokak számára jelentősen kényelmesebb valamilyen feladat-specifikus szerkesztővel elkészíteni az oldal tartalmait - mely lehetővé teszi a kategorizálást, meta információk megadását -, mint egy általános weboldal-szerkesztő programot elővenni a cél érdekében. Ez azonban ahhoz a sajnálatos következményhez vezetett, hogy a webcímek kórosan elburjánzottak, nagyon hosszúak és "csúnyák" lettek. Lássuk miért nem jó ez nekünk, és mit tehetünk ellene! Főleg Apache szerveren működő megoldásokat fogunk vizsgálni.

A szépség és a szörnyeteg

Szerencsére még megmaradt néhány archív link egyik elődünkről, a korábbi PHPInfo oldalról, amely PostNuke rendszerrel publikálta olvasói számára a tartalmakat. Íme egy hír linkje a korábbi oldalon, összehasonlítva ugyanannak a hírnek a mostani webcímével:


Lássuk mit mond az első webím: tölts be egy modult, amelynek a neve 'News', abban vedd elő azt az írást, melynek sorszáma 595, és a hozzászólásokat szálakkal jelenítsd meg, a régebbieket felül kiírva nullás megjelenítési küszöbbel. Két részre bonthatjuk az adott webcímet: a hír megjelenítésére vonatkozó részre és a hozzászólások preferenciáit tartalmazó részre. Ezutóbbi felhasználótól függő érték, illetve nem belépett tag esetén a webhely alapértelmezése. Tehát nincs semmiféle értelme a webcímben tartani, hiszen programozottan mindig előkereshető.

Az első rész a modul betöltésére vonatkozik, és vizsgálatunk szempontjából sokkal érdekesebb kérdéseket vet fel. Elsősorban a modul funkciói vizsgálatával lehet megállapítani, hogy a file=article részre szükség van-e. A News modul két állománnyal operál: az index egy hír listát jelenít meg, az article pedig egy konkrét hírt, tehát ez elfogadható paraméter. A modules.php állomány egyetlen használható op paramétere a modload, tehát bármi mással próbálnánk meghívni, nem adna értelmes választ. Röviden tehát a name, a file és a sid paraméterek létjogosultsága indokolható meg egyáltalán.

Összehasonlításképpen elmondhatjuk, hogy a mostani webcím sokkal kifejezőbb: magyar nyelvű; jelzi, hogy hírről van szó; benne van a dátum, és még a tartalomra utaló kis részlet is. Sokkal rövidebb és letisztultabb, ráadául nem utal benne semmi arra, hogy dinamikus oldalról lenne szó. A hírek esetében minden egyes tartalomhoz saját rövid címet rendelünk, ám ez nem feltétlenül szükséges. A dinamikus oldalak rövid és barátságos címeinek előállításának vannak automatikus módjai is. Ám mielőtt megnéznénk, milyen eszközeink vannak erre, lássuk miért is érdemes egyáltalán belefogni.

Nem csak kereső optimalizálás

A rövid webcímek használata számos pozitív hatást gyakorolhat webes jelenlétünkre. Nézzük sorban, hogy milyen előnyökkel járhat.

• Kereső indexelés: Ami ezt illeti, többnyire sajnos csak mendemondákból tudunk ítélni. A Google webmestereknek szóló dokumentációja mindenesetre tartalmazza, hogy a dinamikus oldalak indexelését visszafogottan végzik, nehogy összeomlasszák a mögöttük futó programokat a kérésáradattal. A közhiedelem szerint a webcímekben megjelenő minden újabb dinamikusságra utaló karakter (?, &) az indexelés esélyének csökkenését jelenti, azaz például minél több paramétert adunk át a PHP szkriptünknek GET értékként, annál inkább dinamikusnak tűnik a kereső indexelője számára oldalunk. Ez meglehetősen logikus feltevés.
  
  
• Megjegyezhető címek: A rövid címek könnyen megjegyezhetőek, és sokkal több helyre kihelyezhetőek. Ha a fent leírtak szerinti hírek index oldal címet képezzük a PostNuke módján, az sokkal barátságtalanabb lesz, mint ha egyszerűen azt mondanánk, hogy webhelyünk hirek mappájában vannak a hírek. Egy ilyen rövid webcím könnyen elfér névjegykártyán, hirdetésekben, akár rádióban bemondva is. Nem utolsó sorban szívesebben továbbítják értünk lelkesedő látogatóink emailben, hiszen nem kell tartani attól, hogy a webcím kettétörik a sortörésben. Egyes vélemények szerint ugyanez a pszhicológiai ok húzódik meg amögött is, hogy szívesebben linkelnek a rövid címekre. Valószínűleg ebben az is benne van, hogy általában profibbnak gondolják azt, aki ezt a technikát alkalmazza. A több ránk mutató link pedig rendkívül hasznos kereső optimalizálási szempontból, hiszen így találati oldalakon előrébb szerepelhetünk.
  
  
• Méret optimalizálás: Tartalommal zsúfolt oldalakon (vagy legalábbis sok linket biztosító honlapokon) a hosszú webcímek kiírása jelentősen megnöveli az oldal méretét, mely a kiszolgálására és megjelenítésére fordított időt is növeli. Ha rövidebb webcímeket használunk, oldalunkon belüli kapcsolataink is kisebb HTML lapot eredményeznek. Ezt a törekvést kicsit visszavetheti, ha nagyon hosszú webhelyünk alapcíme (egy szolgáltatónál valamely eldugott alkönyvtárban van például). Ez sem okozhat problémát, hiszen a <base> HTML fejléc elemmel saját alapcímet határozhatunk meg a linkek számára. A méret optimalizálás egyik zászlóshajója a Yahoo! honlapja, ahol a következő formájú linkeket találunk:

  <a href=r/sh>Shopping</a>

  Itt a rengeteg link kiírása mellett csak ilyen rövid HTML kóddal tudták megoldani, hogy ne legyen túl nagy a HTML kimenet (sajnos az idézőjeleket is lespórolva). A base elem használatára is kiváló példát mutatnak, ebben adják át a munkamenet azonosítót. A méret csökkenés különben a kereső optimalizálásban is segít, a sallangokat kisebb mértékben, a tartalmat nagyobb súlyban hordozó oldalakat a keresők jobban szeretik (megint csak állítólagosan).
  
  
• Könnyebb programozás: Ha rövid webcímeket szeretnénk használni, akkor jól át kell gondolnunk, hogy mit hova teszünk, annak érdekében, hogy a címek tartósan használhatóak legyenek. Ez rákényszerít minket arra, hogy átgondoljuk tartalmunkat, és egységes kialakítást hozzunk létre. Ezt követően azonban a rövid címekkel könnyebb lesz a dolgunk, hiszen kezelésük programunkban is egyszerű. A Weblabornál például a webcímek alapján döntjük el, hogy melyik fület kell a felső navigációban megjeleníteni. Ha egy webcím elején hirek szerepel, akkor a hírekhez tartozó fület nyitjuk le.
  
  
• És még több előny a keresőknél: Ha még nem lett volna elég kereső optimalizálásból, meg kell említeni, hogy például a Google a webcímekben lévő kulcsszavakat is indexeli. Tehát ha olyan címet alakítunk ki, mint http://pelda.hu/kutya/eledel.html akkor ez az oldal már a címe miatt is jó eséllyel bukkan fel a kutya eledel keresésre. A tapasztalatok szerint a kötőjellel elválasztott szavak külön szónak számítanak az indexelésben.
  

Kés, villa, olló

Most, hogy már tudjuk, hogy van élet a borzalmasan kialakított webcímeken túl, ráadásul ez napossabbá teszi fejlesztéssel töltött óráinkat, és még a közben fogyasztott kávét is megízesíti, lássuk, miként léphetünk be a rövid webcímekkel dolgozók táborába.

1: PATH_INFO

Ez a módszer eléggé könnyen megvalósítható olyan szervereken is, ahol különben nem tudjuk befolyásolni a beállításokat. A webszerverek azon tulajdonságán múlik, hogy amennyiben nem találnak meg egy webcímhez tartozó dokumentumot, akkor a perjelek mentén visszafelé lépdelve megnézik, hogy az előtagok valamelyike nem található-e meg a kiszolgálón. Lássunk egy ilyen címet:


Ezen webcím lekérésekor a szerver felismeri, hogy nem található a teljes címhez illeszthető állomány, ezért visszalép a konyvek.php-re, amit meg is talál. A PHP állományban elérhető a $_SERVER['PATH_INFO'] értékben a PHP szkript neve után található információ. Ezzel aztán bármit kezdhetünk, ha konkrétan könyv sorszámot vártunk, akkor valami ehhez hasonlót javasolnék:Természetesen nem csak egy információ morzsát adhatunk így át, az "alkönyvtárak" száma tetszőleges lehet. Ennek ellenére ennek a módszernek két kézenfekvő hátránya is van. Az egyik, hogy minden lehetséges tartalom típushoz el kell helyeznünk egy PHP állományt, a másik pedig az, hogy továbbra is látszik, hogy PHP-vel operálunk, csak a webcímet sikerült rövidíteni. Először is lássunk egy megoldást a második problémára.

2: PATH_INFO + ForceType

Ha Apache szervert használunk, nem kell feltétlenül PHP kiterjesztést adnunk szkriptünknek ahhoz, hogy azt a PHP feldolgozza. Valójában bármilyen állományt PHP típusúvá kényszeríthetünk. A következőt kell elhelyeznünk webhelyünk gyökérkönyvtárában egy .htaccess állományban (vagy bármilyen más módon az Apache tudtára kell adnunk):Ahhoz, hogy ezt használhassuk, a FileInfo engedélyt tartalmaznia kell az adott könyvtárra érvényes AllowOverride beállításnak. Ha tehát a fenti kód hatással van a könyvtárban lévő állományokra, akkor a konyvek.php-t átnevezhetjük konyvek-re, és a továbbiakban használhatjuk az első metódust a PATH_INFO kezelésére. Webcímeink továbbra is közvetlenül tartalmazni fogják a PHP állomány nevét, ez azonban csak a webszerver számára lesz ismert tény. Ezzel a módszerrel létrehozhatunk további hirek, cegunkrol és hasonló nevű állományokat, melyek ilyen nevű "könyvtárakként" jelennek meg majd a látogatók számára.

Innentől kezd érdekes lenni az, hogy a keresőrobotok visszafogják a dinamikus oldalak indexelését, hiszen statikusnak látszó oldalunkkal kapcsolatban ilyen fenntartásaik már nem lesznek. Ezért hatékony gyorsítótárazást és/vagy más módszereket kell alkalmazni annak érdekében, hogy ne omoljon össze szerverünk egy-egy Google vagy MSNBot támadás során.

Mint említettem ez a módszer ugyan megoldotta a dinamikusság látszatának elfedését, de ugyanakkor nem növelte eléggé a belső rugalmasságot a webcímek kezelhetőségét illetően. Még két módszer van a tarsolyunkban, melyek az első kettőnél sokkal rugalmasabbak, és végre elfelejthetjük azt a megkötést, hogy minden "alkönyvtárnak" egy-egy PHP szkriptet kell megfeleltetni.

3: ErrorDocument

Kulcsszavunk ezúttal az ErrorDocument, azaz a hibák kezelésére szolgáló dokumentum beállításának lehetősége. Amennyiben az Apache egy nem létező webcímet kap, és a fent említett visszalépéssel sem tud értelmes előtagot találni benne, akkor elindítja hibakezelő mechanizmusát. Ennek a folyamatnak a helyére könnyen delegálni tudjuk saját szkriptünket, mely magára vállalja a nem található oldalak kezelését. Ismét egy .htaccess állományt kell létrehozni, most a következő tartalommal:Ez a beállítás azt eredményezi, hogy minden "nem található oldal" (azaz 404-es) hiba esetén a webhelyünk gyökerében lévő cimkezelo.php fog lefutni. Ahhoz, hogy ennek a .htaccess állománynak hatása legyen, ismét csak az előbbi módszernél említett jogosultságnak kell érvényesnek lennie mappánkra.

Ezzel az eszközzel felvértezve a szerverünkön például a /termek/54 cím meghívására a webszerver meg fogja állapítani, hogy ilyen állomány nem létezik, ezért a cimkezelo.php szkriptnek adja át a vezérlést egy átirányított HTTP lekérdezést indítva. A következőképpen tudjuk lekezelni a kérést:A kapott webcímet először megszabadítjuk a kezdő perjeltől, majd feldaraboljuk, hogy az első komponenst megkapva ki tudjuk választani a megfelelő modult, mely lekezeli a kérést. Természetesen lehet egy előre megadott címkezelő függvény hozzárendelési táblát is használni, vagy bármilyen bonyolultabb megoldást választani. Nagyon fontos azonban arra figyelni, hogy most egy 404-es hibát kezelünk, és ha sikerül megtalálnunk a jó oldalt, akkor a válasszal megadott állapotot is meg kell változtatni, tehát ha azonosítható és betölthető tartalmat kértek, akkor a HTTP állapot fejlécet 200 OK státuszra kell állítani. Ha nem megfelelő címet kértek, akkor maradhat a 404-es állapot.

Kipróbálhatjuk a $_SERVER tömb tartalmának kiírását. Látni fogjuk, hogy számos REDIRECT_ kezdetű érték jelenik meg, melyek lehetőséget adnak arra, hogy megtudjuk például, hogy milyen hibakód kezelése érdekében hívta meg a szkriptet a szerver, illetve a REDIRECT_URL-ben is megkaphatjuk az átirányítás előtti címet.

Ezen módszer előnye, hogy - az előbbiekkel ellentétben - tetszőleges címformák kezelésére jó, nem igényel egy-egy PHP állományt minden "könyvtár" bevezetéséhez. Ezen kívül eléggé egyszerűen beállítható, és az Apache jellemző telepítésén nyugodtan használható (amennyiben nem tiltották le számunkra). Hátrányaként felhozható, hogy a 404-es hibák mindig egy újabb bejegyzést jelentenek majd az Apache hibanaplójában alapbeállítások mellett, ezért felesleges hibaáradattal tölthetjük el a hibanaplót.

4: URL Rewrite

Az Apache URL Rewrite (vagy IIS szerverekhez az ISAPI Rewrite) lehetővé teszi, hogy az Apache kérések kiszolgálásába ágyazott mintaillesztő kifejezéseket írjunk, melyek a folyamat elején megváltoztathatják a szerver által kezelt webcímet. Ezzel elérhetjük, hogy az előző módszer átirányított lekérdezése helyett rögtön az adott lekérdezésben kezeljük le az igényelt címet, csupán azt kell tudnunk, hogy miként tudjuk a webcím átírásokat megvalósítani.

Első megközelítésben megoldásunk nem fog többet nyújtani, mint a fenti ErrorDocument alapú változat, csak éppen másképp oldjuk meg ugyanazt a feladatot. A kezünkben lévő rugalmasság csak később tárul fel. Ismét egy .htaccess állományt fogunk létrehozni a következő tartalommal. A példa a Drupal forráskódjából származik. Először is nem biztos, hogy be van kapcsolva a szerveren a Rewrite modul támogatása, ezért egy ilyen feltételes részbe burkoljuk az utasításainkat. Ha nem így tennénk, akkor kikapcsolt Rewrite modul esetén 500-as hibát kapnánk a könyvtár minden állományára és az alkönyvtárakra is, ami nem túl kellemes élmény.

Minden Rewrite modulhoz kapcsolódó direktíva a Rewrite kulcsszóval kezdődik, és általában valamilyen mintaillesztő kifejezés vagy más feltétel segítségével teszi lehetővé a webcím átalakítás megvalósítását.

• A RewriteBase azt adja meg, hogy milyen alapkönyvtárat kell figyelembe venni. Ezt akkor használjuk, ha a webhelyünk valamilyen alkönyvtárban van, mert akkor a további feltételekbe ezt az alkönyvtárat már nem kell belekódolni, és egyszerűbb lesz a könyvtárváltás, ha később szükségessé válik.
  
  
• A RewriteCond olyan feltételeket ad meg, melyek teljesülése a soron következő RewriteRule végrehajtásához feltétlenül szükséges. Itt az adott lekéréshez kapcsolódó változókat is használhatjuk. A példában használt első feltétel ellenőrzi, hogy a kért webcím nem egy állomány, a második feltétel pedig akkor teljesül, ha nem létező könyvtár nevét kérték. Tehát ha nem létező állományt, és nem is létező könyvtárt kértek, akkor hajtódik végre az átírási szabály.
  
  
• A RewriteRule szabja meg azt, hogy az előzetesen megadott feltételeknek megfelelő webcímet végülis miként kell átírni. Itt mintaillesztő kifejezés segítségével azt adjuk meg, hogy a teljes webcímet az index.php q nevű paraméterébe tegyük át. A szögletes zárójelben a webcím átírás egyéb beállításai találhatóak. A QSA azt kéri, hogy egy esetleges GET lekérdezési paraméter listát a megadott lista végére fűzze fel az Apache. Két példa a webcím átírás eredményeire:
  
  
  /hirek/14       =>  /index.php?q=hirek/14
  /hirek?oldal=2  =>  /index.php?q=hirek&oldal=2

Megjegyzendő, hogy nem csak egy átírást fogalmazhatunk meg. Valójában több átírási blokkot alkalmazhatunk, melyek a saját blokkjukban megadott feltételek szerint hajtódnak végre. Ráadásul több Rewrite direktíva is rendelkezésre áll, melyeket most nem ismertetnék. További információért érdemes megnézni a modul dokumentációját.

A Rewrite modul által kezelt bejövő kérések különleges kezelésével nem is kell törődnünk, hiszen az általunk megadott PHP állományban fognak kikötni. Természetesen külön irányításokat készíthetünk a hirek kezdetű webcímekre, hogy az a hírek modulnak megfelelő hirek.php-re irányítson, és a dolgot tovább bonyolíthatjuk, de végső soron a PHP szkriptjeinkhez egy hagyományos HTTP lekérdezés fog eljutni, és a GET/POST változókat minden gond nélkül tudjuk kezelni. Emiatt ez a megoldás eléggé jól használható kész alkalmazások "előtétjeként" is. A Rewrite megoldás másik előnye, hogy kevesebb erőforrást foglal, mert a kérést magát módosítja feldolgozás közben, és nem egy átirányított lekérdezést indít. Mindezekkel az előnyökkel persze csak akkor élhetünk, ha jó mintaillesztési ismereteink vannak és a Rewrite modul az adott kiszolgálón rendelkezésre áll.

Dobj vissza kenyérrel

Megismerve a rövid webcímek kezelésének technikáit, felmerül a kérdés, hogy mégis miként tudjuk ezekre irányítani a felhasználókat. Alkalmazásunkat fel kell készíteni arra, hogy rövid webcímeket írjon ki a választott technológiának megfelelően. Az, hogy belsőleg 404-es hibára képezzük le a címet vagy Rewrite modult használunk, csak a kérés kiszolgálása szempontjából érdekes, a felhasználó nem fogja észrevenni a különbséget, ha minden esetben a szép rövid webcímeket írjuk ki. A teljes alkalmazásnak késznek kell lennie arra, hogy ha egy webcímet kiírunk, akkor az a megfelelő formában jelenjen meg.

A rövid webcímek technikáinak megismerése kapcsán sokakban felmerülhet, hogy saját webhelyüket is ilyen kialakításúra szeretnék változtatni. Egy ilyen vágy megszületését némi előkészítésnek kell követnie. Először is meg kell állapítani, hogy milyen ráhatás lehetséges a webhelyet működtető motorra. Ha saját készítésű szkriptekről van szó, akkor a változtatást "könnyű" keresztülvinni, hiszen a webcímek kezelésének módját kell csak átalakítani.

Ha azonban egy kész alkalmazást használunk (mint például a cikk elején emlegetett PostNuke), akkor a váltás sokkal nagyobb dió. A PostNuke például minden zsigerében hosszú és paramétergazdag webcímek generálására van felkészítve, és erről nagyon nehéz lebeszélni. A Mountain Research and Development publikálta a PostNuke rövid webcímekkel kapcsolatos ismertetőjét. Itt fogadási oldalon az említett Rewrite szabályok széles garmadáját használják fel. Lássunk két példát:A webcím átírás itt már jóval túlmutat a 404-es hibakezelés megoldásain, hiszen a lekért címek bizonyos tulajdonságai alapján más-más paraméterezést állít elő. Egyáltalán nem lehetetlen persze a 404-es hibakezelést alkalmazni, és PHP-n belül elvégezni a webcímek áltakítását, de mivel végül mindenképpen a mintaillesztő kifejezésekhez kell nyúlni, ezért csak az URL Rewrite szintaktikájának megismerésétől tudjuk magunkat megóvni.

Ami a kiírást illeti, a megfelelő webcímek kimenetre kerülését egy kimeneti buffereléses megoldással valósították meg, azaz a PostNuke által generált teljes oldalt a memóriában tartják, majd kiküldés előtt egy PHP-ben megvalósított hosszú webcím -> rövid webcím konverziót követnek el. Hasonló megközelítés bármilyen rendszer esetén alkalmazható, és bár a webcím problémát megoldja, hatékonynak nem nevezhető.

Az üveghegyen is túl

Az is előfordulhat, hogy nem meglévő rendszerünk köré akarunk gyógyító kódokat építeni, hanem teljes váltást szeretnénk megvalósítani jelenlegi rendszerünkről valami új (legalábbis rövid webcímeket támogató) megoldásra. Ezesetben különösen érdemes figyelnünk arra, hogy korábbi webcímeink továbbra is elvezessék a látogatókat a célhoz, és hogy HTTP átirányítással tegyék mindezt. Nem elhanyagolható szempont, hogy váltásunk után a keresőrobotok első látogatása során oldalaink törlődni fognak az indexekből, ha 404-es válaszokat adunk lekéréseikre. Ezért régebbi címeinket úgy kell kezelnünk, hogy azok a tartalmak új oldalaira irányítsanak át. Ha a cikk elején említett korábbi PostNuke címet kipróbálod, látni fogod, hogy az egyenesen az új címre irányít. Így a ránk linkelő oldalak és a keresőrobotok is megtudják, hogy mi lett a tartalom új címe és ezt teszik a korábbi webcím helyére.

Annak érdekében, hogy a váltás után a webcímek átírása a keresők adatbázisában automatikus legyen, egy dologra mindenképpen oda kell figyelni. A régi webcímek esetében nem szabad önműködő belső átirányításokat végezni, hiszen akkor a régi webcímek továbbra is működnek, és a keresők folytatják a hosszú webcímes találatok szolgáltatását. Ehelyett HTTP átirányítást kell eszközölni, mégpedig a 301 Moved Permanently állapotkóddal, mely alapján a keresőrobot meg fogja érteni, hogy a korábbi tartalom átmozgatott megfelelőjének címét adjuk át, melyet az adott tartalom új címeként kell kezelni. Lássunk erre egy példát a 404-es kezelő módosításával:Ez természetesen csak egy kis megvalósítási példa, mindig az adott körülmények között alkalmazott webcím sémákat kell figyelembe venni. Felmerülhet az, hogy a modules.php paraméter sorrendje túlságosan is kötött a kódban. Ez tapasztalatok szerint nem jelent problémát, hiszen a PostNuke szinte mindig ezt a paraméter sorrendet adja ki.

Összefoglalás

Reményeim szerint cikkemmel sikerült felébreszteni a vágyat arra, hogy egyre többen térjenek át a felhasználó-, kereső- és sávszélesség barát rövid webcímek használatára, akárcsak úgy, hogy egy meglévő rendszert foltoznak meg ilyen formában. Meglepődnék, ha nem merülnének fel további kérdések a téma kapcsán, hiszen sok ponton éreztem azt, hogy akár többet is lehetne mondani, vagy jobb példákat is lehetne adni. Kíváncsian várom a véleményeket!