Állapotmentes HTTP és alkalmazási állapot

Célok

A lecke végére el tudod magyarázni, miért nem emlékszik a szerver az előző kérésre, hol élhet az alkalmazás állapota (URL, kliens, szerver), és miért kell azonosító ahhoz, hogy több kérést egy felhasználóhoz kössünk.

Miért baj, hogy a HTTP állapotmentes?

A HTTP-kérés önálló üzenet (2.2): a protokoll nem őrzi meg automatikusan, ki küldte az előző kérést és mit csinált. Az MDN megfogalmazásában nincs kapcsolat két, egymás után, ugyanazon a kapcsolaton végrehajtott kérés között. Ennek előnye, hogy a szerver egyszerű és jól skálázható. A hátránya, hogy a webalkalmazásnak mégis szüksége van folytonosságra: a jelentkezési felületen ugyanannak a hallgatónak több oldalon át kell látnia a választásait, és a rendszernek tudnia kell, hogy ki ő. Ezt az állapotot az alkalmazás kapcsolja az egymástól különálló kérésekhez.

Egy hallgató több kérése

A hallgató megnyitja a kurzuslistát, kiválaszt egy tárgyat, majd a jelentkezési oldalra lép. A szerver három külön HTTP-kérést lát, mindegyiknél külön érkezik a metódus, az URL, a fejlécek és az esetleges törzs. A HTTP önmagában nem kapcsolja őket egyetlen személyhez.

sequenceDiagram
    participant B as Böngésző
    participant S as Szolgáltatás
    B->>S: 1. Kurzuslista kérése
    S-->>B: Válasz
    B->>S: 2. Kurzus részleteinek kérése
    S-->>B: Válasz
    B->>S: 3. Jelentkezés kérése
    S-->>B: Eredmény

Az ábra időbeli sorrendet mutat, nem közös, automatikus HTTP-memóriát. A három kérés összekötéséhez külön mechanizmus kell. Kipróbálva a kipróbáló szerveren: ha a kérés nem hordoz azonosítót, a szerver nem tudja, ki kéri a hallgató jelentkezéseit:

$ curl -i http://localhost:8085/jelentkezesek/anna
HTTP/1.1 401 Unauthorized
{"hiba":"nincs bejelentkezve"}

Mit jelent az állapotmentesség?

A protokoll állapotmentessége azt jelenti, hogy az egyes kérések értelmezéséhez nem jár automatikus, korábbi kérésekből örökölt beszélgetésállapot. Ez nem jelenti azt, hogy a szerver nem tárolhat adatbázist, vagy hogy a weben nem lehet bejelentkezni. Az MDN is megkülönbözteti: a HTTP állapotmentes, de nem „sessionless”: a cookie-k lehetővé teszik az állapotos munkamenetet. A szolgáltatás az üzenetekben hordozott azonosítók és a saját adattárolása révén teremt folytonosságot.

Az 5.3 leckében a REST állapotmentességéről is szó volt: a kérés hordozza az értelmezéséhez szükséges kontextust. Az itt vizsgált kérdés az alkalmazás felhasználói állapota. A kettő összefügg, de egyik sem azt állítja, hogy „sehol nincs állapot”.

Hol élhet az állapot?

Állapot	Természetes hely	Miért?
Kurzuslista szűrője, kiválasztott kurzus	URL	Megosztható, visszakereshető (6.5)
Megnyitott panel, beírt, még el nem küldött szöveg	Kliens memóriája	Rövid életű nézetállapot
Félbehagyott helyi vázlat	Böngészős tárolás (3.6), ha indokolt	Későbbi folytatás
Elfogadott jelentkezés, hozzáférési jog	Szerver	Hivatalos, több felhasználót érintő adat

Nem minden állapotot ugyanoda kell tenni. Az a szabály, hogy ami hivatalos vagy biztonsági jelentőségű, az a szerveren legyen, mert a kliens kódja módosítható (1.4).

Folytonosság és azonosító

Egy szolgáltatás az egymást követő kérésekben szereplő azonosító alapján találja meg a szerveroldalon tárolt állapotot. Az azonosító többféle lehet: cookie-ban küldött munkamenet-azonosító (7.2) vagy az Authorization fejlécben küldött hozzáférési token (7.3). Az azonosító önmagában nem a felhasználó neve, és nem célszerű beleírni a személyes adatokat.

flowchart LR
    K1[1. kérés + azonosító] --> S[Szerver: azonosító alapján megkeresi az állapotot]
    K2[2. kérés + azonosító] --> S
    K3[3. kérés + azonosító] --> S
    S --> A[(Szerveroldali állapot)]

A felület által mutatott állapot és a szerver hivatalos állapota eltérhet. Ha két hallgató egyszerre próbálja elfoglalni az utolsó helyet, a szervernek kell a jelentkezés feldolgozásakor eldöntenie, ki sikeres (2.4: 409). A böngésző korábban látott férőhelyszáma csak pillanatnyi információ.

Végigvezetett példa: a Kurzuspont jelentkezési folyamata

A hallgató három lépésben jelentkezik: kiválaszt egy kurzust, megerősíti, elküldi.

Lépés	Mi hordozza az állapotot?
Kiválasztott kurzus	Az URL (/jelentkezes/webprog): megosztható és frissítés után is megvan.
„Megerősítem” jelölőnégyzet	A kliens memóriája: frissítéskor elveszik, ez elfogadható.
Ki jelentkezik?	A munkamenet-azonosító a kérésben: a szerver ebből tudja, ki a hallgató.
A tényleges jelentkezés	A szerver adatbázisa.

Ha a hallgató eltűnik és később visszatér, a szerver a munkamenet-azonosító alapján (ha még érvényes) felismeri, különben újra be kell lépnie.

Gyakori tévhitek

Állítás	Pontosítás
„Állapotmentes HTTP mellett nem lehet bejelentkezés.”	A cookie, a token és a szerveroldali munkamenet összekötheti a kéréseket.
„A szerver nem tárol adatot, ha a HTTP állapotmentes.”	A protokoll üzenete és az alkalmazás adattárolása külön fogalom.
„A kliens által látott férőhely a végleges igazság.”	A szerver a művelet pillanatában dönt az aktuális állapotról.
„Az azonosító a felhasználó neve.”	Véletlenszerű jelölő, amelyet a szerver visszavezet a felhasználóhoz.

Röviden

• A HTTP állapotmentes: a kérések között nincs automatikus kapcsolat.
• Az alkalmazás azonosítóval és szerveroldali tárolással teremt folytonosságot.
• Az állapot élhet az URL-ben, a kliensben vagy a szerveren; a hivatalos és biztonsági állapot a szerveré.
• A kliens által látott állapot pillanatnyi másolat.

Ellenőrző kérdések

1. Mit jelent az, hogy a HTTP „állapotmentes, de nem sessionless”?
2. Melyik állapotot tennéd az URL-be, a kliens memóriájába és a szerverre egy jelentkezési folyamatban?
3. Miért nem elég a kliensben tárolni, hogy a jelentkezés sikeres?
4. Mire való a munkamenet-azonosító?

Tanulási források

• Overview of HTTP (MDN) — az „állapotmentes, de nem munkamenet nélküli” szakasz, angolul.