Nézzük meg most részletesebben a 7.18. ábrán a webböngésző oldalát! A böngésző lényegében egy olyan program, mely képes megjeleníteni egy weboldalt és kezelni a megjelenített oldalon lévő elemekre történt kattintásokat. Amikor egy elemet kiválasztanak, a böngésző követi a hiperhivatkozást és letölti a kiválasztott oldalt.

A web létrehozásának kezdetén nyilvánvaló volt, hogy az egymásra mutató weboldalaknak szükségük van valamilyen módszerre az oldalak megnevezéséhez és helyének megállapításához. Három kérdést kellett megválaszolni, mielőtt a kiválasztott oldalt meg lehetett volna jeleníteni:

Ha valamilyen módon minden oldalnak egyedi neve lenne, nem lenne semmi félreérthető az oldalak azonosításában. A probléma azonban ezzel még nem lenne megoldva. Gondoljuk át az emberek és oldalak közötti párhuzamot! Az Egyesült Államokban csaknem mindenkinek van társadalombiztosítási száma, ami egyedi azonosító, mert állítólag nincs két ember, akinek a száma ugyanolyan lenne. Mindazonáltal, ha valakinek csak egy társadalombiztosítási száma van, nem lehet kitalálni a tulajdonos címét, és valószínűleg azt sem lehet megmondani, hogy vajon angolul, spanyolul vagy kínaiul kellene levelet írni annak a személynek. A web alapvetően ugyanezekkel a problémákkal küzd.

A kiválasztott megoldás úgy azonosítja az oldalakat, hogy közben egyszerre oldja meg mindhárom problémát. Minden oldalt egy URL (Uniform Resource Locator – egységes erőforrás-meghatározó) segítségével jelölnek meg, ami valójában az oldal egész világon használt neve. Az URL-ek három részből állnak: a protokollból (ami sémaként [scheme] is ismert), annak a gépnek a DNS-nevéből, amelyen az oldal megtalálható, és az elérési útból, ami egyedileg azonosít egy bizonyos oldalt (egy beolvasandó fájlt vagy egy gépen lefuttatandó programot). Általános esetben az út egy hierarchikus név, ami a könyvtárrendszer struktúráját követi. Az út értelmezése azonban a szerverre van bízva; vagy tükrözi az aktuális könyvtárstruktúrát, vagy nem.

Például a 7.18. ábrán látható URL a következő:

http://www.cs.washington.edu/index.html

Ez az URL három részből áll: a protokollból (http), a hoszt DNS-nevéből ( University of Washington ) és az útból (index.html).

Amikor a felhasználó rákattint egy hiperhivatkozásra, a böngésző lépéseket tesz annak érdekében, hogy elhozza a hiperhivatkozás által mutatott oldalt. Kövessük végig a példabeli hivatkozásunk kiválasztásának lépéseit!

Sok böngésző a képernyő alján egy státussorban jelzi ki, hogy éppen melyik lépést hajtja végre. Ily módon, ha a teljesítmény gyatra, a felhasználó láthatja, hogy ez azért van, mert a DNS nem válaszol, vagy a kiszolgáló nem válaszol, vagy csak egyszerűen lassú a hálózat, mivel torlódás lépett fel az oldal átvitele közben.

Az URL-eket nyílt végűre tervezték abban az értelemben, hogy egyszerű legyen többféle protokollt használó böngészőket készíteni a különféle típusú erőforrások elérése érdekében. Valójában számos más protokollhoz is meghatároztak URL-eket. A gyakoribbak egy kissé leegyszerűsített formában a 7.19. ábrán láthatók.

7.19. ábra - Néhány gyakori URL-séma

Nézzük át röviden a listát! A http protokoll a web eredeti nyelve, amin a webszerverek beszélnek. A HTTP a HyperText Transfer Protocol (hipertext-átviteli protokoll) rövidítése. Ebben a fejezetben később részletesen is meg fogjuk vizsgálni.

Az ftp protokollt a fájlok FTP-vel, az internetes fájlátviteli protokoll segítségével való eléréséhez használják. Az FTP időben megelőzte a webet, és még több mint három évtized múltán is használják. A web megkönnyíti a szerte a világban lévő FTP-szervereken elhelyezett nagyszámú állomány megszerzését, mivel egyszerű, kattintható felhasználói felületet biztosít a parancssoros felület helyett. Ez az információhoz való tökéletesített hozzáférés az egyik oka a web látványos fejlődésének.

Egy helyi állományt weboldalként lehet elérni a file protokoll segítségével, vagy még egyszerűbben, csak megnevezve azt. Ez a megközelítés nem igényel szervert. Természetesen csak helyi fájlokkal működik, távoliakkal nem.

A mailto protokoll igazából nem rendelkezik weboldal-lekérési tulajdonsággal, de azért hasznos. Lehetővé teszi a felhasználóknak, hogy e-levelet küldjenek a webböngészőből. A legtöbb böngésző úgy reagál egy mailto hivatkozásra, hogy az üzenet megírásához elindítja a felhasználói ügynököt azzal a címmezővel, amely már ki van töltve.

Az rtsp és sip protokollok valós idejű multimédia-letöltések munkameneteinek létrehozására, valamint hang- és videohívásokhoz használatosak.

Végül az about protokoll egy szabály, amely információval szolgál a böngészőről. Például az about:plugins hivatkozás követése esetén a legtöbb böngésző olyan oldalt jelenít meg, amely felsorolja azokat a MIME-típusokat, amelyeket böngészők a kiterjesztéseik, az ún. beépülő modulok (plug-in) segítségével kezelnek.

Röviden, az URL-eket úgy tervezték meg, hogy ne csak a felhasználók weben való szörfözését könnyítsék meg, hanem futni tudjanak egyrészt a régebbi protokollok, mint az FTP és az e-levél, valamint újabb, hang- és videoadatok átviteléhez használatos protokollok is, továbbá kényelmes hozzáférést biztosítson a helyi állományokhoz és böngészőinformációhoz. Ez a megközelítés feleslegessé tette a többi szolgáltatás használatához szükséges, különleges felhasználói felülettel ellátott programokat, és csaknem minden internetes anyag elérése egyetlen programba, a webböngészőbe kerülhetett. Ha az ötlet nem egy svájci kutatólaboratóriumban dolgozó brit fizikusnak jutott volna eszébe, könnyen azt képzelhetnénk, hogy a tervet valamelyik szoftvercég hirdetési részlege álmodta meg.

Mindezen kellemes tulajdonságok ellenére a web növekvő használata felfedte az URL-sémában rejlő egyik gyengeséget. Az URL egy meghatározott hosztra mutat, de néha hasznos lenne, ha egy oldalra anélkül lehetne hivatkozni, hogy ezzel egyidejűleg megmondanánk, hogy az oldal hol található. Például a sűrűn hivatkozott oldalak esetében jó lenne, ha egymástól távol több másolata is létezne, a hálózati forgalom csökkentése érdekében. Sajnos nincs rá mód, hogy azt mondjuk: „Nekem az xyz oldalra van szükségem, de nem érdekel, honnan szerzed meg.”

Az ilyen típusú problémának a megoldására hozták létre az URL-ek általánosított változatát, az URI-t (Uniform Resource Identifier – egységes erőforrás-azonosító). Bizonyos URI-k megadják, hogyan kell megtalálni egy erőforrást. Ezek az URL-ek. Más URI-k megadják az erőforrás nevét, de azt már nem, hogy hol található. Ezeket az URI-kat URN-nek (Uniform Resource Names – egységes erőforrásnév) nevezik. Az URI-k írásának szabályait az RFC 3986 határozza meg, míg a használatban lévő különféle sémákat az IANA követi nyomon. A 7.19. ábrán feltüntetett sémákon kívül még sok egyéb típusa létezik az URI-knak, de az itt látható sémák a meghatározói a ma használatos webnek.

Ahhoz, hogy meg tudja jeleníteni az új oldalt (vagy bármelyik oldalt), a böngészőnek értenie kell az oldal formátumát. Az oldalakat egy HTML nevű, szabványosított nyelven írják, hogy minden böngésző megértsen minden weboldalt. Ez (jelenleg) a web közvetítőnyelve (lingua franca), amellyel e fejezetben később még részletesen foglalkozunk.

Bár a böngésző alapjában véve csak egy HTML-értelmező, a legtöbb böngésző számos gombbal és funkcióval rendelkezik, hogy megkönnyítsék a weben való navigálást. Többnyire van egy gombjuk az előző oldalra való visszalépéshez, egy gombjuk a következő oldalra való előrelépéshez (ez csak akkor működik, ha a felhasználó előzőleg már visszalépett), és egy olyan gombjuk, amivel a felhasználó egyenesen a saját kezdőoldalára juthat. A legtöbb böngészőnek van egy gombja vagy menüpontja, amivel könyvjelzőt tehet egy adott oldalra, és egy másik, amivel meg lehet jeleníteni a könyvjelzők listáját, így pár egérkattintással bármelyiket újra meglátogathatjuk.

Ahogyan példánk mutatja, a HTML-oldalak nem csak egyszerű szöveget és hipertextet tartalmazhatnak, hanem számos más tartalmi elemet is. A még általánosabb működés érdekében nem kell minden oldalnak HTML-t tartalmaznia. Egy oldal lehet MPEG-formátumú videó, PDF-formátumú dokumentum, JPEG-formátumú fénykép, MP3-formátumú dal, vagy a több száz másik állománytípus közül bármelyik. Mivel a szabványos HTML-oldalak ezek közül bármelyikre hivatkozhatnak, a böngészőnek gondjai lesznek, amikor olyan oldallal találkozik, amit nem tud értelmezni.

A különböző állománytípusok száma rohamosan nő. A legtöbb esetben ezért, mert ahelyett hogy újabb és újabb értelmezők beépítésével egyre nagyobbá tették volna a böngészőket, egy sokkal általánosabb megoldást választottak. Amikor a kiszolgáló elküld egy oldalt, egyúttal elküld némi járulékos információt is az oldalra vonatkozóan. Ez az információ tartalmazza az oldal MIME-típusát (lásd 7.13. ábra). A böngésző a text/html típusú oldalakat és még néhány beépített típust közvetlenül megjelenít. Ha az adott MIME-típus nincs a beépítettek között, akkor a böngésző megnézi a MIME-típusokat tartalmazó táblázatát, hogy megtudja, hogyan kell megjelenítenie az oldalt. A táblázat minden MIME-típushoz egy megjelenítőt társít.

A böngészők bővítése kétféleképpen, plug-in-ek vagy segédalkalmazások segítségével lehetséges. A beépülő modul (plug-in) egy olyan harmadik fél által készített szoftvermodul, ami a böngésző bővítményeként van telepítve, amint azt a 7.20.(a) ábra szemlélteti. Gyakori beépülő modul például a PDF, a Flash és a Quicktime, amelyek dokumentumok megjelenítését, hangok és videók lejátszását végzik. A beépülő modulok a böngészőn belül futnak, ezért hozzáférhetnek az aktuális oldalhoz és módosíthatják annak megjelenését is.

7.20. ábra - (a) Egy böngésző beépülő modul. (b) Egy segédalkalmazás

A böngészőknek van egy eljáráskészletük, melyet a beépülő moduloknak implementálniuk kell, hogy meghívhatók legyenek a böngészőből. Például általában van egy olyan eljárás, amit a böngésző azért hív meg, hogy megadja a beépülő moduloknak a megjelenítendő adatokat. Ez az eljáráskészlet a beépülő modul interfésze, ami böngészőnként eltérő lehet.

Mindemellett a böngésző is kínál szolgáltatásokat saját eljáráskészletén keresztül a beépülő moduloknak. A böngésző interfészében jellemzően olyan eljárások vannak, amelyek lehetővé teszik a memória lefoglalását és felszabadítását, egy üzenet megjelenítését a státussorban vagy paraméterek lekérdezését a böngészőtől.

Ahhoz, hogy a beépülő modult használni lehessen, előbb telepíteni kell. A szokásos eljárás az, hogy a felhasználó ellátogat a beépülő modul weboldalára, és letölt egy telepítőállományt. A telepítőállomány futtatása kicsomagolja a beépülő modult, majd meghívja a szükséges eljárásokat, hogy bejegyezze a beépülő modul MIME-típusát a böngészőhöz, és társítsa vele a beépülő modult. A böngészők általában előre telepített formában tartalmazzák a népszerű beépülő modulokat.

A böngészők kiterjesztésének másik módja a segédalkalmazások (helper applications) használata. Ezek önálló programok, melyek külön folyamatként futnak, ahogy azt a 7.20.(b) ábra szemlélteti. Mivel a segédalkalmazás különálló program, az interface karnyújtásnyi távolságra van a böngészőtől. Általában inkább csak megkapja a letöltött ideiglenes állomány nevét, megnyitja az állományt, majd megjeleníti a tartalmát. A segédalkalmazások többnyire nagy programok, melyek a böngészőtől függetlenül léteznek, mint például a Microsoft Word vagy PowerPoint.

Sok segédalkalmazás használja az application MIME-típust. Ennek következtében meglehetősen sok altípust definiáltak hozzá, például az application/vnd.ms-powerpoint-ot a PowerPoint-állományoknak. A vnd jelzi a gyártóspecifikus formátumokat. Ily módon egy URL mutathat közvetlenül egy PowerPoint-állományra, majd amikor a felhasználó rákattint, a PowerPoint automatikusan elindul, és lekezeli a megjelenítendő tartalmat. A segédalkalmazásoknak nem kell az application MIME-típus használatára szorítkozniuk. Az Adobe Photoshop például az image/x-photoshop típust használja.

A böngészők tehát gyakorlatilag korlátlan számú dokumentumtípus kezelésére is beállíthatók anélkül, hogy bármit is változtatni kellene rajtuk. A korszerű webszerverek gyakran több száz típus/altípus kombinációt kezelnek, és ehhez még minden alkalommal újabbak jönnek, amint egy új programot telepítenek.

Ütközések forrása lehet, ha több beépülő modul és segédalkalmazás is elérhető ugyanahhoz az altípushoz, például a video/mpeg-hez. Ilyenkor az történik, hogy az utoljára regisztráló szoftver felülírja a meglevő MIME-típustársítást, kisajátítva ezzel a típust. Következésképpen, egy új program telepítése után a böngésző lehet, hogy másképp fogja kezelni a meglevő típusokat.

A böngészők nem csak a távoli webszerverekről tölthetnek le állományokat, hanem megnyithatják azokat helyileg is anélkül, hogy hálózat lenne a láthatáron. A böngészőnek azonban valahogyan ki kell találnia az állomány MIME-típusát. Az operációs rendszerek szabványos megoldása a fájl kiterjesztésének MIME-típussal történő társítása. Egy tipikus konfiguráció esetén a foo.pdf a böngészőben fog megnyílni az application/pdf beépülő modul segítségével, a bar.doc pedig a Wordben, mint az application/msword segédalkalmazás.

Itt is adódhatnak ütközések, hiszen egyszerre több program is tudja – mondjuk inkább azt, hogy szeretné tudni – kezelni például az mpg állományokat. A tapasztaltabb felhasználóknak szánt programok a telepítés során gyakran jelölőnégyzeteket (checkbox) adnak meg minden olyan MIME-típushoz és kiterjesztéshez, amit kezelni képesek. A felhasználó így kiválaszthatja a számára szükséges típusokat, és nem fogja akaratlanul felülírni a meglevő társításokat. A nagyközönségnek szánt programok azonban azt feltételezik, hogy a felhasználónak fogalma sincs róla, hogy mi az a MIME-típus, úgyhogy magukhoz ragadnak mindent, amit csak tudnak, tekintet nélkül arra, hogy mit tettek az addig telepített programok.

