Weblabor

Böngészés során számtalanszor akad az ember hibaüzenetekbe, ezek közül is a leggyakoribb talán az "Error 404: File not found.". Jelentése pedig az "igen, egyszer volt itt egy oldal, de már nincs"-től kezdve az "ezt valaki elgépelte"-ig terjed. A legrosszabb megoldás, ha webfejlesztőként nem törődünk e jelenséggel, és hagyjuk, hogy a webszerver tegye amire képes. A hiba oldal megtervezése is fontos egy site építése során és nem is mindig olyan egyszerű eldönteni, hogy mit tartalmazzon.

Hibaüzenetek és kódok

A hibaüzeneteket és kódjaikat (legalábbis egy részüket) az alábbi táblázat foglalja össze. A kódok a szerver által adott válasz fejlécében "HTTP/x.y KÓD" kapnak helyet (az RFC 1945 6.1 pontja definiálja ezt a kérdést, egy részletesebb listát pedig az RFC2616-ban olvashatunk). A szerveren futó programokkal - indokolt esetben - befolyásolhatjuk, hogy mi kerüljön ide, például így működik a phpMyAdmin 'http' beléptetési módja is. Figyeljük meg, hogy a kód első száma (a százas helyiértéken levő) a kód típusát definiálja, a négyessel kezdődő (4xx) a kliens, míg az ötössel kezdődő (5xx) a szerver oldalon keletkező hibákat jelöli:



A felsorolásból a klienshez köthető hibák jelzéséhez érdemes dinamikus hibalapot készíteni. A szerverhez köthetőeknél inkább egyszerű HTML lapot javasolnék, hogy ne terhelje tovább a gépet és programhiba esetén is megjeleníthető legyen. A továbbiakban a 4xx hibák esetén megjelenítendő információs oldalakkal, ezen belül is a leggyakoribb 404-es lapjával foglalkozunk.

Funkciók

Ian Lloyd a "The Perfect 404" cikkében azt javasolja, hogy az oldal tartalmazzon:

• Navigációs elemeket, legalább egy linket a címlapra vagy honlaptérképre
  
• Kulcsszavas keresési lehetőséget
  
• Visszafogott grafikát
  

A kiépített navigációs elemek (pl. menü) segítségével irányítani tudjuk az eltévedt látogatót. Lehetővé tesszük számára, hogy a honlap jól körülhatárolt logikai egységeit röviden áttekintse és kiválassza azt, amelyik érdekli. Egy ilyen hiba oldalon a hagyományos navigáció mellett nagy értéke van a támogatási linkeknek is ("technikai segítség", "webmester", "hiba bejelentése" stb.).

A kulcsszavas keresés szép gesztus a hibaoldalon, hiszen tetszőleges kifejezésre kilistázza a honlap témába vágó oldalait. Ezt érdemes saját kereső programmal vagy a nagyobb keresők sitesearch szolgáltatásával megoldani. Ha nem regisztráljuk az oldalunkat ilyen szolgáltatáshoz, akkor választhatunk a rendelkezésre álló programokból, mint pl. ht://Dig, vagy mi magunk is barkácsolhatunk a meglévő eszközökből, pl. grep. A dinamikus weblapok esetén a keresés nagyobb odafigyelést igényel, nehogy a kódjainkat is megmutassuk a látogatónak.

A visszafogott grafika erősen ízlés dolga, hiszen a robotok úgysem töltik le a képeket. Érdemes úgy megtervezzük a hibalapot, hogy ízléses legyen, de mértékkel, pl. Flash reklámok nélkül. Az is derüljön ki egyértelműen, hogy azért ezt látja a látogató, mert valami hiba történt, ez nem a keresett tartalom.

Az oldal összeállítására Ian Lloyd JavaScript megoldást javasol. Ezáltal a saját 404.html hibakezelő lapunk dinamikussá válhat és kiválasztott paraméterek alapján összeszerkeszthető a tartalma. Ha pedig a böngészőben a látogató letiltotta a JavaScript támogatást, egy statikus lapot kap (<noscript> tagon belüli rész). Ezt én annyiban egészíteném ki, hogy szerintem szerver oldalon érdemes összeállítani egy ilyen dinamikus lapot és akkor teljesen mindegy, hogy van-e JavaScript támogatás, vagy sem. További előnye, hogy a szerver oldalon hozzáférhetünk adatbázisokhoz, a tartalomkezelőhöz stb.

