031.3 Lecke 1

A kliens és a szerver közötti HTTP-adatcsere első szakaszát a kliens kezdeményezi, amikor kérést küld a szervernek. Vegyünk például egy gyakori böngészőfeladatot: egy HTML-oldal betöltése például a https://learning.lpi.org/en/ oldalnak otthont adó szerverről. A cím, vagyis az URL, több fontos információt is tartalmaz. Ebben a konkrét példában három információ is megjelenik:

Miután a HTTP-szerver megkapta a kérés fejlécét, a szerver válaszüzenetet küld vissza a kliensnek. Egy HTML-kérés jellemzően ilyen válaszfejléccel rendelkezik:

Az első sor a válaszüzenetben használt HTTP-protokoll verzióját adja meg, amelynek meg kell egyeznie a kérés fejlécében használt verzióval. Ezután, szintén az első sorban, a válasz állapotkódja jelenik meg, amely azt jelzi, hogy a kiszolgáló hogyan értelmezte és generálta a kérésre adott választ.

A státuszkód egy háromjegyű szám, ahol a bal szélső számjegy határozza meg a válasz osztályát. Az állapotkódoknak öt osztálya van, 1-5-ig számozva, amelyek mindegyike a kiszolgáló által végrehajtott művelet típusát jelzi:

A második és a harmadik számjegy további részletek feltüntetésére szolgál. A 200-as kód például azt jelzi, hogy a kérés minden probléma nélkül megválaszolható. A példában látható módon a válaszkódot (OK) követő rövid szöveges leírás is megadható. Néhány specifikus kód különösen érdekes annak érdekében, hogy a HTTP-kliens kedvezőtlen helyzetekben is hozzáférhessen az erőforráshoz, vagy hogy sikertelen kérés esetén segítsen azonosítani a hiba okát:

Bár ezek azt jelentik, hogy a kérést nem lehetett teljesíteni, a "4xx" és "5xx" állapotkódok legalább azt jelzik, hogy a HTTP-kiszolgáló fut és képes kéréseket fogadni. A 4xx kódok a kliens részéről igényelnek intézkedést, mivel az URL vagy a hitelesítő adatok helytelenek. Ezzel szemben az 5xx kódok azt jelzik, hogy a szerveroldalon valami nem stimmel. Ezért a webes alkalmazások kontextusában az állapotkódok e két osztálya azt jelzi, hogy a hiba forrása magában az alkalmazásban van, akár kliens, akár szerver, nem pedig a mögöttes infrastruktúrában.

A HTTP-kiszolgálók két alapvető mechanizmust használnak a kliens által kért tartalom teljesítésére. Az első mechanizmus statikus tartalmat biztosít: azaz a kérési üzenetben megadott útvonal megfelel a kiszolgáló helyi fájlrendszerében lévő fájlnak. A második mechanizmus dinamikus tartalmat biztosít: azaz a HTTP-kiszolgáló továbbítja a kérést egy másik programnak - valószínűleg egy szkriptnek -, amely különböző forrásokból, például adatbázisokból és más fájlokból állítja össze a választ.

Bár különböző HTTP-kiszolgálók léteznek, mindegyik ugyanazt a HTTP kommunikációs protokollt használja, és többé-kevésbé ugyanazokat a konvenciókat alkalmazza. Egy olyan alkalmazás, amelynél nem merül fel különleges igény, bármilyen hagyományos szerverrel, például Apache vagy NGINX szerverrel megvalósítható. Mindkettő képes dinamikus tartalom generálására és statikus tartalom szolgáltatására, de enyhe különbségek vannak a konfigurációjukban.

A kiszolgálandó statikus fájlok helyét például az Apache és az NGINX különböző módon határozza meg. A konvenció az, hogy ezeket a fájlokat egy erre a célra létrehozott könyvtárban tartják, amelynek neve a hoszthoz kapcsolódik, például /var/www/learning.lpi.org/. Az Apache-ban ezt az elérési utat a DocumentRoot /var/www/learning.lpi.org konfigurációs utasítás határozza meg a virtuális hosztot definiáló szakaszban. Az NGINX-ben a használt irányelv a root /var/www/learning.lpi.org a konfigurációs fájl server szakaszában.

Bármelyik szervert is választjuk, a /var/www/learning.lpi.org/ fájlokat a HTTP-n keresztül szinte ugyanúgy fogják kiszolgálni. A válaszfejléc néhány mezője és azok tartalma eltérő lehet a két szerver esetén, de az olyan mezőknek, mint a Content-Type, jelen kell lenniük a válaszfejlécben és minden szerveren konzisztensnek kell lenniük.

A HTTP-t úgy tervezték, hogy bármilyen típusú internetkapcsolaton működjön, legyen az gyors vagy lassú. Ezenkívül a legtöbb HTTP-forgalomnak számos hálózati csomóponton kell áthaladnia az internet elosztott felépítése miatt. Ennek eredményeképpen fontos valamilyen tartalmi gyorsítótárazási stratégia alkalmazása, hogy elkerülhető legyen a korábban letöltött tartalom felesleges átvitele. A HTTP-adattovábbítás két alapvető gyorsítótár-típussal működhet: megosztott és privát.