A böngészők sokféle új típussal való kibővítésének lehetősége kényelmes dolog, de bajokhoz is vezethet. Amikor egy Windows-os PC-n lévő böngésző letölt egy exe kiterjesztésű állományt, látja, hogy ez egy futtatható program, vagyis nincs hozzá segédalkalmazás. Ekkor kézenfekvő lépés a program futtatása. Ez azonban óriási biztonsági rést jelentene. Egy rosszindulatú webhelynek nincs is más dolga, mint hogy kiállít egy oldalt, mondjuk, filmsztárok vagy élsportolók képeivel, melyek mind egy vírusra mutatnak. Egy kattintás egy képre, és máris letöltődik egy ismeretlen és esetleg ellenséges végrehajtható program, és futni kezd a felhasználó gépén. Az ilyen hívatlan vendégek elkerülésére a Firefox és más böngészők úgy vannak beállítva, hogy az ismeretlen programok automatikus futtatásával legyenek óvatosak, de nem minden felhasználó tudja, hogy melyek a biztonságos, ám kényelmetlen döntések.

Ennyit tehát az ügyfél oldaláról, és most vessünk egy pillantást a kiszolgáló oldalára is. Amint azt már láttuk, a böngésző az URL beírása vagy egy hipertextsorra való kattintás után feldolgozza az URL-t, és a http:// valamint a következő perjel közötti részt kikeresi a DNS-ből. Ha megvan a kiszolgáló IP-címe, a böngésző kiépít egy TCP-összeköttetést a kiszolgáló 80-as portjával. Ezután átküld egy parancsot, ami tartalmazza az URL hátralevő részét, mely az adott kiszolgálón levő oldalhoz vezető út. A kiszolgáló végül elküldi az állományt megjelenítésre a böngészőnek.

Első közelítésben egy webszerver a 6.6. ábrán látható kiszolgálóhoz hasonlóan néz ki. Az a kiszolgáló egy állomány nevét kapja meg, amit meg kell keresnie, és vissza kell küldenie a hálózaton keresztül. Bármelyik esetet is nézzük, a kiszolgáló a következő lépéseket hajtja végre a központi ciklusában:

A modern webszervereknek több funkciójuk van ennél, de abban az egyszerű esetben, ha a tartalmat egy fájl tárolja, alapjában véve ennyi egy webszerver feladata. A dinamikus tartalom esetében a harmadik lépést egy, az elérési út alapján meghatározott program végrehajtása helyettesítheti, és ez küldi vissza a tartalmakat.

A webszervereket azonban másképp valósították meg annak érdekében, hogy másodpercenként sok kérést legyenek képesek kiszolgálni. Az egyik probléma az egyszerű megvalósítással, hogy a fájlok elérése gyakran torlódást okoz. A lemezről történő olvasások nagyon lassúak a program végrehajtásához képest, és az operációs rendszer függvényeinek hívásai következtében ugyanazok a fájlok újra meg újra beolvasásra kerülhetnek a lemezről. A másik probléma, hogy egyszerre csak egy kérést dolgoznak fel. Az állomány nagy lehet, és annak továbbítása idején a többi kérés blokkolva várakozni kényszerül.

Az első nyilvánvaló javítási lehetőség (amit minden webszerver alkalmaz is), hogy egy gyorstárat (cache) tartanak a memóriában, mely az n legutoljára beolvasott állományt vagy egy bizonyos gigabájtnyi tartalmat tárol. A kiszolgáló mindig megnézi a gyorstárat, mielőtt a merevlemezhez fordulna. Ha ott megvan az állomány, akkor rögtön ki lehet olvasni a memóriából, azaz nincs szükség lemezhozzáférésre. A hatékony gyorstárazáshoz sok központi memória és valamivel több feldolgozási idő is szükséges (a tárban való keresés, illetve a tár tartalmának kezelése miatt). Az így elérhető időmegtakarítás által az erőfeszítések és kiadások azonban még így is szinte mindig megtérülnek.

Az egyidejűleg több mint egyetlen kérés kiszolgálásának problémájával való megbirkózásra az egyik stratégia a szerver többszálúvá (multithreaded) tétele. Az egyik lehetséges megoldás szerint a kiszolgáló egy előtétmodulból (front-end module) és k darab feldolgozómodulból áll, amint azt a 7.21. ábra mutatja. Az előtétmodul fogadja az összes beérkező kérést. Az így létrejött szál mind ugyanahhoz a folyamathoz tartozik, tehát a feldolgozómodulok mind hozzáférhetnek a folyamat címterében lévő gyorstárhoz. Amikor beérkezik egy kérés, az előtétmodul fogadja azt, és létrehoz egy rövid leíró rekordot, majd átadja a rekordot az egyik feldolgozómodulnak.

7.21. ábra - Egy többszálú webszerver egy előtét- és több feldolgozómodullal

A feldolgozómodul először a gyorstárban keresi a kért állományt. Ha ott van, akkor átírja a rekordot, hogy legyen benne egy mutató az adott állományra. Ha nincs ott, akkor egy lemezműveletet indít, hogy beolvassa az állományt a gyorstárba (és esetleg kidob pár másik állományt a tárból, hogy legyen elég hely). Amikor az állomány betöltődött a lemezről, bekerül a gyorstárba, és visszaküldik az ügyfélnek is.

Ennek a sémának az az előnye, hogy amíg egy vagy több feldolgozómodul blokkolódik, mert egy lemez- vagy hálózati művelet befejezésére vár (és így nem fogyaszt processzoridőt), addig más modulok aktívan dolgozhatnak a többi kérésen. k darab feldolgozómodullal k-szor nagyobb átbocsátóképesség is elérhető az egyszálú szerverrel szemben. Persze ha a lemez vagy a hálózat a korlátozó tényező, akkor több lemezre vagy gyorsabb hálózatra van szükség az egyszálú modellel szembeni bármilyen tényleges előrelépéshez.

A korszerű webszerverek nem pusztán állományneveket fogadnak és állományokat adnak vissza. A valóságban a kérések feldolgozása egészen bonyolult is lehet. Ebből kifolyólag sok kiszolgálóban minden feldolgozómodul egy lépéssorozatot hajt végre. Az előtétmodul átad minden beérkező kérést az első rendelkezésre álló feldolgozómodulnak, amely erre a következő lépések egy részhalmazát hajtja végre attól függően, hogy melyek szükségesek az adott kérés feldolgozásához. Ezekre a lépésekre a TCP-összeköttetés és bármelyik biztonságos szállítási mechanizmus (például a 8. fejezetben ismertetendő SSL/TLS) létrehozása után kerül sor.

Az első lépésre azért van szükség, mert a bejövő kérés nem biztos, hogy szó szerint tartalmazza az állomány vagy program tényleges nevét. Beépített rövidítéseket tartalmazhat, amelyeket le kell fordítani. Egyszerű példa a www.cs.vu.nl URL. Itt az állománynév üres, tehát az URL-t ki kell egészíteni valamilyen alapértelmezett állománynévvel, általában az index.html-lel. Egy másik általános szabály a ~felhasznalo/ leképezése a felhasználó webkönyvtárára. Ezek a szabályok együtt is alkalmazhatóak. Az egyik szerző (AST) honlapja tehát a

http://www.cs.vu.nl/~ast

címen érhető el annak ellenére, hogy az állomány neve index.html egy bizonyos alapértelmezett könyvtárban.

A modern böngészők a konfigurációs információt is meg tudják állapítani, mint például a böngészőszoftver típusa vagy a felhasználó alapértelmezett nyelve (például olasz vagy angol). Ez lehetővé teszi, hogy a kiszolgáló mobil készülék esetén kis képeket tartalmazó, és az előnyben részesített nyelvű weboldalt válassza, ha van ilyen. A névkiegészítés általában nem annyira magától értetődő feladat, mint amilyennek első látásra tűnik, annak köszönhetően, hogy az utak könyvtárakra és programokra való leképezésére különféle konvenciók léteznek.

A második lépésben a feldolgozó modul megnézi, hogy az oldalra vonatkozó megkötések teljesülnek-e. Nem minden oldal érhető el a nagyközönség számára. Az, hogy az ügyfél lekérheti-e az oldalt, az ügyfél (például felhasználónevekkel és jelszavakkal megadott) személyazonosságától vagy az ügyfél DNS-en vagy IP-címterületen belüli helyétől függhet. Például egy oldalt a vállalaton belüli felhasználókra lehet korlátozni. Ennek megvalósítási módja a szerver felépítésétől függ. Például a népszerű Apache-szerver esetében az a konvenció, hogy egy .htaccess nevű, a hozzáférési megszorításokat tartalmazó állományt helyeznek el abban a könyvtárban, amelyik a korlátozott elérésű oldalt tartalmazza.

A harmadik és a negyedik lépés jelenti az oldal megszerzését. A feldolgozás szabályain múlik, hogy vajon megszerezhető-e a gyorstárból. Például azok az oldalak, amelyeket futó programok hoznak létre, nem mindig gyorstárazhatók, mert minden egyes futás alkalmával eltérő eredményt állíthatnak elő. Alkalmanként még az állományokat is ellenőrizni kell, hogy lássuk, megváltozott-e a tartalmuk, mert a régi tartalmak eltávolíthatók a gyorstárból. Ha az oldalnak egy program futtatására van szüksége, akkor felmerül a program paramétereinek vagy bemenetének beállítási problémája is. Ezek az adatok az útból vagy a kérés más részeiből érkeznek.

Az ötödik lépés a válasz egyéb részeinek megállapításából áll, amelyek az oldal tartalmát kísérik. Egy példa erre a MIME-típus, ami megállapítható a fájl kiterjesztéséből, az állomány vagy program kimenetének első néhány szavából, egy konfigurációs fájlból és valószínűleg más forrásokból is.

A hatodik lépés az oldal visszaküldése a hálózaton keresztül. A teljesítőképesség növelése érdekében a szerver és az ügyfél több oldal lekéréséhez is használhatja ugyanazt a TCP-összeköttetést. Ez az ismételt felhasználás azt jelenti, hogy szükség van valamilyen logikára ahhoz, hogy egy lekérdezést hozzárendeljen egy megosztott összeköttetéshez, és hogy minden egyes választ úgy küldjön vissza, hogy az korrekten kapcsolódik a kéréshez.

A hetedik lépésben más fontos nyilvántartások vezetése mellett egy bejegyzés kerül a rendszernaplóba adminisztratív célból. Az ilyen naplókból később értékes információt lehet kibányászni a felhasználók szokásaira vonatkozóan, például arról, hogy milyen sorrendben látogatják a felhasználók az oldalakat.

A weben történő navigálás, ahogyan azt eddig leírtuk, egymástól független oldalak lekérésének sorozatából áll. Nincs semmilyen koncepció egy bejelentkezési munkamenetre (login session). A böngésző elküld egy kérést, a kiszolgáló pedig visszaküld egy állományt, aztán elfelejti, hogy valaha is látta már az adott ügyfelet.

Ez a modell tökéletesen megfelel akkor, ha nyilvánosan hozzáférhető dokumentumokat akarunk elérni, és jól működött abban az időben, amikor a webet létrehozták. Nem alkalmas azonban arra, hogy különböző felhasználóknak más-más oldalakat küldjön vissza attól függően, hogy korábban mit kértek a szervertől. A webhellyekkel folytatott számos együttműködéshez, interakcióhoz szükséges ez a viselkedés. Az ügyfeleknek például néhány webhelyen (például újságoknál) regisztrálniuk kell magukat (esetleg fizetniük is kell), hogy használhassák az oldalakat. Ez felveti a kérdést: hogyan tudja a kiszolgáló megkülönböztetni a korábban már regisztrált felhasználóktól érkező kéréseket a többi felhasználó kérésétől? A második példát az e-kereskedelem adja. Ha egy felhasználó egy elektronikus áruházban bóklászik, és időnként belerak egy-egy árut a bevásárlókocsijába, akkor hogyan tudja a kiszolgáló nyomon követni a kocsi tartalmát? A harmadik példa a személyre szabható portálok esete, mint amilyen a Yahoo!. A felhasználók beállíthatják személyre szabott, részletes kezdőoldalukat, hogy az csak azt az információt tartalmazza, amelyekre ők kíváncsiak (például a részvényeik árfolyamáról és kedvenc sportcsapataikról). De hogyan tudja a kiszolgáló megjeleníteni a helyes oldalt, ha nem tudja, hogy ki a felhasználó?

Elsőre azt gondolhatnánk, hogy a kiszolgálók a felhasználókat az IP-címük megfigyelésével követik nyomon. Csakhogy ez az ötlet nem működik. Sok felhasználó dolgozik mások által is használt számítógépen, különösen otthon, és az IP-cím csupán a számítógépet azonosítja, nem a felhasználót. Még rosszabb, hogy sok vállalat NAT-ot használ, így minden felhasználó kimenő csomagjai ugyanazt az IP-címet hordozzák, azaz a szerver számára valamennyi NAT mögötti számítógép egyforma. Sok ISP DHCP segítségével rendeli az IP-címeket az ügyfeleihez. Az IP-címek idővel megváltoznak, így a szerver számára Ön egyszer csak a szomszédjának fog tűnni. Mindezek miatt a szerver nem használhatja az IP-címeket a felhasználók követésére.

Ezt a problémát oldja meg a gyakran bírált sütik (cookies) nevű mechanizmus. A név az ősi programozói zsargonból származik, és arra a helyzetre utal, amikor egy program meghív egy eljárást, és visszakap valamit, amit később esetleg fel kell mutatnia, hogy elvégeztessen valamit. Ebben az értelemben egy UNIX-állományleíró vagy egy Windows-objektumazonosító is tekinthető sütinek. A sütiket először a Netscape-böngészőben valósították meg 1994-ben, és ma az RFC 2109 részletezi.

Amikor egy ügyfél elkér egy weboldalt, a kiszolgáló a kért oldal mellett egy süti formájában járulékos információt is megadhat. A süti egy meglehetősen kicsi (legfeljebb 4 KB méretű), névvel ellátott karakterlánc, amit a szerver a böngészőhöz társíthat. Ez a társítás még mindig nem egyenértékű a felhasználó azonosításával, de az IP-címnél sokkal közelebb áll hozzá, és sokkal hasznosabb. A böngészők a felkínált sütiket egy bizonyos ideig, általában az ügyfél lemezének sütikönyvtárában tárolják úgy, hogy a sütik megmaradjanak a böngésző indításai során addig, amíg a felhasználó le nem tiltja a sütik használatát. A sütik nem futtatható programok, csak egyszerű karakterláncok. Elvileg egy süti is tartalmazhatna vírust, de mivel egyszerű adatként kezelik, a vírusnak hivatalosan nincs lehetősége ténylegesen futni és károkat okozni. Néhány számítógépes kalóznak persze mindig sikerül kihasználnia egy böngészőhibát, és elérnie az aktiválást.

Egy süti legfeljebb öt mezőt tartalmazhat, ahogy azt a 7.22. ábra mutatja. A Körzet megmondja, honnan származik. A böngészők dolga, hogy ellenőrizzék, hogy a kiszolgálók nem hazudnak-e a körzetükről. Az egyes körzeteknek ügyfelenként legfeljebb 20 sütit kell tárolniuk. Az Útvonal a kiszolgáló könyvtárrendszerének egy útvonalát jelenti, és meghatározza, hogy a kiszolgáló állományfájának melyik része használhatja a sütit. A mező értéke gyakran /, ami az egész fát jelenti.

7.22. ábra - Néhány példa a sütikre

A Tartalom mező név = érték felépítésű. A kiszolgáló bármit írhat a név és az érték helyére is. Ebben a mezőben tárolják a süti tényleges tartalmát.

A Lejárat mező adja meg, hogy mikor jár le a süti érvényessége. Ha ez a mező üres, akkor a böngésző kilépéskor eldobja a sütit. Az ilyen sütiket nemtartós sütinek (nonpersistent cookie) nevezzük. Ha meg van adva egy időpont és dátum, akkor a süti tartós (persistent), és a lejárat idejéig megőrzik. Az időt a greenwichi idő szerint (GMT) adják meg. Ha a kiszolgáló el akar távolítani egy sütit egy ügyfél merevlemezéről, akkor egyszerűen elküldi még egyszer, csak múltbeli lejárati idővel.