Minta megoldások

Több nagyobb cég honlapját meglátogatva kipróbáltam, hogy mit is gondolnak az ottani programozók a 404 hibaüzenet megjelenítéséről. Érdekes, hogy sokan választották az egyszerű átirányítást, tehát a látogató hiba esetén a címlapra érkezik. PHP-ban ez valahogy így néz ki (legyen a neve "elso404.php"):Fontos, hogy a HTTP/1.0 (RFC 1945 10.11 pontja) szerint az átirányításban a teljes URL-t illik feltüntetni. Tapasztalataim szerint a relatív URL-eket is lekezelik a böngészők, de alkalmazásuk esetleg nem várt eredményhez vezethet. Működéséhez természetesen be kell állítani a webszerveren is ezt a kódot hibakezelőnek:

• Apache esetén a .htaccess fájlba vagy a <VirtualHost> beállításainál megadni:

  ErrorDocument 404 /elso404.php

• Microsoft IIS szerveren az IIS Manager-ben állítható át (help: "About Custom Error Messages").
  

Az "error 404 page" kulcsszavakra keresve a tréfás lapoktól kezdve a haiku versekkel tarkított hibalapokig sok-sok példát találtam. Az ilyen lapokra vadászóknak tudom ajánlani a 404 Research Lab oldalait. Sajnos a példák keresése közben azt tapasztaltam, hogy ezeket az oldalakat sokan ugyanúgy hibákkal készítik el, mint a honlapjuk többi részét. Kommentár nélkül íme két megoldás a homokaasu.org és index.hu címekről.

A látottak közül nekem a Sun Microsystems hibaüzenete volt a legszimpatikusabb. A hibát úgy erőszakoltam ki belőle, hogy a nemlétező http://hu.sun.com/noezbiztosnincs címet írtam a böngészőbe. A kapott oldal számomra azért tetszetős megoldás, mert:

• A cégre jellemző navigációs panel látható a lap tetején.
  
• A Sun és a technikai központ elérhetősége kiemelt dobozokba került a bal oldalon.
  
• A dinamikus tartalomban feltünteti a legutóbb létrehozott és változott URL-ek listáját.
  

Különösen a legutolsó pont szerencsés, amely megpróbálja kitalálni, hogy miért is történt ez a hiba és aktív segítséget nyújt a látogatónak. Az oldal tartalmaz még egy visszajelzés linket is, amely a látogatóra bízza az eset jelentését.

Hasonlóan pozitív példaként hozhatom fel a Weblabor hibalapját is. Itt a tartalomkezelő rendszer egyik oldalát mutatja meg a webszerver, így a dinamikus részben láthatóak a honlap újdonságai (friss blogmarkok, aktív és új fórumtémák).

Haladó megoldás

Webmester értesítése

Azon kívül, hogy webmesterként időnként átbogarásszuk a szerver logokat, egyéb lehetőségek is vannak. Ha már rászánjuk az időt és dinamikus hibalapot készítünk, legyen része az automatikus visszajelzés is (masodik404.php):A fenti megoldással a webmester automatikusan kap egy levelet minden hiba esetén. Néhány hét (perc) után az is kiderül, ha elfelejtettünk 'favicon.ico' vagy 'robots.txt' állományokat elhelyezni tárhelyünkön. A HTTP_REFERER segítségével kideríthetőek a szerkesztési hibák (a hivatkozó oldalra rosszul helyeztünk el egy linket), a HTTP_USER_AGENT segítségével (elvileg) eldönthetjük, hogy egy robot kéri-e a lapot, vagy egy ember ül a gépe előtt és böngészget. Ez utóbbi feltétel felhasználható a dinamikus tartalom felépítésében is. A webmesternek küldött levél pedig kiegészíthető egyéb információkkal is, akár a $_SESSION és a $_COOKIE tömbök tartalmával is.