A megosztott gyorsítótárat nem csak egy kliens használja. Egy nagy tartalomszolgáltató például használhat földrajzilag elosztott szervereken lévő gyorsítótárakat, így a kliensek a hozzájuk legközelebbi szerverről kapják meg az adatokat. Ha egy kliens kérést indított, és a válaszát egy megosztott gyorsítótárban tárolták, akkor az ugyanazon a területen ugyanezt a kérést intéző többi kliens is megkapja a gyorsítótárban tárolt választ. A privát gyorsítótárat maga a kliens hozza létre a saját kizárólagos használatára. Ez az a fajta gyorsítótárazási mód, amelyet a webböngésző a képek, CSS-fájlok, JavaScript vagy a HTML-dokumentum esetében végez, így ezeket nem kell újra letölteni, ha a közeljövőben szükség van rájuk.

Mind a megosztott, mind a privát gyorsítótár-stratégia a HTTP fejlécek segítségével szabályozza a letöltött tartalom gyorsítótárazásának módját. A privát gyorsítótár esetében a kliens megnézi a válaszfejlécet, és ellenőrzi, hogy a helyi gyorsítótárban lévő tartalom még mindig megfelel-e az aktuális távoli tartalomnak. Ha igen, a kliens lemond a válasz payloadjának átvételéről, és a helyi verziót használja.

A gyorsítótárazott erőforrás érvényessége többféleképpen is értékelhető. A szerver megadhat egy lejárati dátumot a válaszfejlécben az első kérésnél, így a kliens a lejárati idő végén eldobja a gyorsítótárazott erőforrást, és a frissített változat megszerzéséhez újra lekérdezi azt. A szerver azonban nem mindig tudja meghatározni az erőforrás lejárati dátumát, ezért az erőforrás verziójának azonosítására általában az ETag válaszfejlécmezőt használják, például Etag: "606adcd4-46fa".

Annak ellenőrzéséhez, hogy egy gyorsítótárazott erőforrás frissítésre szorul-e, a kliens csak a válaszfejlécet kéri le a szervertől. Ha az ETag mező megegyezik a helyileg tárolt változatéval, a kliens újra felhasználja a gyorsítótárazott tartalmat. Ellenkező esetben az erőforrás frissített tartalma letöltésre kerül a szerverről.

Egy hagyományos weboldalon vagy webes alkalmazásban a munkamenetvezérlést kezelő funkciók a HTTP-fejléceken alapulnak. A szerver nem feltételezheti például, hogy az azonos IP-címről érkező összes kérés ugyanattól a klienstől származik. A leghagyományosabb módszer, amely lehetővé teszi a szerver számára, hogy a különböző kéréseket egyetlen klienshez rendelje, a cookiek (sütik) használata. A süti egy azonosító címke, amelyet a szerver a HTTP fejlécben ad meg a kliensnek.

A sütik lehetővé teszik a szerver számára, hogy megőrizze az adott kliensre vonatkozó információkat, még akkor is, ha a klienst használó személy nem azonosítja magát kifejezetten. A sütik segítségével olyan munkamenetek valósíthatók meg, amelyekben a bejelentkezések, bevásárlókosarak, preferenciák stb., megmaradnak a különböző kérések között, amelyeket ugyanahhoz a szerverhez intéznek, amely ezeket a kéréseket biztosította. A sütiket a felhasználó böngészésének nyomon követésére is használják, ezért fontos, hogy a küldésük előtt hozzájárulást kérjenek.

A kiszolgáló a "Set-Cookie" mező segítségével állítja be a sütit a válaszfejlécben. A mező értéke egy kulcs=érték pár, amelyet úgy választanak ki, hogy egy adott klienshez kapcsolódó attribútumot képviseljen. A szerver például létrehozhat egy azonosítószámot egy olyan kliens számára, aki először kér egy erőforrást, és ezt a válaszfejlécben átadhatja a kliensnek:

Ha a kliens engedélyezi a sütik használatát, akkor az ugyanahhoz a kiszolgálóhoz érkező új kérelmek fejlécében szerepel a cookie-mező:

Ennek az azonosítószámnak a segítségével a szerver lekérdezheti a kliens speciális definícióit, és testreszabott választ generálhat. Lehetőség van egynél több Set-Cookie mező használatára is, hogy különböző sütiket adjon át ugyanannak a kliensnek. Ily módon egynél több definíció is megőrizhető a kliensoldalon.

A sütik adatvédelmi problémákat és potenciális biztonsági réseket is felvetnek, mivel fennáll annak a lehetősége, hogy átkerülhetnek egy másik klienshez, akit a szerver az eredeti kliensként azonosít. A munkamenetek megőrzésére használt sütik hozzáférést biztosíthatnak az eredeti kliens bizalmas információihoz. Ezért nagyon fontos, hogy a kliensek helyi védelmi mechanizmusokat alkalmazzanak, hogy megakadályozzák a sütik jogosulatlan eltávolítását és újrafelhasználását.