Végül, a Biztonságos mezőt úgy lehet beállítani, hogy azt jelezze, hogy a böngésző a kiszolgálónak csak biztonságos átvitellel, nevezetesen SSL/TLS segítségével (amelyet a 8. fejezetben ismertetünk) küldheti vissza a sütit. Ezt a funkciót az e-kereskedelmi, banki és egyéb biztonsági alkalmazásokban használják.

Azt már láttuk, hogyan lehet megszerezni a sütiket, de hogyan használják azokat? Nos, mielőtt a böngésző elküldene egy kérést valamely webhelyre, megnézi sütikönyvtárát, hogy a kérés célját képező körzetből helyeztek-e már el ott sütiket. Ha igen, az összes ilyen sütit, de csak ezeket mellékelik a kéréshez. A kiszolgáló a visszakapott sütiket úgy értelmezi, ahogyan csak akarja.

Nézzünk meg pár lehetséges használati esetet. A 7.22. ábrán az első sütit a toms-casino.com helyezte el, hogy azonosíthassa a látogatót. Amikor az ügyfél a következő héten visszatér, hogy még több pénzt szórjon el, a böngésző átküldi a sütit, hogy a kiszolgáló tudja, kiről is van szó. A látogató azonosítójával felvértezve a kiszolgáló megkeresheti a látogató rekordját egy adatbázisban, hogy ezen információ felhasználásával egy megfelelő weboldalat állítson elő. Ez az oldal a látogató ismert szokásainak megfelelően tartalmazhat egy pókerleosztást, az aznapi lóversenyek listáját vagy egy félkarú rablót.

A második süti a jills-store.com-tól érkezett. Itt a felállás az, hogy az ügyfél az áruházban mászkálva mindenféle jó dolgot szeretne vásárolni. Amikor egy jó vételt talál és rákattint, a kiszolgáló beleteszi azt a (szerveren kezelt) bevásárlókosarába, valamint összeállít egy termékkódot is tartalmazó sütit, és visszaküldi ezt az ügyfélnek. Ahogy az ügyfél új oldalakra kattintva tovább bóklászik az áruházban, a sütit minden új oldalkérésnél visszaküldik. A kiszolgáló a közben összegyűlő további megrendeléseket mind hozzáadja a sütihez. Végül, mikor a felhasználó a tovább a pénztárhoz gombra kattint, a kéréssel együtt a megrendelések immár teljes listáját tartalmazó sütit is elküldik. Ezáltal a kiszolgáló pontosan tudni fogja, hogy a vevő mit kíván megvásárolni.

A harmadik sütit egy webportál használja. Amikor a felhasználó rákattint egy a portálra mutató hivatkozásra, a böngésző átküldi a sütit. A portál ebből tudni fogja, hogy egy olyan oldalt kell összeállítania, mely a Cisco és az Oracle részvényárfolyamait, valamint a New York Jets csapat eredményeit tartalmazza. Mivel egy süti akár 4 KB-os is lehet, rengeteg hely van arra, hogy részletesebb beállításokat is megadhassunk a számunkra érdekes újsághírekre, helyi időjárásra, reklámajánlatokra stb. vonatkozóan.

A sütik felhasználásának egy sokkal vitatottabb területe a felhasználók online szokásainak felderítése. Ez a webhely üzemeltetői számára lehetővé teszi annak megértését, hogy a felhasználók hogyan navigálnak webhelyeiken, a hirdetők számára pedig, hogy profilokat állítsanak össze azokból a hirdetésekből vagy webhelyekből, amelyeket egy adott felhasználó megtekintett. A probléma az, hogy a felhasználókat általában nem érdekli az, hogy tevékenységüket nyomon követik akár részletes profilokkal, akár látszólag semmivel nem kapcsolatos webhelyekkel. Ennek ellenére a webes nyomonkövetés (web tracking) nagy üzlet. A DoubleClick-et, amely hirdetéseket szolgáltat és követ nyomon, az Alexa webfelügyeleti cég a világ 100 legforgalmasabb webhelye közé sorolta. A Google Analytics-et, ami az operátorok számára nyomon követi a webhely használatát, a világháló 100 000 legforgalmasabb webhelyének több mint a fele használja.

Egy szervernek könnyű nyomon követnie a felhasználó tevékenységét sütik segítségével. Tételezzük fel, hogy egy kiszolgáló nyomon kívánja követni, hány egyedi látogatója volt, és az egyes látogatók hány oldalt tekintettek meg, mielőtt elhagyták a webhelyet. Amikor az első kérés beérkezik, még nem tartozik hozzá süti, tehát a kiszolgáló elküld egy sütit Számláló = 1 tartalommal. Amikor a webhelyet a felhasználó ismét megtekinti, a sütit mindig visszaküldi a kiszolgálónak. A kiszolgáló a számlálót mindig megnöveli eggyel, és így küldi vissza az ügyfélnek. A számlálók nyomon követése révén a kiszolgáló láthatja, hogy hányan távoznak az első oldal megtekintése után, hányan a második után és így tovább.

A felhasználók böngészési szokásainak oldalak közötti nyomon követése csak egy kicsivel bonyolultabb. Ez a következőképpen működik. Egy reklámügynökség, mondjuk, az Alattomos Hirdetések, felkeresi a fontosabb webhelyeket, és az ügyfeleik termékeit hirdető reklámokat helyez el az oldalaikon, amiért a webhelyek tulajdonosainak bizonyos díjat fizet. Ahelyett azonban, hogy a webhelyeknek egy GIF-állományt adna elhelyezésre, csak egy URL-t ad, hogy azt rakják fel minden oldalra. Minden ilyen URL egy egyedi számot tartalmaz az elérési útban, mint például

http://www.alattomos.com/382674902342.gif

Amikor a felhasználó először látogat meg egy olyan P oldalt, amely egy ilyen hirdetést tartalmaz, a böngésző letölti a HTML-állományt. Ezt megvizsgálva észreveszi a www.alattomos.com-on levő képre mutató hivatkozást, elküld tehát egy kérést a képre vonatkozóan. Erre visszakap egy hirdetést tartalmazó GIF-állományt, egy egyedi felhasználói azonosítót tartalmazó sütivel együtt, ami a 7.22. ábra esetében 4627239101. Alattomosék feljegyzik maguknak, hogy az ilyen azonosítójú felhasználó meglátogatta a P oldalt. Ez könnyen megoldható, mivel az igényelt útra (382674902342.gif) csak a P oldal hivatkozik. Az adott hirdetés természetesen több ezer weboldalon is megjelenhet, de mindig különböző állománynévvel. Az Alattomos cég feltehetően egy penny töredékét kapja a termékek gyártójától minden továbbított hirdetés után.

Később, amikor a felhasználó meglátogat egy másik, Alattomosék hirdetését tartalmazó weboldalt, a böngésző először elkéri a HTML-állományt a kiszolgálótól. Azután meglátja, mondjuk a http://www.alattomos.com/193654919923.gif-re vonatkozó hivatkozást az oldalon, és elkéri ezt az állományt. Mivel rendelkezik már egy sütivel a www.alattomos.com körzetből, a böngésző a kéréshez mellékeli az Alattomos-féle sütit, ami a felhasználó azonosítóját tartalmazza. Alattomosék így már a második oldalt ismerik meg, amit a felhasználó meglátogatott.

Az Alattomos cég idővel egy teljes profilt állíthat össze a felhasználó böngészési szokásairól, még akkor is, ha az soha nem kattintott egyik hirdetésre sem. A felhasználó nevével ugyan még nem rendelkezik (bár ismeri az IP-címét, ami elég lehet ahhoz, hogy kikövetkeztesse a nevet más adatbázisokból). Ha viszont a felhasználó csak egyszer is megadja a nevét egy olyan webhelynek, mely együttműködik az Alattomossal, máris meglesz a teljes profilja névvel együtt, és bárki megvásárolhatja azt. Az ilyen adatok eladása elég jövedelmező az Alattomos számára ahhoz, hogy még több helyen még több hirdetést helyezzen el, és így még több adatot gyűjtsön.

Ráadásul, ha az Alattomos szuperalattomos akar lenni, a hirdetésnek nem is kell klasszikus reklámszalagnak (banner) lennie. Egy olyan „hirdetés”, ami egyetlen, háttérrel egyező színű képpontból áll (vagyis gyakorlatilag láthatatlan), pontosan ugyanazt eredményezi, mint egy reklámszalag: hatására a böngésző letölti az 1 × 1 méretű GIF-képet, és beküld minden sütit, ami a képpont körzetéből (domainjéből) származik.

A sütik az online magánéleti jogokról szóló viták gyújtópontjába kerültek a fentihez hasonló, nyomkövető viselkedésük miatt. Az egyész ügyben az a legalattomosabb, hogy sok felhasználó egyáltalán nem tud erről az információgyűjtésről, és még akár azt is gondolhatja, hogy biztonságban van, elvégre egyetlen hirdetésre sem kattintott rá. Ebből az okból kifolyólag azokat a sütiket, amelyek a felhasználókat az oldalak között nyomon követik, sokan kémprogramnak (spyware) tekintik. Vessen egy pillantást a böngészője által tárolt sütikre! A legtöbb böngésző megjeleníti ezt az információt az aktuális adatvédelmi beállításokkal együtt. Lehet, hogy meg fog lepődni a fellelt neveken, e-levél címeken, jelszavakon és homályos azonosítókon. Remélhetőleg nem fog hitelkártyaszámokat találni, de a visszaélés lehetősége nyilvánvaló.

Néhány felhasználó az összes süti visszautasítására állítja be a böngészőjét, hogy magánéletük háborítatlanságának legalább a látszatát megőrizzék. Ez azonban gondokat okozhat, mert sok webhely nem működik megfelelően sütik nélkül. Alternatív megoldásként sok böngésző lehetővé teszi a felhasználók számára a harmadik féltől származó (third-party) sütik blokkolását. A harmadik féltől származó süti nem az éppen letöltött oldalról származik, hanem egy másik webhelyről. Például az alattomos.com sütije, aminek használatára a P oldal böngészése közben került sor, egy egész más webhelyen van. Ezeknek a sütiknek a blokkolása segít megelőzni a webhelyek közötti nyomon követést. Böngészőkiterjesztések is telepíthetők a sütik használatának finomhangolása (vagy inkább használatuk mellőzése) érdekében. Ahogy a vita folytatódik, sok vállalat adatvédelmi házirendet dolgoz ki, amely a visszaélések elkerülése érdekében korlátozza azt, hogy hogyan történjen a cégnél az információmegosztás. A házirendek persze csak azt mondják meg, hogy mit mondjanak a vállalatok az információ kezeléséről. Például: „Az Öntől gyűjtött információt csak a saját üzleti tevékenységünkhöz használjuk fel” – ami az információ értékesítése is lehet.

A HTML (HyperText Markup Language – hipertextjelölő nyelv) a világhálóval együtt mutatkozott be. Lehetővé teszi, hogy a felhasználók weboldalakat állítsanak elő, melyek tartalmazhatnak szöveget, ábrákat, videót, hivatkozásokat más weboldalakra és egyebeket. A HTML jelölőnyelv vagy dokumentumok megformázásának módját leíró nyelv. A „jelölő” (markup) kifejezés azokból az időkből származik, amikor a szerkesztők a nyomtatók számára – melyek akkoriban emberi lények voltak – ténylegesen megjelölték a dokumentumokban, hogy melyik betűtípust kell használni és így tovább. A jelölőnyelvek ezért explicit formázóparancsokat tartalmaznak. A HTML-ben például a <b> a félkövér mód kezdetét, a </b> pedig a végét jelzi. A jelölőnyelvek legtöbb akadémiai szerző számára jól ismert további példái a LaTeX és a TeX.

A jelölőnyelv használatának legfőbb előnye a nem jelölőnyelvekkel szemben, hogy elválasztja a tartalmat attól, ahogyan azt meg kellene jeleníteni. Ezek után már egyszerű megírni egy böngészőt: csupán csak a jelölőparancsokat kell megértenie, majd alkalmazni azokat a tartalomra. Azzal, hogy a jelölőparancsokat beágyazták minden HTML-állományba és szabványosították őket, bármely webböngésző számára lehetővé vált, hogy tetszőleges weboldalt elolvashasson és újraformázhasson. Ez rendkívül fontos, mert lehet, hogy egy oldalt 1600 × 1200-as felbontás és 24 bites színmélység mellett egy csúcskategóriás számítógépen hoztak létre, de egy 640 × 320-as ablakban kell megjeleníteni egy mobiltelefonon.

Bár dokumentumokat kétségkívül bármely egyszerű szövegszerkesztő segítségével is írhatunk (és sokan ezt is teszik), lehetőség van azonban speciális HTML-szerkesztők vagy szövegszerkesztő programok használatára is, melyek elvégzik a munka nagy részét (de cserébe kevesebb beavatkozási lehetőséget adnak a felhasználónak a végeredmény részleteire nézve).

Egy egyszerű, HTML-ben megírt weboldal és annak böngészőben történő megjelenítése látszik a 7.23. ábrán. Minden weboldal fejlécből és törzsből áll, magát az oldalt pedig <html> és </html> formázási parancsok, ún. címkék (tags) határolják, bár a legtöbb böngésző nem tekinti hibának ezek hiányát. Amint a 7.23.(a) ábra mutatja, a fejlécet a <head> és </head>, a törzset pedig a <body> és </body> címkék fogják közre. A címkék szövegét direktívának (directive) nevezik. A legtöbb (de nem az összes) HTML-címke ilyen formátumú, vagyis a <valami> címke jelzi valaminek a kezdetét, és a </valami> a végét.

7.23. ábra - (a) Egy fiktív weboldal HTML-je. (b) A formázott oldal

A címkék lehetnek kis- és nagybetűsek is, azaz <head> és <HEAD> ugyanazt jelentik, de kompatibilitás szempontjából a kisbetűs írásmód a legjobb. A HTML-forrás formázásának nincs jelentősége. A HTML-értelmezők figyelmen kívül hagyják a fölösleges szóköz és kocsi-vissza karaktereket, hiszen mindig az aktuális megjelenítési területnek megfelelően kell újraformázniuk a szöveget. Ebből következik, hogy az ilyen, ún. white space (puha szóköz) karakterek tetszés szerint használhatók a HTML-forrásokban, hogy azok olvashatóbbak legyenek – legtöbbjük erre bizony rá is szorul. Ugyanezért nem elég egyszerűen üres sorokkal elválasztani a bekezdéseket, mivel azokat az értelmezők nem veszik figyelembe; erre a célra külön címkét definiáltak.

Egyes címkék attribútumokkal, azaz (névvel ellátott) paraméterekkel is rendelkeznek. Például a 7.23. ábrán látható <img> címkét egy képnek a soron belüli megjelenítésére használják. Két paramétere van: az src és az alt. Az első attribútum megadja a képhez tartozó URL-t. A HTML-szabvány nem rendelkezik arról, hogy mely képformátumok megengedettek. A gyakorlatban minden böngésző támogatja a GIF- és JPEG-állományokat. A böngészők támogathatnak más formátumokat is, de ez a lehetőség kétélű fegyver. Ha a felhasználó olyan böngészőhöz szokott, amely támogatja, mondjuk, a TIFF-állományokat, akkor esetleg ilyeneket fog rakni saját weboldalaira, és később meg fog lepődni, amikor a többi böngésző egyszerűen figyelmen kívül hagyja gyönyörű műveit.

A második attribútum megadja azt a helyettesítő szöveget, amit akkor kell használni, amikor a képet nem lehet megjeleníteni. A HTML-szabvány minden címkéhez definiálja az esetleges paramétereit, ha van egyáltalán, és azok jelentését. Minden paraméternek saját neve van, így a paraméterek megadásának sorrendje tetszőleges.