Az elektronikus levélben történő értesítések hátránya, hogy egy rosszul beállított robot vagy egy aktív hacker gyorsan megtömheti a webmester postaládáját. Ennek elkerülésére célszerű saját logfájlt vagy adatbázist használni. Adatbázis esetén induljunk ki valami hasonló szerkezetből (SQLite példa):Az elkészített tábla 'ido' eleme tartalmazza a dátumot Unix timestamp formátumban. Feltöltésére az e-mail küldés helyett a következő kódot használhatjuk (harmadik404.php):A fenti példa ADOdb felhasználásával könnyen átvihető tetszőleges szerverre és adatbázisra. Az SQL utasítás összeállításában a szöveges adatok levágása a substr függvénnyel akkor hasznos, ha valaki megpróbálja túlterhelni programjaink bufferét. A webmester értesítését pedig bízzuk inkább naponta automatikusan (pl. crontab) lefuttatott önálló programra. A site adminisztrációs felületén pedig napló nézegető és elemző menüket helyezhetünk el:

• Az utóbbi N nap bejegyzései (a határidő számítása PHP-ben : date('U') - $nap*24*3600):

  SELECT * FROM errorlog WHERE ido>={hatarido} ORDER BY ido DESC;

• Legaktívabb IP címek Top10 listája:

  SELECT ip,count(*) as darab FROM errorlog GROUP BY ip ORDER BY darab DESC LIMIT 10;
  

Mit is keresett...

Különösen nagyobb oldalakon előfordul a tartalmak átszerkesztése, URL-ek eltűnése, átnevezése. Ez zavarba hozza a látogatót és a kereső robotokat is. A zökkenőmentes átállás segítésére megpróbálkozhatunk egy "gondolatolvasó" trükkel. A webszervereken beállítható, hogy a beérkező kérést átfogalmazza. Apache esetén ezt a mod_rewrite modul végzi el. Használata a httpd.conf vagy .htaccess fájlokban a következő:A fenti példával tetszőleges átirányítás megoldható egyszerű regulás kifejezések alkalmazásával, akár másik szerverre is. Átköltözés esetén az Apache dokumentáció a következő mintát javasolja:Amely leellenőrzi, hogy létezik-e a fájl és ha nem, a kérést átküldi webserverB.com-ra. Ez a megoldás természetesen csak a DocumentRoot-on belüli fájlokra használható. A feltétel kicserélhető, és ekkor minden URL-t lekezel:Sajnos a használata többletmunkát igényel a szervertől, ezért a teljesítmény megtartása érdekében általában a szkriptekre bízzák az átirányítást is. További hátránya, hogy a site-on belüli átirányítás esetén a látogató a régi URL-t is valódinak és érvényesnek látja. Ezt a problémát már csak programozással oldhatjuk meg. A látogatót a megfelelő fejléc elküldésével értesíthetjük arról, hogy ezentúl új címet keressen:



A 301 és 302 kódok közötti különbség, hogy a 302 esetében később a tartalom ismét megtalálható lesz az adott URL-n, de a 301 esetében már nem. A 301-es kódot látva a keresőrobotok lecserélik a tartalomhoz vezető URL-t az új címre.

Érdemes tehát esetleg a hibakezelést kombinálni egy átirányítás ellenőrzéssel is. Ekkor figyelni kell arra, hogy az elküldött header információ megelőzzön minden más kiírt szöveget. Sikeres átirányítás során a státusz kód és az új cím megadása után lépjünk is ki a programból. Mivel a REQUEST_URI változó tartalmazza a kérést, célszerű az előbbi adatbázist kiegészíteni egy átirányítás táblával, amiben kereshetünk:Ennek a karbantartása a webmester feladata, a programba illesztése pedig egyszerű (negyedik404.php):A fenti program dekódolja a kérés címét, majd megkeresi az esetlegesen hozzá kapcsolódó átirányítást. Érvényes XHTML generálásakor ugyan problémás az URL paramétereket elválasztó '&' jel, amelyet ott '&' formában illik átadni, a header függvény használatakor az eredeti '&' jelet kell alkalmazni.

Összegzés

A hibalapok közül leggyakrabban a 404-esekkel találkozunk böngészés során. A 404-es hibalapoknak a feladata az eltévedt szörfözők és robotok útba igazítása. A statikus "File not found" szöveg helyett ma már elvárható, hogy a honlapunk navigációs elemei, keresés és dinamikus útbaigazító tartalom jelenjenek meg. Ezeken felül a hibakezelő szkript automatikus értesítő levelet küldhet a webmesternek vagy adatbázisban tárolhatja az eseményeket, a kérés elemzésével pedig megtalálhatja a keresett tartalom új helyét és oda átirányíthatja a látogatót. A honlap programozójának ilyen pár soros apró figyelmességei bőven megtérülnek a site fenntartása és esetleges későbbi átalakítása során.