Maguk a HTML-dokumentumok az ISO 8859 Latin-1 karakterkészletben íródnak, de escape sorozatok segítségével a csak ASCII-t támogató billentyűzeteken is használhatók speciális karakterek, mint például az è. A szabvány a speciális karakterek listáját is tartalmazza. Ezek escape sorozatainak mindegyike & jellel kezdődik és pontosvesszővel végződik, az &nbsp; például egy szóközt, az &egrave; egy è, míg az &eacute; egy é karaktert generál. Mivel a <, > és & karaktereknek speciális jelentésük van, ezeket csak az &lt;, &gt; illetve az &amp; sorozatok segítségével lehet kifejezni.

A fejléc legfontosabb eleme a cím, melyet a <title> és </title> címkék határolnak. Ezenkívül egyéb járulékos információk is szerepelhetnek itt, bár egy sem fordul elő a példánkban. Maga a cím nem jelenik meg az oldalon, a böngészők leginkább az oldalt tartalmazó ablakot címkézik meg vele.

A 7.23. ábrán több címsor használatos. Minden címsort a <hn> címkék állítottak elő, ahol n egy 1 és 6 közé eső számot jelent. A <h1> a legfontosabb címsor, a <h6> a legkevésbé fontos. Ezek után a böngészőre van bízva, hogy a címsorokat ténylegesen hogyan jeleníti meg. A kisebb számmal jelzett címsorok tipikusan nagyobb és vastagabb betűtípussal jelennek meg, de a böngésző akár különböző színeket is rendelhet a különböző szintű címsorokhoz. A <h1> címsorok általában nagy, félkövér betűtípussal szerepelnek, alattuk és felettük legalább egy üres sorral. A <h2> szintű címsorok ugyanakkor kisebb méretű betűtípust használnak, és kisebb helyet is hagynak a címsor alatt és fölött.

A <b> és <i> címkék a félkövér (boldface) és dőlt betűs (italics) módba történő váltáshoz használatosak. A <hr> címke kikényszerít egy sortörést és vízszintes vonalat húz a kijelzőn.

A <p> címke új bekezdést kezd. A böngésző ezt például egy üres sor beszúrásával és némi behúzással jelenítheti meg. Érdekes módon a </p> címkét, ami a bekezdés végének megjelölésére szolgál, a lusta HTML-programozók gyakran elhagyják.

A HTML különféle mechanizmusokat biztosít listák, sőt akár egymásba ágyazott listák létrehozására is. A sorrend nélküli listák, mint amilyenek a 7.23. ábrán is láthatók, <ul> címkével kezdődnek, a listaelemeket pedig az <li> jelzi. Létezik egy <ol> címke is, a sorszámozott listák indításához. A sorrend nélküli listákban az egyes elemek előtt gyakran pontok () jelennek meg. A sorszámozott listák elemeit a böngésző számozza meg.

Végül elérkeztünk a hiperhivatkozásokhoz. Erre látunk példákat a 7.23. ábrán, melyek az <a> (anchor, horgony) és </a> címkéket használják. Az <a>-nak számos paramétere van, melyek közül a legfontosabb a href, ami a hivatkozott URL-t tartalmazza. Az <a> és </a> közötti szöveg megjelenítésre kerül. Ha rákattintunk, akkor egy új oldalra jutunk el. Más elemekkel történő hivatkozás is megengedett. Például meg lehet adni egy képet az <a> és </a> címkék között az <img> használatával. Ebben az esetben a kép jelenik meg, és az erre való kattintás aktiválja a hiperhivatkozást.

Számos más HTML-címke és attribútum létezik, amelyeket nem láttunk ebben az egyszerű mintában. Például az <a> címke kaphat egy name paramétert is, melynek segítségével beültet egy hiperhivatkozást magába az oldalba. Ez lehetővé teszi például, hogy egy hiperhivatkozás az oldal közepére mutasson. Ez azoknak a weboldalaknak hasznos, amelyek olyan tartalomjegyzékkel kezdődnek, amelynek elemeire rá lehet kattintani. A tartalomjegyzék egy elemére kattintva a felhasználó ugyanannak az oldalnak a megfelelő részére fog ugrani. Egy eltérő címkére példa a <br>. Ez a böngészőt a sortörésre és egy új sor megkezdésére kényszeríti.

Valószínűleg az a legjobb módja a címkék megértésének, ha működés közben látjuk őket. Ehhez keressen egy weboldalt és nézze meg a HTML-t a böngészőjében, hogy lássa, hogyan állították össze az oldalt. A böngészők többségében található egy forrás megjelenítése (view source) vagy hasonló nevű menüpont. Ezt kiválasztva az aktuális oldal tényleges, formázott képe helyett annak HTML-forrását tekinthetjük meg.

Felvázoltuk azokat a címkéket, amelyek a web kezdete óta léteznek. A HTML folyamatosan fejlődik. A 7.24. ábra bemutat néhány tulajdonságot, amelyeket a HTML egymást követő verzióiban vezettek be. A HTML 1.0 a HTML-nek arra a verziójára utal, amit a világháló megjelenésekor használtak. A HTML 2.0, 3.0 és 4.0 verziói néhány éven belül, egymást gyorsan követve jelentek meg, a web robbanásszerű fejlődésével. A HTML 4.0 után közel tíz év telt el, mire a következő fő verzió, a HTML 5.0 szabványosításához vezető út világossá vált. Mivel ez egy nagyobb frissítés, amely egységesíti azokat a módszereket, amelyekkel a böngészők a gazdag tartalmakat kezelik, a HTML 5.0 kidolgozása folyamatban van, és nem várható, hogy a szabvány 2012 előtt megszületik. A szabványok dacára a fontosabb böngészők már támogatják a HTML 5.0 funkcióit.

7.24. ábra - Néhány eltérés a HTML-verziók között

A HTML-verziók fejlődése az olyan új képességekkel történő bővülésről szól, amelyeket az emberek igényeltek, de a szabvánnyá válás előtt nem szabványos módon (például beépülő modulokkal) kellett megoldani a problémáikat. Például a HTML 1.0 és 2.0 verziókban még nem voltak táblázatok. Ezek a HTML 3.0-ban jelentek meg. Egy HTML-táblázat egy vagy több sorból áll, a sorok pedig egy vagy több cellából (table cell), melyek sok mindent tartalmazhatnak (például szöveget, képeket, további táblázatokat). A HTML 3.0 előtt azok a szerzők, akiknek táblázatra volt szükségük, valamilyen ad-hoc módszerhez kellett folyamodniuk, például beillesztettek egy táblázatot tartalmazó képet.

A HTML 4.0 további lehetőségeket tartalmazott. Ezek között van olyan, amely a hátrányos helyzetű felhasználók számára biztosít hozzáférési lehetőséget, amely objektumbeágyazást tesz lehetővé (ez az <img> címke általánosítása úgy, hogy más objektumok is beágyazhatók legyenek az oldalakba), amely támogatja a szkripteket (megengedve a dinamikus tartalmat). További lehetőségek is vannak.

A HTML 5.0 számos képességgel rendelkezik azoknak a gazdag médiumoknak a kezeléséhez, amelyeket ma rendszeresen használnak a világhálón. Videót és hangot lehet beágyazni az oldalakba, és lejátszatni azokat a böngészővel anélkül, hogy a felhasználónak beépülő modulokat kellene telepítenie. Az ábrákat a böngészőben lehet létrehozni vektorgrafikaként, a bittérképes képformátumok (mint a JPEG és a GIF) használata helyett. A parancsfájlok futtatását is jobban támogatja, például a háttérben futó számítási szálakkal és a háttértárolóhoz történő hozzáféréssel. Ezek a szolgáltatások segítenek azoknak a weboldalaknak a támogatásában, amelyek sokkal inkább hasonlítanak felhasználói felülettel rendelkező hagyományos alkalmazásokra, mint dokumentumokra. A web ebbe az irányba halad.

Van egy fontos képesség, amit eddig nem tárgyaltunk meg: az adatbevitel. A HTML 1.0 alapvetően egyirányú volt. A felhasználók lekérhettek oldalakat a tartalomszolgáltatóktól, de bonyolult volt a másik irányba információt visszaküldeni. Gyorsan nyilvánvalóvá vált, hogy szükség van a kétirányú forgalomra a világhálón elhelyezett termékekre történő rendelések felvételéhez, regisztrációs kártyák online kitöltéséhez, a megadott kifejezés megkereséséhez és még sok minden máshoz.

A felhasználó által megadott adat elküldése (a böngészőn keresztül) a kiszolgálóhoz kétfajta segítséget igényel. Először is arra van szükség, hogy a HTTP legyen képes adatokat szállítani abban az irányban. Egy későbbi szakaszban leírjuk ennek a módját; a HTTP a POST metódust használja. A második követelmény, hogy legyen képes olyan felhasználói csatlakozó felületi elemek megjelenítésére, amelyek összegyűjtik és becsomagolják a betáplált adatokat. Az űrlapok ezzel a funkcionalitással a HTML 2.0-ban jelentek meg.

Az űrlapok dobozokat vagy gombokat tartalmazhatnak, amelyek lehetővé teszik a felhasználók számára, hogy információt írhassanak be, vagy a felkínált lehetőségek közül választhassanak, majd az információt visszaküldhessék az oldal tulajdonosának. Az űrlapokat éppen úgy írják meg, mint a HTML más részeit, ahogyan az a 7.25. ábra példáján látható. Megjegyezzük, hogy az űrlapok még mindig statikus tartalmak. Ugyanúgy viselkednek, függetlenül attól, hogy ki használja őket. A dinamikus tartalom, amelyet később tárgyalunk, sokkal kifinomultabb módokat kínál a bevitt adatok összegyűjtésére egy olyan program segítségével, amelynek viselkedése a böngésző környezetétől függhet.

7.25. ábra - (a) Egy megrendelőlap HTML-je. (b) A megformázott oldal

Mint minden űrlapot, ezt is a <form> és </form> címkék fogják közre. Ennek a címkének az attribútumai meghatározzák, hogy mit kell tenni a bevitt adatokkal. Ebben az esetben a POST metódus használatával el kell küldeni az adatokat az URL-lel meghatározott címre. A címkébe nem zárt szöveg egyszerűen megjelenik. Minden szokásos címke (mint például a <b>) megengedett az űrlapon belül, hogy az oldal készítője vezérelhesse az űrlapnak a képernyőn történő megjelenését.

Ezen az űrlapon háromfajta bemeneti dobozt használtunk, melyek mindegyike az <input> címkét használja. Ennek sokfajta paramétere van, amelyek meghatározzák a megjelenített doboz méretét, természetét és használatának módját. Ennek legközönségesebb formái a felhasználó szövegét befogadó üres mezők, a kipipálható dobozok, és a submit (elküld) gombok, amelyek az adatoknak a kiszolgálóra történő visszaküldését idézik elő.

Az első fajta bemeneti doboz a „Név” szöveg után következő szöveg (text) típusú doboz. A doboz 46 karakter hosszú, és a felhasználótól egy szöveget várunk bele, amelyet azután a customer változóban tárolunk el.

Az űrlap következő sora a felhasználó városának nevét kérdezi, 46 oszlop szélesen. Az ezután következő sor az utcára, a házszámra és a lakásszámra kérdez rá. Mivel nem használtunk <p> címkéket a mezők között, így a böngésző mindet egy sorban fogja megjeleníteni (ahelyett, hogy külön bekezdésekbe helyezné azokat), ha elférnek. A böngésző szemében ez a bekezdés csak hat elemet tartalmaz: három karakterláncot és három dobozt, váltakozva. A következő sor a hitelkártya számát és lejáratának dátumát kérdezi meg. A hitelkártyaszámokat csak megfelelő biztonsági intézkedések megtétele után lenne szabad átvinni az interneten. Ezek közül néhányat a 8. fejezetben fogunk tárgyalni.

A lejárat dátuma után új funkcióval találkozunk: a rádiógombokkal (radio buttons). Ezeket akkor használják, amikor két vagy több lehetőség között kell választani. Az elméleti modell itt egy autórádió volt, melynek fél tucat gombja van az állomások kiválasztására. Ha az egyik gombra rákattintanak, az az ugyanabban a csoportban levő összes többit kikapcsolja. A vizuális megjelenítés a böngészőtől függ. A szerkentyű méretének megadására is két rádiógombot használtunk. A két csoportot a name paramétereikkel különböztetjük meg, nem pedig olyan statikus címkékkel, mint mondjuk a <radiobutton> és a </radiobutton>.

A value paramétereket a lenyomott rádiógomb jelzésére használják. Például attól függően, hogy a felhasználó melyik hitelkártya-változatot választotta, a cc változó értéke vagy a „visacard”, vagy a „mastercard” karakterláncra fog beállni.

A két rádiógombkészlet után eljutottunk a szállítási lehetőségekhez, amelyet egy ellenőrző gomb, checkbox típusú négyzet (jelölőnégyzet) jelképez. Ez lehet ki- vagy bekapcsolva. A rádiógomboktól eltérően, amelyeknél a halmazból pontosan egyet kell kiválasztani, minden checkbox típusú doboz ki- vagy bekapcsolt állapotban lehet, az összes többitől függetlenül.

Végül elérkeztünk a submit (küldés) gombhoz. A value (érték) karakterlánc a gomb címkéje, és ez jelenik meg. Amikor a felhasználó a Rendelés elküldése gombra kattint, a böngésző egyetlen hosszú sorba csomagolja az összegyűlt információt, és visszaküldi a kiszolgálónak arra az URL-re, amit a <form> címke részeként adtak meg. A böngésző egy egyszerű kódolást használ. A mezők elválasztására az & szolgál, a szóközt pedig a + jelképezi. Példánk űrlapjában ez a sor a 7.26. ábrán láthatóhoz hasonló lehet.

7.26. ábra - A böngésző egy lehetséges válasza a kiszolgálónak a felhasználó által megadott információval

Ezt a karakterláncot egyetlen sorként küldik vissza a kiszolgálónak. (Itt azért törtük három sorba, mert nem elég széles az oldal.) A karakterlánc értelmezése a kiszolgálóra van bízva; nagy valószínűséggel átadja az információt egy programnak, ami feldolgozza azt. Ennek lehetséges módjait a következő szakaszban tárgyaljuk.

Másfajta beviteli mezők is léteznek, melyeket nem mutattunk be ebben az egyszerű példában. Két ilyen típus a password (jelszó) és a textarea (szöveges terület). Egy password doboz ugyanolyan, mint egy text doboz (az alapértelmezett típus, melyet nem szükséges megnevezni), kivéve, hogy a begépelt karakterek nem jelennek meg. A textarea doboz megegyezik a text dobozzal, csak több sort is tartalmazhat.

Hosszú listákhoz, amelyekből egy elemet kell kiválasztani, létrehozták a <select> és </select> címkéket, amely címkék között a választási lehetőségek felsorolása található. Ez a felsorolás gyakran legördülő menü formájában jelenik meg. A szemantika olyan, mint a rádiógomboké, hacsak nincs megadva a multiple (többszörös) paraméter, amelynél a szemantika megegyezik a jelölőnégyzetek szemantikájával.

Végül, arra is van mód, hogy jelezzük az alapértelmezett vagy kezdeti értékeket, amelyeket a felhasználó megváltoztathat. Például, ha a text dobozt ellátjuk a value mezővel, annak tartalma megjelenik a felhasználó számára az űrlapon, hogy szerkeszthesse vagy törölje azt.

A HTML eredeti célja a dokumentum szerkezetének, nem pedig a megjelenésének meghatározása volt. Például a

<h1> Deborah fényképei </h1>

parancs arra utasítja a böngészőt, hogy emelje ki a címsort, de nem mond semmit a betűtípusról, a betűméretről vagy a színről. Ezek a böngészőre vannak bízva, hiszen az ismeri a képernyő tulajdonságait (például hogy hány képpontból áll). Sok webtervező azonban teljesen uralni akarta az oldalaik megjelenítését, ezért új címkéket adtak a HTML-hez, hogy befolyásolni lehessen a megjelenítést, mint például az alábbi címkével:

<font face=”helvetica” size=”24” color=”red”> Deborah fényképei </font>

Emellett lehetővé vált a képernyőterületen való elhelyezkedés pontos megadása is. Ezzel a megközelítéssel az a baj, hogy fárasztó és nagyra duzzadt, nem hordozható HTML-t eredményez. Az oldal ugyan tökéletesen jelenhet meg abban a böngészőben, amelyben kifejlesztették, de teljes lehet a káosz egy másik böngészőben vagy ugyanannak a böngészőnek egy másik kiadásában, illetve más képernyőfelbontásnál.

Jobb választás a stíluslapok (style sheets) használata. A szövegszerkesztőkben lévő stíluslapok lehetővé teszik a szerzők számára, hogy a szöveghez logikai stílust rendeljenek fizikai stílus helyett, például „első bekezdés”-t a „dőlt betűs szöveg” helyett. Minden egyes stílus megjelenését önállóan határozzák meg. Ily módon, ha a szerző úgy dönt, hogy a 14 pontos, kék és dőlt betűs első bekezdéseket 18 pontos, félkövér, megdöbbentő rózsaszínűre változtatja, mindössze egyetlen definíciót kell megváltoztatnia az egész dokumentum átalakításához.

A CSS (Cascading Style Sheets – egymásba ágyazható stíluslapok) a HTML 4.0-val vezette be a stíluslapokat a világhálóra, azonban a széles körű használat és a böngészők támogatása nem kezdődött meg 2000 előtt. A CSS egy egyszerű nyelvet határoz meg a címkézett tartalom megjelenését vezérlő szabályok leírásához. Nézzünk meg egy példát! Tételezzük fel, hogy az Egyesült Szerkentyű Rt. menő oldalakat szeretne létrehozni, tengerészkék Arial betűtípusú szöveggel a piszkosfehér háttéren, különböző szintű címsorokkal, amelyek 100%-kal és 50%-kal nagyobbak, mint a szöveg. A 7.27. ábra CSS-definíciója megadja ezeket a szabályokat.

7.27. ábra - Egy CSS-példa

Mint látható, a stílusok meghatározása tömör lehet. Minden sor kiválaszt egy elemet, amelyre vonatkozik, és megadja a tulajdonságok értékeit. Az elem tulajdonságai alapértelmezés szerint minden olyan HTML-elemre is vonatkoznak, amelyeket az tartalmaz. Tehát a body stílusa meghatározza a dokumentum törzsében lévő bekezdések szövegének stílusát. Léteznek kényelmes rövidítések a színekre (például red a vörös színhez). Valamennyi olyan stílusparaméternek, amit nem határoztunk meg, a böngésző ad alapértelmezett értéket. Ez a viselkedés választhatóvá teszi a stíluslap definíciókat, de nélkülük is meg fognak jelenni az oldalak valamilyen értelmes módon.

A stíluslapok beágyazhatók a HTML-állományokba (például a <style> címke használatával), de sokkal gyakrabban helyezik őket egy különálló állományba és hivatkoznak rájuk. Például az Egyesült Szerkentyű oldalának <head> címkéje úgy módosítható, hogy a 7.28. ábrán látható módon hivatkozzon az awistyle.css állományban lévő stíluslapra. A példa a CSS-fájlok MIME-típusát is mutatja, ami text/css.

7.28. ábra - Egy CSS-stíluslap beágyazása

Ennek a stratégiának két előnye van. Először is, lehetővé teszi, hogy a stílusoknak egy halmazát egy webhely több oldalán is felhasználjuk. Ez a szervezés egységes megjelenést kölcsönöz az oldalaknak még akkor is, ha különböző szerzők különböző időpontokban fejlesztették, és lehetővé teszi az egész webhely megjelenésének módosítását egyetlen CSS-állomány, és nem a HTML szerkesztésével. Ezt a módszert egy C program #include állományához hasonlíthatjuk: ha ott megváltoztatunk egy makrodefiníciót, akkor az megváltozik az erre hivatkozó összes állományban is. A másik előny az, hogy a letöltött HTML-állományok kicsik maradhatnak. Ennek az az oka, hogy a böngésző a CSS-állománynak egyetlen másolatát tölti le az összes olyan oldal számára, amelyek hivatkoznak rá. Nem szükséges minden egyes weboldallal együtt egy új másolatot is letöltenie.

Nézzük meg a kiszolgálóoldali tartalom-előállítás esetét egy kicsit részletesebben! Egy egyszerű helyzet, amelyben szerveroldali feldolgozásra van szükség, az űrlapok használata. Tegyük fel, hogy a felhasználó kitöltötte a 7.25.(b) ábra szerkentyű megrendelő űrlapját, és rákattintott a Rendelés elküldése gombra. Amikor a felhasználó kattint, az űrlappal meghatározott URL-en lévő kiszolgálónak egy kérés megy a felhasználó által kitöltött űrlap tartalmával együtt (ebben az esetben egy POST metódussal a http://widget.com/cgi‑bin/order.cgi URL-re). Ezeket az adatokat át kell adni feldolgozásra egy programnak vagy szkriptnek. Tehát az URL azonosítja a futtatandó programot, az adatok pedig a program bemenetére kerülnek. Ebben az esetben a feldolgozás magába foglalná a rendelésnek a cég belső rendszerébe léptetését, az ügyfélnyilvántartás frissítését és a hitelkártya megterhelését. A kérésre válaszként kapott weboldal attól függ, hogy mi történt a feldolgozás során. Ez nem fix, mindig ugyanaz, mint egy statikus oldalnál. Ha a megrendelés sikeres, a visszaküldött oldal megadhatja a kiszállítás várható időpontját. Ha sikertelen, a visszaküldött oldal tájékoztathat arról, hogy a kért szerkentyűk nincsenek raktáron, vagy a hitelkártya valamilyen okból nem volt érvényes.

Az, hogy a kiszolgáló miért egy programot futtat ahelyett, hogy egy állományt keresne meg és küldene vissza, a szerver kialakításától függ. Ezt nem maguk a webes protokollok határozzák meg. Ennek az az oka, hogy a felhasználói csatlakozófelület egyedi kialakítású, és a böngészőnek nem szükséges ismernie a részleteket. Ami a böngészőt illeti, az egyszerűen csak egy kérés összeállítását és egy oldal lekérését végzi.

Ennek ellenére szabványos API-kat dolgoztak ki a webszerverek számára a programok meghívásához. Ezeknek a csatlakozófelületeknek a léte megkönnyíti a fejlesztők dolgát akkor, amikor a különféle szervereket webalkalmazásokkal egészítik ki. Röviden áttekintünk két API-t, hogy legyen némi elképzelésünk ezekről, hogy miket is tartalmaznak.

Az első API egy dinamikus oldallekérések kezeléséhez használható módszer, mely a web kezdete óta elérhető. Ezt CGI-nek (Common Gateway Interface – általános átjáró interfész) nevezik, és az RFC 3875 ismerteti. A CGI egy csatlakozófelületet, interfészt biztosít, mely lehetővé teszi, hogy a webszerverek olyan kiszolgálóoldali programokkal és szkriptekkel beszéljenek, melyek valamilyen bemenetet fogadnak el (például űrlapokból), és válaszul HTML-oldalakat állítanak elő. Ezeket a programokat valamilyen fejlesztőknek kényelmes nyelven írhatják, a fejlesztés könnyebbsége érdekében általában egy szkriptnyelven. Ez lehet Python, Ruby, Perl vagy az Ön kedvenc nyelve.

A CGI által meghívott programok szokás szerint egy cgi-bin nevű könyvtárban helyezkednek el, amely az URL-ben is látszik. A kiszolgáló leképezi az erre a könyvtárra vonatkozó kéréseket egy programnévre, és végrehajtja ezt a programot egy különálló folyamatként. A kéréssel együtt elküldött minden adatot bemenetként átadja a programnak. A program kimenete egy weblap, amit a kiszolgáló visszaküld a böngészőnek.

Példánkban az order.cgi programot a 7.26. ábrán látható módon kódolt űrlapról vett bemenettel a kiszolgáló hívja meg. A program elemzi a paramétereket és feldolgozza a rendelést. Egy hasznos megállapodás, hogy a program visszaküldi a megrendelő űrlap HTML-jét, ha bemenetként nem kapott bemeneti adatokat űrlapról. Így a program biztos lehet abban, hogy ismeri az űrlap megjelenési formáját.

A második API, amit szemügyre veszünk, az előzőtől eléggé eltérő. Itt az a megközelítés, hogy kis szkripteket ágyaznak be a HTML-oldalakba, melyeket maga a kiszolgáló futtat a weboldal előállítása érdekében. A PHP (PHP: Hypertext Preprocessor – hipertext előfeldolgozó) egy népszerű nyelv, mely megfelelő az ilyen szkriptek megírásához. Használatához a kiszolgálónak értenie kell a PHP-t csakúgy, mint ahogy a böngészőnek is értenie kell az CSS-t, hogy értelmezni tudja a stíluslapokat tartalmazó weboldalakat. A kiszolgálók a PHP-t tartalmazó weboldalakat általában az állomány kiterjesztése alapján azonosítják, ami php és nem html vagy htm.

A PHP-t egyszerűbb használni, mint a CGI-t. A 7.30.(a) ábra az űrlapok PHP-val történő kezelésére mutat egy példát. Az ábra felső részén egy szokványos HTML-oldal látható, benne egy egyszerű űrlappal. A <form> címke ezúttal az action.php állományt adja meg; ezt kell meghívni a paraméterek kezeléséhez, amikor a felhasználó beküldi az űrlapot. Az oldal két szövegdobozt jelenít meg: az egyik a nevet, a másik az életkort kéri. Miután ezeket kitöltötték, és az űrlapot beküldték, a kiszolgáló elemzi a 7.26. ábrához hasonló visszaküldött karakterláncot, és a nevet a name, a kort pedig az age változóba teszi. Ezután válaszként megkezdi a 7.30.(b) ábrán látható action.php állomány feldolgozását. Az állomány feldolgozása során a PHP-parancsok végrehajtásra kerülnek. Ha a felhasználó azt írta a dobozokba, hogy „Barbara” és „32”, akkor a visszaküldött HTML-oldal a 7.30.(c) ábrán látható lesz. Az űrlapok kezelése tehát rendkívül egyszerű lesz a PHP használatával.

7.30. ábra - (a) Egy űrlapot tartalmazó weboldal. (b) PHP-szkript az űrlap adatainak kezelésére. (c) A PHP-szkript kimenete, ha a bemenet „Barbara”, illetve „32” volt

Annak ellenére, hogy a PHP-t könnyű használni, valójában egy nagyon hatékony programozási nyelv, mely a web és a kiszolgálóoldali adatbázis közötti kapcsolatot hivatott megteremteni. Vannak benne változók, karakterláncok, tömbök, tartalmazza a C-ben megtalálható vezérlési szerkezetek többségét, és ezenfelül egy, a puszta printf-nél sokkal hatékonyabb I/O-t. A PHP nyílt forráskódú, szabadon hozzáférhető és széles körben használják. A PHP-t kifejezetten úgy tervezték, hogy jól működjön az Apache-csal, amely a világ legelterjedtebb webszervere, és szintén nyílt forráskódú. A PHP-ről többet is megtudhatunk Valade [2009] munkájából.

Már két különböző módot is láttunk dinamikus HTML-oldalak előállítására: a CGI-szkripteket és a beágyazott PHP-t. Számos más megoldás is létezik, amelyek közül választani lehet. A JSP (JavaServer Pages – Java kiszolgáló oldalak) hasonlít a PHP-hez, azzal a különbséggel, hogy a dinamikus rész PHP helyett a Java programozási nyelven íródik. Azoknak az oldalaknak, melyek ezt az eljárást használják, .jsp a kiterjesztésük. Az ASP.NET (Active Server Pages .NET – aktív kiszolgálóoldalak) nem más, mint a PHP vagy a JSP Microsoft-féle változata. Ezek olyan programok, amelyek a Microsoft saját .NET hálózatos alkalmazási keretrendszerét használják a dinamikus tartalom előállítására. Az ilyen módszerrel készült oldalakhoz az .aspx kiterjesztést használják. E három technika közti választás általában inkább politikai (nyílt forrás vagy Microsoft), mint technikai kérdés, mivel a három nyelv nagyjából egyenértékű.

A PHP- és CGI-szkriptek megoldják a kiszogáló oldalán az adatbevitel kezelésének és az adatbázisok elérésének problémáját. Ezek a szkriptek képesek az űrlapokból beérkező információ fogadására, információ kikeresésére egy vagy több adatbázisból, valamint az eredményeket tartalmazó HTML-oldalak előállítására. Egyikük sem képes azonban egérműveletekre reagálni vagy a felhasználókkal közvetlenül együttműködni. Ilyen célok érdekében olyan szkripteket kell beágyazni a HTML-oldalakba, amelyek végrehajtása nem a kiszolgáló, hanem az ügyfél oldalán történik. A HTML 4.0-tól kezdődően vált lehetővé az ilyen szkriptek használata, a <script> címke segítségével. Azokat a módszereket, amelyeket ezeknek az interaktív weblapoknak a létrehozására használnak, dinamikus HTML-ként említik.

A legnépszerűbb ügyféloldali szkriptnyelv a JavaScript, melyet most röviden be is mutatunk. A nevek közötti hasonlóság ellenére a JavaScriptnek szinte semmi köze sincs a Java programozási nyelvhez. A többi szkriptnyelvhez hasonlóan ez is nagyon magas szintű nyelv. Egyetlen JavaScript-sorral megoldható például az, hogy földobjunk egy dialógusablakot, megvárjuk a szöveges bevitelt, majd az eredményül kapott karakterláncot egy változóban tároljuk. Az ilyen magas szintű képességek miatt a JavaScript ideális nyelv interaktív weboldalak létrehozására. Másrészt viszont az a tény, hogy e nyelv gyorsabban mutálódik, mint a röntgengépbe szorult muslica, rendkívül nehézzé teszi, hogy olyan JavaScript-programokat írjunk, amelyek minden platformon működnek. Egy nap talán ez a helyzet is rendeződik.

A 7.31. ábra egy JavaScript-programra mutat példát. A 7.30. ábrához hasonlóan itt is egy űrlap jelenik meg, ami megkérdezi a nevet és az életkort, majd megjósolja, hogy hány éves lesz az adott személy jövőre. Az oldal törzse majdnem ugyanaz, mint a PHP-példában. A legfontosabb különbség itt az Elküld gomb deklarációjában és a benne levő hozzárendelési utasításban van. Ez a hozzárendelési utasítás mondja meg a böngészőnek, hogy gombnyomásra hívja meg a valasz szkriptet, és adja át neki az űrlapot mint paramétert.

7.31. ábra - A JavaScript használata egy űrlap feldolgozására

Ami itt teljesen új, az a valasz nevű JavaScript-függvény deklarációja a HTML-állomány fejlécében, ahol rendszerint csak a cím, háttérszín stb. található. Ez a függvény kiolvassa a nev mező értékét az űrlapból, és karakterláncként tárolja a szemely nevű változóban. Kiolvassa még a kor mező értékét is, átalakítja egésszé az eval függvény használatával, hozzáad egyet, és az eredményt tárolja az evek változóban. Azután megnyit egy dokumentumot a kimenet számára, elvégez négy kiíratást a writeln metódussal, majd lezárja a dokumentumot. A dokumentum egy HTML-állomány lesz, amint az a benne lévő különféle HTML-címkékből is látszik. Végül a böngésző megjeleníti a dokumentumot a képernyőn.

Fontos megértenünk, hogy a PHP és JavaScript hasonlók abból a szempontból, hogy mindkettő kódot ágyaz be a HTML-állományokba, de teljesen máshogy kerülnek feldolgozásra. A 7.30. ábrán látható PHP-példában, miután a felhasználó rákattintott az Elküld gombra, a böngésző összegyűjti az információt egy hosszú karakterláncba, és egy PHP-oldalra vonatkozó kérés formájában elküldi azt a kiszolgálónak. A kiszolgáló betölti a PHP-állományt, és egy új HTML-oldal létrehozása érdekében végrehajtja a benne lévő PHP-szkriptet. Ezt az oldalt visszaküldi megjelenítésre a böngészőnek. A böngésző még abban sem lehet biztos, hogy az oldalt egy program állította elő. Ez a feldolgozási folyamat látható a 7.32.(a) ábrán az 1-4 lépésekben.

7.32. ábra - (a) Kiszolgálóoldali szkript PHP-vel. (b) Ügyféloldali szkript JavaScripttel

A 7.31. ábrán látható JavaScript-példában az Elküld gomb megnyomása után a böngésző értelmezi az adott oldalon található JavaScript-függvényt. Mindez ott helyben, a böngészőn belül kerül végrehajtásra. A kiszolgálóval nincs semmilyen kapcsolat. Ez a feldolgozási folyamat látható a 7.32.(b) ábrán az 1-es és 2-es lépésekben. Ennek következtében az eredmény látszólag azonnal megjelenik, míg a PHP esetében előfordulhat néhány másodperces késedelem, amíg az eredményül kapott HTML-oldal megérkezik az ügyfélhez.

Ez az eltérés nem azt jelenti, hogy a JavaScript jobb, mint a PHP, hiszen a kettőnek egészen más a felhasználási területe. A PHP (és ebből adódóan a JSP és az ASP is) akkor használatos, amikor egy kiszolgálón lévő adatbázissal kell együttműködni. A JavaScriptet (és más ügyféloldali nyelveket is, amelyeket később említünk, mint például a VBScriptet) ezzel szemben akkor használják, amikor a kliensszámítógép előtt ülő felhasználóval kell együttműködni. Mindazonáltal lehetséges ezek kombinálása, ahogyan azt hamarosan látni fogjuk.

A JavaScript nem az egyedüli mód, ha erősen interaktív weboldalakat kívánunk előállítani. Windows-platformokon az egyik alternatíva erre a Visual Basic-alapú VBScript. Egy további népszerű, több platformon is támogatott módszer a kisalkalmazások (applets) használata. Ezek apró Java-programok, melyeket egy virtuális számítógép, a JVM (Java Virtual Machine – Java virtuális gép) számára gépi utasításokra fordítottak. A HTML-oldalakba (az <applet> és </applet> címkék közé) ágyazható kisalkalmazásokat a JVM-képességgel rendelkező böngészők értelmezik. Mivel a Java-kisalkalmazásokat nem közvetlenül futtatják, hanem értelmezik, a Java-értelmező meggátolhatja, hogy Rossz Dolgokat tegyenek. Legalábbis elméletben. A gyakorlatban azonban a kisalkalmazás írók végtelen sok hibát találnak a Java I/O könyvtárakban.

A Microsoft, válaszul a Sun Java kisalkalmazásaira, létrehozta az ActiveX-vezérlőket (ActiveX controls) tartalmazó weboldalakat. Ezek a vezérlők olyan programok, melyeket az x86-os processzorok gépi nyelvére fordítottak le, és teljesen hardveren futtatnak. Ez a képességük sokkal gyorsabbá és rugalmasabbá teszi ezeket, mint az értelmezőt igénylő Java-kisalkalmazások, mert megtehetnek mindent, amit egy program megtehet. Amikor az Internet Explorer egy ActiveX-vezérlőt talál egy weboldalon, akkor letölti azt, ellenőrzi az azonosságát, és futtatja. Ismeretlen programok letöltése és futtatása azonban súlyos biztonsági kérdéseket vet fel, melyeket a 8. fejezetben válaszolunk meg.

Mivel szinte minden böngésző képes mind a Java-programok, mind a JavaScript értelmezésére, az a tervező, aki egy erősen interaktív weboldalt szeretne elkészíteni, legalább két módszer közül választhat, sőt ha a különböző platformok közti hordozhatóság nem szempont, akkor ehhez még az ActiveX is hozzájön. Általános szabályként elmondhatjuk, hogy a JavaScript-programokat egyszerűbb megírni, a Java-kisalkalmazások gyorsabban hajtódnak végre, az ActiveX-vezérlők pedig a leggyorsabban futnak. Továbbá, mivel minden böngésző pontosan ugyanazt a JVM-et implementálja, de nincs két olyan böngésző, mely ugyanazt a JavaScript-verziót implementálná, ezért a Java-kisalkalmazások hordozhatóbbak, mint a JavaScript-programok. A JavaScriptről többet is megtudhatunk a témában íródott számos terjedelmes (olykor 1000 oldalnál is hosszabb) könyvből, mint például Flanagan [2010] művéből.

A rendkívül vonzó webalkalmazásoknak könnyen kezelhető felhasználói felületre és a távoli webszerverken tárolt adatok könnyű elérésére van szükségük. Azok a szkriptek, amelyeket az ügyfél oldalán (például JavaScript), és amelyeket a kiszolgáló oldalán (például PHP) létrehoznak, alapvető technikák egy adott probléma megoldásához. Ezeket a technikákat általában számos más, kulcsfontosságú technikával kombinálva, együtt szokták használni, amit AJAX-nak (Asynchronous JAvascript and Xml – aszinkron JavaScript és XML) neveznek. Számos teljes körű szolgáltatást nyújtó webalkalmazás, mint például a Google Gmail, a Maps és a Docs, AJAX segítségével készült.

Az AJAX némiképp zavarba ejtő, mert ez nem programnyelv, hanem olyan technikák halmaza, amelyek együttműködnek annak érdekében, hogy lehetővé tegyék a webalkalmazásokat, és amelyeknél minden bit ugyanolyan könnyen kezelhető és hatékony, mint a hagyományos asztali számítógépes alkalmazásoknál. Ezek a technikák a következők:

Mivel ez egy egész gyűjtemény, végignézzük mindegyik elemét, hogy lássuk, mivel járul hozzá a működéshez. Korábban már megvizsgáltuk a HTML-t és a CSS-t. Ezek a szabványok arra szolgálnak, hogy megadják a tartalmat és annak megjelenítési módját. Bármelyik program, amelyik képes HTML-t és CSS-t előállítani, a webböngészőt úgy használhatja, mint egy megjelenítő motor (display engine).

A DOM (Document Object Model – dokumentum objektum modell) egy HTML-oldal egyfajta megjelenési formája, amely programok számára elérhető. Ez egy fa struktúrájú ábrázolás, ami tükrözi a HTML-elemek szerkezetét. Például a 7.30.(a) ábrán megadott HTML DOM-fája látható a 7.33. ábrán. A gyökér egy html elem, ami az egész HTML-blokkot ábrázolja. Ez az elem a body elem szülője, ami pedig a form elem szülője. Az űrlap két, jobb oldalra rajzolt attribútummal rendelkezik, az egyik attribútum az űrlap továbbításához szükséges metódus (egy POST), a másik attribútum az űrlappal kapcsolatos tevékenységet határozza meg (egy URL-t ad meg, ahová a kérést küldeni kell). Ennek az elemnek három gyermeke van, amelyek az űrlapon lévő két bekezdéscímke és egy beviteli címke tükröződései. A fa alján levelek találhatók, amelyek elemeket vagy literálokat, például karakterláncokat tartalmaznak.

7.33. ábra - A 7.30.(a) ábra HTML-jének DOM-fája

A DOM-modell jelentősége abban áll, hogy a programok számára egyszerű lehetőséget kínál az oldal részeinek megváltoztatására. Nem kell újraírni az egész oldalt, csak a változást tartalmazó csomópontot kell kicserélni. Amikor ez a változás megtörténik, a böngésző ennek megfelelően frissíti a kijelzőt. Például, ha az oldal egyik részén lévő képet kicserélik a DOM-ban, a böngésző anélkül fogja frissíteni ezt a képet, hogy az oldal többi részét megváltoztatná. Már láttuk a DOM-ot működés közben, amikor a 7.31. ábra JavaScript példája sorokat adott hozzá a document elemhez, hogy új szövegsorokat jelenítsen meg a böngésző ablakának alján. A DOM hatékony módszer olyan oldalak készítéséhez, amelyek működés közben megváltozhatnak.

A harmadik technika, az XML (eXtensible Markup Language – kiterjeszthető jelölőnyelv) egy olyan nyelv, amely strukturált tartalom meghatározására szolgál. A HTML összevegyíti a tartalmat a formázással, mert az információ megjelenítésével törődik. A webalkalmazások általánosabbá válásával azonban növekszik az igény a strukturált tartalomnak a formázástól való elválasztására. Például képzeljünk el egy programot, ami valamilyen könyv legjobb árát keresi a weben. Ennek számos weboldalt kell elemeznie a tétel címe és ára után kutatva. HTML-ben leírt weboldalak esetén a programnak nagyon nehéz kitalálnia, hogy hol van a cím és hol van az ár.

Ezért a W3C kifejlesztette az XML-t [Bray és mások, 2006], hogy lehetővé tegyék a webes tartalom strukturálását az automatizált feldolgozás érdekében. A HTML-lel ellentétben, az XML-ben nincsenek definiált címkék. Minden felhasználó meghatározhatja a saját egyéni címkéit. Az XML-dokumentumnak egy egyszerű példája látható a 7.34. ábrán. Ez egy „könyvlista” nevű szerkezetet határoz meg, ami történetesen könyvek listája. Minden könyvnek három mezője van: a cím, a szerző és a kiadás éve. Rendkívül egyszerű módon, ezeknek a struktúráknak lehetnek ismétlődő mezőik (például több szerző), opcionális mezőik (például egy CD-ROM-melléklet) és alternatív mezőik (például egy könyvesbolt URL-je, ha a könyv még üzletben kapható, vagy egy aukciós hely URL-je, ha már üzletben nem kapható).

7.34. ábra - Egy egyszerű XML-dokumentum

Példánkban mindhárom mező oszthatatlan entitás, de egyébként a mezők további részekre való osztása is megengedett. Például, a még aprólékosabb keresések és formázások érdekében a szerző mezőt a következőképp is megadhattuk volna:

<szerzo>

<keresztnev> George </keresztnev>

<vezeteknev> Zipf </vezeteknev>

</szerzo>

Minden mezőt almezőkre, majd al-almezőkre stb. oszthatunk, tetszőleges mélységig.

A 7.34. ábrán látható állomány mindössze egy három könyvből álló listát ad meg. Ez kiválóan alkalmas a böngészőben és a kiszolgálón futó programok közötti információtovábbításra, de semmit nem árul el arról, hogy a dokumentumot mint weboldalt hogyan kell megjeleníteni. Ennek érdekében a program, amely feldolgozza az információt és 1949-et a könyvek szempontjából nagyszerű évnek ítéli, egy olyan HTML-t állíthat elő, melyben a címek dőlt betűs szövegként jelennek meg. Egy másik lehetőség az, hogy az XSLT (eXtensible Stylesheet Language Transformations – kiterjeszthető stíluslapnyelv-átalakítások) nyelvet használjuk annak meghatározására, hogy az XML-t miként kell HTML-lé transzformálni. Az XSLT hasonlít a CSS-re, de sokkal hatékonyabb annál. A részletektől az olvasót megkíméljük.

Egy másik előnye az adatok HTML helyett XML-ben történő kifejezésének az, hogy ezt a programok könnyebben tudják elemezni. A HTML-t eredetileg kézzel írták (gyakran még ma is), ezért sok közülük egy kicsit hanyag. A zárócímkéket (például a </p>-t) gyakran kifelejtik. Más címkéknek, mint a <br>, nincsen megfelelő zárócímkéje. Ismét más címkéket nem megfelelően ágyaznak egymásba, valamint a címkéket és attribútumokat felváltva hol kis-, hol nagybetűkkel írják. A legtöbb böngésző minden tőle telhetőt elkövet az eredeti szándék megfejtése érdekében. Az XML definíciója szigorúbb és tisztább. A címkék nevei és az attribútumok mindig kisbetűsek, a címkéket a megnyitással ellentétes sorrendben mindig be kell zárni (vagy egyértelműen jelezni kell, ha ez egy megfelelő záróelem nélküli üres címke), továbbá az attribútumok értékét idézőjelek között kell feltüntetni. Ez a pontosság az elemzést könnyebbé és félreérthetetlenné teszi.

A HTML-t még az XML kifejezéseivel is meghatározták. Ezt a megközelítést XHTML-nek (eXtended Hypertext Markup Language – kiterjesztett hipertextjelölő nyelv) nevezik. Ez alapvetően a HTML-nek egy „nagyon válogatós” változata. Az XHTML-oldalaknak szigorúan be kell tartaniuk az XML szabályait, máskülönben a böngésző nem fogadja el azokat. Nincs több silány weboldal és böngészők közti következetlenség! Akár az XML esetében, itt is az a szándék, hogy a programokkal (ebben az esetben webalkalmazásokkal) történő feldolgozás számára jobb oldalak készüljenek. Bár az XHTML 1998 körül született meg, csak lassan zárkózik fel. A HTML-t készítő emberek nem értik, miért van szükségük az XHTML-re, és a böngésző támogatás is késlekedett. A HTML 5.0 meghatározása éppen most van folyamatban, ezért egy weboldal akár HTML-formában, akár XHTML-formában leírható az átmenet megkönnyítése érdekében. Végső soron az XHTML-nek le kellene váltania a HTML-t, de még hosszú idő fog eltelni, míg ez az átmenet végbemegy.

Az XML népszerűnek bizonyult a programok közötti kommunikáció nyelveként is. Amikor ezt a kommunikációt a (következő szakaszban ismertetett) HTTP-protokollal valósítják meg, akkor webszolgáltatásról (web service) beszélünk. Konkrétan a SOAP (Simple Object Access Protocol – egyszerű objektumhozzáférési protokoll) a webszolgáltatások megvalósításának egy olyan módja, amely programok között távoli eljáráshívásokat (RPC) hajt végre nyelv- és rendszerfüggetlen módon. Az ügyfél csak összeállítja a kérést egy XML-üzenet formájában, és a HTTP-protokoll segítségével elküldi a kiszolgálónak. A kiszolgáló a választ szintén XML-üzenetként küldi vissza. Ily módon a különböző platformokon lévő alkalmazások is kommunikálhatnak egymással.

Visszatérve az AJAX-hoz, a lényeg számunkra egyszerűen csak az, hogy az XML egy hasznos formátum az adatoknak a böngészőben és a kiszolgálón futó programok közötti kicseréléséhez. Annak érdekében azonban, hogy a böngésző felhasználói felülete az adatok küldése és fogadása közben könnyen kezelhető maradhasson, a szkripteknek képesnek kell lenniük olyan aszinkron I/O (asynchronous I/O – aszinkron bevitel/kivitel) végrehajtására, amely nem blokkolja a kijelzőt addig, amíg a kérésre adott válasz meg nem érkezik. Például képzeljünk el egy térképet, ami görgethető a böngészőben! Amikor a szkript értesítést kap a görgetési műveletről, a térkép oldalán lévő szkript további térképadatokat igényelhet a szervertől, ha a térkép megjelenített része közel jár az adatok széléhez. A felhasználói felületnek nem szabad lefagynia ezeknek az adatoknak a letöltése alatt. Egy ilyen felhasználói felület nem nyerne felhasználói díjat. A görgetésnek folyamatosan kell folytatódnia. Amikor az adatok megérkeznek, a szkriptet értesítik, hogy felhasználhatja az adatokat. Ha minden jól megy, az új térképadatok hamarabb megérkeznek, mint szükség lenne rájuk. A korszerű böngészők támogatják a kommunikációnak ezt a modelljét.

A kirakó utolsó darabja egy szkriptnyelv, ami összetartja az AJAX-ot azáltal, hogy hozzáférést biztosít a fent felsorolt technikákhoz. A legtöbb esetben ez a nyelv a JavaScript, de vannak alternatívák, mint például a VBScript. Korábban bemutattunk egy egyszerű JavaScript-példát. Ne tévesszen meg senkit ez az egyszerűség! A JavaScript-nek sok fura megoldása van, de ez egy teljes értékű programozási nyelv, a C vagy Java minden erősségével. Vannak változói, karakterláncai, tömbjei, objektumai, függvényei és a szokásos vezérlési szerkezetei. Ezenkívül különleges felhasználói felületekkel rendelkezik a böngészőhöz és a weblapokhoz. A JavaScript képes követni az egér mozgását a képernyőn lévő objektumok felett, ami megkönnyíti a hirtelen előbukkanó menük elkészítését és eleven weboldalakhoz vezet. A weboldalak eléréséhez tudja a DOM-ot használni, tudja a HTML-t és az XML-t manipulálni, és képes aszinkron HTTP-kommunikációt végrehajtani.

Mielőtt befejeznénk a dinamikus oldalak témakörét, röviden összegezzük az eddig érintett technikákat úgy, hogy hivatkozunk rájuk egy ábrán! Teljes weboldalakat is elő lehet állítani menet közben különféle szkriptekkel a kiszolgáló oldalán. A szkriptek megírhatók olyan kiszolgálót kiterjesztő nyelveken, mint a PHP, JSP vagy az ASP.NET, vagy futhat különálló CGI-folyamatokként, és így bármilyen nyelven megírhatók. Ezek a lehetőségek láthatók a 7.35. ábrán.

7.35. ábra - Különböző, dinamikus oldalak előállítására szolgáló technikák

Miután a böngésző megkapta ezeket a weboldalakat, úgy bánik velük, mint a közönséges HTML-ben, CSS-ben és más MIME-típusokkal megírt oldalakkal, csak megjeleníti azokat. Böngészőben futó beépülő modulok és böngészőn kívül futó segédalkalmazások telepíthetők a böngésző által támogatott MIME-típusok kiterjesztése érdekében.

A dinamikus tartalmat az ügyfél oldalán is elő lehet állítani. A weboldalakba ágyazott programok megírhatóak JavaScript-ben, VBScript-ben, Java-ban és más nyelveken. Ezek a programok tetszőleges számításokat végezhetnek, és frissíthetik a kijelzőt. A weboldalakban lévő programok az AJAX segítségével aszinkron módon cserélhetnek XML és más típusú adatokat a szerverrel. Ez a modell támogatja a legkülönfélébb webalkalmazásokat, amelyek éppen úgy néznek ki, mint a hagyományos alkalmazások, eltekintve attól, hogy a böngésző belsejében futnak, és hozzáférnek az interneten lévő kiszolgálók által tárolt információhoz.

A böngészők általában úgy veszik fel a kapcsolatot a kiszolgálókkal, hogy egy TCP-összeköttetést építenek ki a kiszolgáló gépének 80-as portjával, bár a szabvány ezt formálisan nem követeli meg. A TCP használatának előnye az, hogy sem a böngészőnek, sem a kiszolgálónak nem kell aggódnia a hosszú üzenetek kezelésének módja, a megbízhatóság és a torlódásvezérlés miatt. Az összes ilyen kérdésről a TCP-implementáció gondoskodik.

A világháló korai szakaszában, a HTTP 1.0-ban az összeköttetés kiépítése után egyetlen kérést küldtek el, amire egyetlen válasz érkezett. Ezután a TCP-összeköttetést lebontották. Abban a világban, amikor egy tipikus weboldal még kizárólag szövegből állt, ez még helyénvaló is volt. Az átlagos weboldalak mérete gyorsan növekedett, kezdett már nagyon sok beágyazott hivatkozást tartalmazni olyan tartalmakra, mint például az ikonok és egyéb vizuális nyalánkságok. A működést nagyon költségessé tette, hogy minden egyes ikon átviteléhez külön TCP-összeköttetést kellett kiépíteni.

Ez a megfigyelés vezetett a HTTP 1.1-hez, ami már támogatja a tartós kapcsolatokat (persistent connections). Ezáltal lehetővé vált, hogy kiépítsünk egy TCP-összeköttetést, elküldjünk egy kérést, megkapjuk a választ, majd pedig további kéréseket küldjünk és válaszokat kapjunk. Ezt a stratégiát a kapcsolat újrahasználásának (connection reuse) is nevezik. Azáltal, hogy több kérés között oszlik meg a TCP-kiépítés, indítás és lebontás költsége, az egyes kérésekre jutó, a TCP által okozott relatív többletterhelés kisebb lesz. A kéréseket akár csővezeték (pipeline) módszerrel is lehet küldeni, azaz már azelőtt el lehet küldeni a 2-es kérést, hogy az 1-es kérésre megérkezett volna a válasz.

E három eset közötti teljesítménybeli különbséget mutatja a 7.36. ábra. Az (a) rész három kérést mutat, az egyik követi a másikat, mindegyik külön összeköttetést használ. Tegyük fel, hogy ez egy weboldalt ábrázol, amin két beágyazott kép található, amelyek ugyanazon a kiszolgálón helyezkednek el. A képek URL-jeinek meghatározása a főoldal lekérése után történik, ezért azokat a főoldal után töltik le. Manapság egy átlagos oldalnak körülbelül 40 további objektuma van, amit le kell kérni a megjelenítéshez, de ez túlságosan megnövelné az ábránkat, ezért csak két beágyazott objektumot fogunk használni.

7.36. ábra - HTTP (a) több összeköttetéssel és egymást követő kérésekkel. (b) Tartós kapcsolat és egymást követő kérések. (c) Tartós kapcsolat és csővezeték módszerrel küldött kérések

A 7.36.(b) ábrán az oldalt tartós kapcsolattal kérik le. Ez azt jelenti, hogy kezdetben TCP-összeköttetés létesül, aztán elküldésre kerül ugyanaz a korábbi három kéréssorban egymás után, és majd csak ezután bomlik le az összeköttetés. Figyeljük meg, hogy a lekérés sokkal gyorsabban végbemegy! A gyorsulásnak két oka van. Először is, nem veszett el idő a további összeköttetések kiépítésével, ugyanis minden egyes TCP-összeköttetés létrehozásához legalább egy körbefordulási időre van szükség. Másodszor, ugyananannak a két képnek a továbbítása gyorsabban megtörténik. Miért? Ennek a TCP torlódáskezelése az oka. Az összeköttetés kezdetén a TCP a lassú indítási eljárást használja az átvitel növelése érdekében, amíg megtanulja a hálózati utak viselkedését. Ennek a bemelegedési időszaknak az a következménye, hogy több rövid TCP-összeköttetésnek aránytalanul hosszabb ideig tart az információátvitel, mint egy hosszabb TCP-összeköttetésnek.

Végül, a 7.36.(c) ábrán egyetlen tartós kapcsolat és csővezeték módszerrel küldött kérések láthatóak. A második és harmadik lekérés különösen gyorsan követi egymást, amint a főoldalnak elegendően nagy része megérkezett ahhoz, hogy meg lehessen állapítani a képek lekérésének szükségességét. Végül ezekre a kérésekre adott válaszok következnek. Ez a módszer lerövidíti a kiszolgáló tétlenül eltöltött idejét, és így tovább fokozza a teljesítőképességet.

A tartós összeköttetések azonban nincsenek ingyen. Ezek használata kapcsán egy új kérdés merül fel: mikor kell lezárni az összeköttetést? Egy kiszolgálóval létrehozott összeköttetésnek megnyitva kell maradnia az oldal töltése közben. És azután? Jó esély van rá, hogy a felhasználó rá fog kattintani egy hivatkozásra, ami új oldalt kér a kiszolgálótól. Ha az összeköttetés megnyitva marad, a következő kérés azonnal elküldhető. Arra azonban nincs garancia, hogy az ügyfél valamikor nemsokára egy másik kérést intéz a kiszolgálóhoz. A gyakorlatban az ügyfelek és a kiszolgálók általában addig tartják megnyitva a tartós kapcsolatokat, amíg egy rövid időt (például 60 másodpercet) tétlenül nem töltenek, vagy amíg a nyitott kapcsolatok száma túl nagy nem lesz, amikor is be kell zárni néhányat.

A figyelmes olvasó észrevehette, hogy egy kombinációt eddig kihagytunk. Lehetséges TCP-összeköttetésenként egy-egy kérés elküldése is, de egyidejűleg több TCP-összeköttetés párhuzamos használatával. Ezt a párhuzamos összeköttetési (parallel connection) módszert széles körben alkalmazták a böngészők a tartós kapcsolatok előtt. Ugyanazokkal a hátrányokkal bír, mint az egymást követő összeköttetések – magasabb költségek – de annál sokkal jobb a teljesítőképessége. Ennek az az oka, hogy az összeköttetések egyidejű elindítása és felfutása a késleltetési idő egy részét elrejti. Példánkban mindkét beágyazott képhez tartozó összeköttetés egyidejűleg elindulhat. Ugyanazzal a kiszolgálóval azonban nem javasolt túl sok összeköttetést használni. Ennek oka az, hogy a TCP minden egyes összeköttetésnél külön torlódáskezelést végez. Ennek következtében az összeköttetések egymással versengenek, ami csomagvesztést okoz, és összességében a hálózatot sokkal aggresszívebben használják, mint egy egyedi összeköttetés. A tartós kapcsolatok jobbak, és használatukat előnyben részesítik a párhuzamos összeköttetésekkel szemben, mert kivédik az állandó költségeket és nem szenvednek a torlódási problémáktól.

Metódusok

Bár a HTTP-t a weben való használatra tervezték, szándékosan a szükségesnél általánosabbra készítették, szem előtt tartva az eljövendő objektumorientált alkalmazásokat. A protokoll ebből kifolyólag olyan műveleteket, más néven metódusokat (methods) is támogat, melyek nem pusztán egy weboldal elkérésére irányulnak. Ez az általánosság tette lehetővé a SOAP létrejöttét is.

Minden kérés egy- vagy többsornyi ASCII-szövegből áll, ahol az első sor első szava a kért metódus neve. A beépített metódusokat a 7.37. ábra sorolja fel. A nevek érzékenyek a kisbetű/nagybetű különbségre, így a GET egy legális eljárás, de a get nem az.

7.37. ábra - A beépített HTTP-kérés-metódusok

A GET metódus arra kéri a kiszolgálót, hogy küldje el az oldalt. (Amikor „oldalról” beszélünk, akkor ez alatt a legáltalánosabb esetben „objektumot” értünk, de a fogalmak megértéséhez elegendő, ha az oldalra úgy gondolunk, mint egy állomány tartalmára.) Az oldal megfelelő módon MIME-ben van kódolva. A webszerverekhez intézett kérések túlnyomó többsége GET. A GET szokásos alakja:

GET állománynév HTTP/1.1

ahol az állománynév a letöltendő oldal neve, és 1.1 a használt protokoll verziója.

A HEAD metódus csak az üzenet fejlécét kéri, a tényleges oldal nélkül. Ez a metódus használható arra, hogy információt gyűjtsünk indexelési célokra, vagy egyszerűen ellenőrizzük egy URL érvényességét.

A POST metódust használják űrlapok elküldésére. Ezt és a GET-et is használják a SOAP-webszolgáltatásokhoz. A GET-hez hasonlóan ez is egy URL-t hordoz, de ahelyett, hogy egyszerűen lehozna egy oldalt, adatokat tölt fel a kiszolgálóra (például az űrlap tartalmát vagy távoli eljáráshívás paramétereit). A szerver ezután az URL-től függően elvégez valamit az adatokkal, elméletileg hozzáfűzi az adatokat az objektumhoz. A hatás lehet például egy cikk megvásárlása, vagy egy távoli eljárás meghívása. Végül az eljárás visszatér az eredményt jelző oldallal.

A többi metódust nem nagyon használják a web böngészésére. A PUT metódus a GET fordítottja: az oldal olvasása helyett írja azt. Ez a metódus teszi lehetővé weboldalak gyűjteményének felépítését a távoli kiszolgálókon. A kérés törzse tartalmazza az oldalt. Ez lehet MIME szerint kódolt; ebben az esetben a PUT-ot követő sorok tartalmazhatják a hitelesítési fejléceket annak bizonyítására, hogy a hívónak valóban van engedélye a kívánt feladat végrehajtására.

A PUT-hoz némileg hasonló a POST metódus. Ez is egy URL-t hordoz, de a meglevő adat felülírása helyett az új adatot „hozzáadja” ahhoz valamilyen általános értelemben. Az ilyen értelmű hozzáadásra lehet példa egy üzenet postázása egy hírcsoportba, vagy egy állomány hozzáadása egy hirdetőtábla-rendszerhez. A gyakorlatban sem a PUT-ot, sem a POST-ot nem nagyon használják.

A DELETE azt teszi, amit várunk: törli az oldalt, vagy legalább is jelzi, hogy a webszerver elfogadta az oldal törlését. Akárcsak a PUT-nál, itt is nagy szerepet játszik a hitelesítés és az engedélyezés.

A TRACE metódus a hibakeresést szolgálja. Arra utasítja a kiszolgálót, hogy küldje vissza a kérést. Ez akkor hasznos, amikor a kéréseket nem a megfelelő módon dolgozzák fel, és az ügyfél tudni akarja, hogy ténylegesen milyen kérést kapott meg a kiszolgáló.

A CONNECT metódus segítségével a felhasználó számára lehetővé válik egy webszerverhez közbeeső egységen, mint például egy webes gyorstáron keresztül történő csatlakozás.

Az OPTIONS metódus lehetővé teszi, hogy az ügyfél lekérdezzen egy oldalt, valamint megkapja az oldallal használható metódusokat és fejléceket.

Minden kérésre érkezik egy válasz, ami egy állapotsorból, és esetleg további információból (például egy weboldal része vagy egésze) áll. Az állapotsor tartalmazza a háromjegyű állapotkódot, ami megmondja, hogy a kérést teljesítették-e, és ha nem, miért nem. Az első számjegy öt nagy csoportra osztja a válaszokat, ahogy azt a 7.38. ábra mutatja. Az 1xx kódokat ritkán használják a gyakorlatban. A 2xx kódok azt jelentik, hogy a kérést sikeresen kezelték, és érkezik is vissza a tartalom (ha van). A 3xx kódok arra utalnak, hogy az ügyfélnek máshol kell keresgélnie vagy egy másik URL-lel vagy a saját gyorstárjában (ezt később tárgyaljuk). A 4xx kódok azt jelentik, hogy a kérést az ügyfél hibája miatt nem lehet teljesíteni, mert például érvénytelen a kérés, vagy nem létezik az oldal. Végül, az 5xx kódok azt jelzik, hogy magának a kiszolgálónak van valamilyen belső gondja vagy egy szoftverhiba, vagy az ideiglenes túlterhelés miatt.

7.38. ábra - A válasz állapotkódjának csoportjai

A kérés sora (például a GET metódust tartalmazó sor) után további információt tartalmazó sorok következhetnek. Ezeket a kérésfejlécének (request headers) nevezzük. Az ilyen információ az eljáráshívások paramétereihez hasonlatos. A válaszoknak szintén lehetnek válaszfejlécei (response headers). Egyes fejléceket akár mindkét irányban is lehet használni. A legfontosabb fejléceket a 7.39. ábra mutatja be. Ez a lista nem rövid, ezért ahogyan azt feltehetőleg az olvasó is gondolja, minden egyes kérés- és válaszfejlécnek gyakran több változata létezik.

7.39. ábra - Néhány HTTP-üzenetfejléc

A Felhasználói-ügynök (User-Agent) fejléc lehetővé teszi, hogy az ügyfél közölje a kiszolgálóval böngészőjének típusát (például Mozilla/5.0 és Chrome/5.0.375.125). Ez az információ azért hasznos, mert lehetővé teszi, hogy a kiszolgálók a célnak megfelelően alakítsák a böngészőknek szánt válaszaikat, mivel a különféle böngészők erősen eltérő képességekkel rendelkezhetnek, és másképp viselkedhetnek.

A négy Elfogadható (Accept) fejléc azt mondja meg a kiszolgálónak, hogy az ügyfél mit hajlandó elfogadni, amennyiben csak egy korlátozott választék elfogadására van módja. Az első típus azt adja meg, hogy az ügyfél milyen MIME-típusokat lát szívesen (például text/html). A második megadja a karakterkészletet (például ISO-8859-5 vagy Unicode-1-1). A harmadik a tömörítő eljárásokkal foglalkozik (például gzip). A negyedik egy természetes nyelvet jelöl (például spanyol). Ha a kiszolgáló több oldal közül is választhat, akkor ezen információ felhasználásával azt adhatja vissza, amit az ügyfél keres. Ha nem képes teljesíteni a kérést, akkor egy hibakóddal tér vissza, és a kérés meghiúsul.

A Ha-változott-azóta (If-Modified-Since) és a Ha-egyik-sem-egyezik (If-None-Match) fejléceket a gyorstárakkal kapcsolatban használják. Lehetővé teszik az ügyfél számára, hogy csak akkor kérje egy oldal küldését, ha annak gyorstárban lévő másolati példánya már nem érvényes. A gyorstárazást hamarosan bemutatjuk.

A Hoszt (Host) fejléc a kiszolgálót nevezi meg; ezt az URL-ből veszik ki. Ez a fejléc kötelező. Azért használják, mert némely IP-címhez több DNS-név is tartozik, és a kiszolgálónak valahogy el kell döntenie, hogy melyik hosztnak adja tovább a kérést.

A Hitelesítés (Authorization) fejlécre a védett oldalak esetén van szükség. Ekkor az ügyfélnek esetleg bizonyítania kell, hogy jogosult megnézni az oldalt – erre szolgál ez a fejléc.

Az ügyfél a Hivatkozó (a hibásan írt Referer) fejlécet használja arra, hogy megadja azt az URL-t, amelyik a most kért URL-re hivatkozott. Leggyakrabban ez az előző oldal URL-je. Ez a fejléc különösen fontos a webböngészés nyomon követéséhez, mert megmondja a kiszolgálóknak, hogy a kliens hogyan jutott az oldalra.

Bár a sütikkel nem az RFC 2616, hanem az RFC 2109 foglalkozik, ezeknek is vannak fejléceik. A kiszolgálók a Süti-beállítás (Set-Cookie) sütifejléc útján küldik el sütijeiket az ügyfeleknek. Az ügyfélnek el kell mentenie a sütit, és az ezt követő kérésekben a Süti (Cookie) fejlécet használva vissza kell küldenie a kiszolgálónak. (Jegyezze meg, hogy létezik egy sokkal frissebb sütikre vonatkozó előírás új fejlécekkel, az RFC 2965, de ezt az ipar nagymértékben visszautasította és nem valósították meg széles körben.)

Számos más fejlécet is használnak a válaszokban. A Kiszolgáló (Server) lehetővé teszi a kiszolgáló számára, hogy felfedje a szoftverének sorszámát, ha akarja. A következő öt, „Tartalom-” (Content) kezdetű fejléc segítségével a kiszolgáló megadhatja az éppen elküldött oldal jellemzőit.

Az Utoljára-módosítva (Last-modified) fejléc megmondja, hogy mikor módosították utoljára az oldalt, a Lejár (Expires) fejléc pedig arról informál, hogy az oldal meddig marad érvényes. Mindkét fejléc fontos szerepet játszik a gyorstárak kezelésében.

A Hely (Location) fejlécet a kiszolgáló arra használja, hogy közölje az ügyféllel: próbálkozzon egy másik URL-lel. Ez akkor hasznos, ha az oldal elköltözött, vagy ha több URL is mutat ugyanarra az oldalra (esetleg különböző kiszolgálókon). Használják még azok a vállalatok is, melyeknek van egy központi weboldaluk a com körzetben, de onnan az ügyfeleket átirányítják a nemzeti vagy regionális oldalra az IP-címük vagy a preferált nyelvük alapján.

Ha egy oldal nagyon nagy méretű, akkor egy kisebb ügyfél esetleg nem akarja megkapni egyszerre az egészet. Egyes kiszolgálók bájttartományokra vonatkozó kéréseket is elfogadnak, így az oldalt több kisebb egységben is le lehet tölteni. Az Elfogadható-tartományok (Accept-Ranges) fejléc azt jelenti be, hogy a kiszolgáló hajlandó ilyen jellegű részleges kéréseket kezelni.

Ezzel elérkeztünk azokhoz a fejlécekhez, melyek mindkét irányban használhatók. A Dátum (Date) fejléc mindkét irányban használható, és az üzenet elküldésének dátumát és időpontját tartalmazza, míg a Tartomány (Range) fejléc megadja az oldalnak a válasz által szolgáltatott bájttartományát.

Az ECímke (ETag) fejléc egy rövid címkét ad meg, ami az oldal tartalmának neveként szolgál. Ezt a gyorstárazáshoz használják. A Gyorstár-vezérlés (Cache-Control) fejléc további explicit utasításokat ad az oldalak gyorstárazására (vagy még gyakrabban, a gyorstárazás mellőzésére) vonatkozóan.

Végül az Átállás (Upgrade) egy új kommunikációs protokollra, mint például egy jövőbeli HTTP-protokollra vagy biztonságos átvitelre történő átkapcsolásra szolgál. Ez lehetővé teszi, hogy az ügyfél bejelentse, mit képes kezelni, és hogy a kiszolgáló is megmondja, mi az, amit éppen használ.

Az emberek gyakran visszatérnek az általuk korábban megtekintett weboldalakra, és a kapcsolódó weboldalaknak gyakran ugyanazok a beágyazott erőforrásaik. Néhány példa: azok a képek, amelyeket a webhely oldalai közti navigáláshoz használnak, valamint a közös stíluslapok és szkriptek. Nagyon pazarló lenne minden egyes megjelenítés előtt az ezekhez az oldalakhoz tartozó összes ilyen erőforrást lekérni, mert a böngészőnek már van egy másolati példánya.

Az oldalak későbbi felhasználás céljából történő tárolását gyorstárazásnak (caching) nevezzük. Ennek az az előnye, hogy amikor a gyorstárban lévő oldalt ismét felhasználják, nem kell megismételni az átvitelt. A HTTP beépített támogatással rendelkezik, hogy segítsen az ügyfeleknek azonosítani, mikor lehet biztonságosan újrahasználni az oldalakat. Ez a támogatás azáltal növeli meg a teljesítőképességet, hogy csökkenti a hálózati forgalmat és a késleltetést. A kompromisszum az, hogy a böngészőnek most már tárolnia kell az oldalakat, de ezt a kompromisszumot csaknem mindig érdemes megkötni, mert a helyi tárolás nem költséges. Az oldalakat általában lemezen tárolják, így újra felhasználhatók a böngésző későbbi futása alkalmával.

A nehéz ügy a HTTP gyorstárazásával kapcsolatban annak megállapítása, hogy egy oldalnak a korábban gyorstárba helyzetett másolati példánya ugyanolyan-e, mint az eredeti oldal lenne, ha azt újra lekérnék. Ezt a döntést nem lehet kizárólag az URL alapján meghozni. Például az URL megadhat egy olyan oldalt, ami megjeleníti a legfrissebb híreket. Ennek az oldalnak a tartalma sűrűn fog frissülni annak ellenére, hogy az URL ugyanaz marad. Vagy az oldal tartalma a görög és a római mitológia isteneinek listája is lehet. Ennek az oldalnak valamelyest kevésbé gyorsan kellene megváltoznia.

A HTTP két stratégiát használ ennek a problémának a megoldására. Ezek, mint a feldolgozás módjai láthatók a 7.40. ábrán, a kérés (1. lépés) és a válasz (5. lépés) között. Az első stratégia az oldal érvényesítése (2. lépés). A gyorstárhoz fordulnak, és ha az rendelkezik a kért URL-hez tartozó oldal olyan másolati példányával, amiről tudni lehet, hogy az friss (azaz még mindig érvényes), akkor nem szükséges azt újból lekérni a kiszolgálótól. Ehelyett közvetlenül visszaadható a gyorstárban tárolt oldal. Amikor a gyorstárban lévő oldalt eredetileg lekérték, visszaérkezett vele a Lejár fejléc, amelyben lévő aktuális dátum és időpont használható ennek a döntésnek a meghozatalához.

7.40. ábra - HTTP-gyorstárazás

Nem minden oldal érkezik azonban megfelelő Lejár fejrésszel, ami megadja, mikor kell az oldalt újból lekérni. Végül is, jósolni nehéz – különösen a jövőre nézve. Ebben az esetben a böngésző valamilyen heurisztikát használhat. Például, ha az oldalt nem változtatták meg az elmúlt évben (ahogyan azt az Utoljára-módosítva fejléc állítja), akkor elég biztonságosan lehet fogadni arra, hogy nem fog megváltozni a következő órában. Garancia azonban nincsen rá, és ez egy rossz fogadás is lehet. Például lehet, hogy az értéktőzsde mára bezárt, és így az oldal órákig nem fog megváltozni, de gyorsan fog változni, amikor majd elkezdődik a következő kereskedési időszak. Ennél fogva egy oldal gyorstárban való tárolhatósága idővel erősen változhat. Emiatt a heurisztikát óvatosan kell használni, noha a gyakorlatban gyakran jól működik.

A még le nem járt oldalak megtalálása a legkedvezőbb eset a gyorstár használata során, mert ez azt jelenti, hogy a kiszolgálóval egyáltalán nem kell kapcsolatba lépni. Sajnos ez nem mindig sikerül. A kiszolgálóknak a Lejár fejlécet óvatosan kell használniuk, mert nem lehetnek biztosak abban, hogy mikor fogják frissíteni az oldalt. Tehát lehet, hogy a gyorstárban lévő másolati példányok még mindig frissek, de az ügyfél ezt nem tudja.

Ebben az esetben a második stratégiát használják. Ez abból áll, hogy megkérdezik a kiszolgálót, vajon a gyorstárban lévő másolati példány még mindig érvényes-e? Ez a kérés a feltételes GET (conditional GET), és a 7.40. ábra 3. lépésében látható. Ha a szerver tudja, hogy a gyorstárban lévő másolat még mindig érvényes, akkor ezt megmondhatja egy rövid válaszban (4a lépés). Máskülönben el kell küldenie a teljes választ (4b lépés).

Több fejlécmezőt használnak arra, hogy lehetővé tegyék a kiszolgáló számára annak ellenőrzését, hogy a gyorstárban lévő másolat még mindig érvényes-e. Az ügyfél tudja a gyorstárban lévő oldal utolsó frissítésének idejét az Utoljára-módosítva fejlécből. Ezt az időt elküldheti a szervernek a Ha-változott-azóta fejléc segítségével, hogy az oldalt csak akkor kérje le, ha az időközben megváltozott.

Másik lehetőségként a kiszolgáló az oldallal együtt visszaküldhet egy ECímke fejlécet. Ez a fejléc egy címkét ad meg, ami az oldal tartalmának rövid neve. Ez hasonló, mint egy ellenőrző összeg, de jobb annál. (Ez egy kriptográfiai hash-érték lehet, melyet a 8. fejezetben ismertetünk.) Az ügyfél a gyorstárban lévő másolatokat a kiszolgálónak küldött Ha-egyik-sem-egyezik fejrésszel érvényesítheti, amely a gyorstárban lévő másolatok címkéit sorolja fel. Ha a címkék közül bármelyik megfelel annak a tartalomnak, amellyel a kiszolgáló válaszolna, a megfelelő gyorstárbeli másolat felhasználható. Ez a módszer akkor használható, amikor a frissesség megállapítása nem kényelmes vagy nem hasznos. Például egy kiszolgáló ugyanarra az URL-re különböző tartalmakat adhat vissza attól függően, hogy melyek az előnyben részesített nyelvek vagy MIME-típusok. Ebben az esetben önmagában a módosítás dátuma nem fog segíteni a kiszolgálónak meghatározni, hogy a gyorstárban lévő oldal friss-e.

Végül jegyezzük meg, hogy mindkét gyorstárazási stratégiát hatástalanítják a Gyorstár-vezérlés fejlécben szállított direktívák. Ezek a direktívák korlátozhatják (például no-cache) a gyorstárazást, amikor az nem alkalmazható. Ilyen például egy dinamikus oldal, ami a következő lekérés alkalmával eltérő lesz. A hitelesítést igénylő oldalakat sem tartják a gyorstárban.

A gyorstárazás sokkal összetettebb ennél, de már csak két fontos pontnak van helyünk. Először is, a gyorstárazást a böngészőn kívül, más helyeken is elvégezhetik. Általános esetben a HTTP-kérések útvonala keresztülmehet egy sor gyorstáron. A böngészőn kívüli gyorstárak használatát helyettes gyorstárazásnak (proxy caching) nevezzük. A gyorstárazásnak minden egyes újabb szintje segíthet a lánc további részeire eljutó kérések számának csökkentésében. Az olyan szervezeteknél, mint amilyenek az internetszolgáltatók (ISP-k) vagy a vállalatok, megszokott a helyettes gyorstárazás használata, hogy kiaknázzák az oldalak különböző felhasználók közti gyorstárazásából származó előnyöket. A helyettes gyorstárazást a tartalomelosztás szélesebb témakörén belül fogjuk megtárgyalni a 7.5 szakaszban, ennek a fejezetnek a végén.

Másodszor, a gyorstárazások jelentősen növelhetik a teljesítőképességet, de nem annyira, mint azt egyesek remélik. Ennek az az oka, hogy míg vannak nyilvánvalóan népszerű dokumentumok a világhálón, nagyon sok olyan népszerűtlen dokumentum is van, amit lekérnek az emberek, és ezek között sok még ráadásul nagyon hosszú is (például videók). A népszerűtlen dokumentumok „hosszú farka” elfoglalja a helyet a gyorstárban, és a gyorstárból kiszolgálható kérések száma csak lassan növekszik a gyorstár méretével. A webes gyorstárak mindig valószínűleg a kéréseknek csak kevesebb, mint felét képesek lekezelni. További információért lásd Breslau és mások [1999] munkáját.

Mivel a HTTP egy ASCII-protokoll, ezért meglehetősen egyszerűen lehet egy terminálról (nem pedig böngészőből) személyesen és közvetlenül a webszerverrel beszélni. Ehhez nem kell más, csak egy TCP-összeköttetés a kiszolgáló 80-as portjával. Javasoljuk, hogy az Olvasó személyesen is kísérletezzen a következő parancssorozattal. A legtöbb UNIX-héjprogramban és Windowson a parancsablakban működni fog (ha a telnet program engedélyezett).

telnet   www.ietf.org#IETF   80

GET   /rfc.html HTTP/1.1

Host:   www.ietf.org#IETF

Ez a parancssorozat egy telnet (azaz TCP-) összeköttetést kezdeményez az IETF webszerverének 80-as portjával a IETF címen. Ezután következik a GET parancs, ami megnevezi az URL útját és a protokollt. Próbáljon ki Ön által választott kiszolgálókat és URL-eket! A következő sor a kötelező Hoszt fejléc. Az utolsó fejlécet követő üres sorra szintén szükség van. Ez mondja meg a kiszolgálónak, hogy nincs több kérésfejléc. A kiszolgáló ezután elküldi a választ. A kiszolgálótól és az URL-től függően számos különféle fejléc és oldal figyelhető meg.