Host: usermap.cvut.cz

Struktura HTTP, stav web aplikace

BI-WI.21-17
  • Obsluha a struktura HTTP požadavku a odpovědi ve webové aplikaci. Stav webové aplikace.

HTTP (HyperText Transfer Protocol)

  • Základním protokol aplikační vrstvy pro přenos hypermediálních dokumentů.
  • Funguje na principu požadavek-odpověď mezi klientem (typicky webový prohlížeč) a serverem.
  • Standardně využívá TCP/IP port 80, zatímco jeho zabezpečená varianta HTTPS využívá port 443.
  • Jedná se o textový protokol (s výjimkou HTTP/2 a novějších, které podporují binární přenos)
  • Fundamentálně bezstavový

../../Attachments/Pasted image 20260620095526.png

Struktura HTTP (Request)

GET /profile/140f269cb240 HTTP/1.1

Accept: text/html
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Řádek požadavku (Request Line)

  • Metoda (Method): Specifikuje akci, která má být provedena se zdrojem (např. GET, POST).
  • URI požadavku (Request URI): Identifikuje zdroj, na který se požadavek vztahuje.
  • Verze HTTP (HTTP Version): Určuje použitou verzi protokolu (např. HTTP/1.1).

Hlavičky (Headers)

  • Poskytují dodatečné informace o požadavku nebo o klientovi. Každá hlavička je dvojice název-hodnota (např. Host: usermap.cvut.cz, Accept: text/html).

Prázdný řádek (CRLF)

  • Odděluje hlavičky od těla požadavku.

Tělo požadavku (Body)

  • Nepovinná část obsahující data odesílaná serveru, typicky u metod POST nebo PUT (např. data z formuláře).

Struktura HTTP (Response)

HTTP/1.1 200 OK
Date: Sun, 5 Jul 2020 16:46:06 GMT
Content-Type: text/html
Content-Length: 39

<html>
<body>Ahoj svete!</body>
</html>

Stavový řádek (Status Line):

  • Verze HTTP (HTTP Version): Verze protokolu použitá serverem.
  • Stavový kód (Status Code): Třímístné číslo indikující výsledek zpracování požadavku (např. 200).
  • Stavová fráze (Reason Phrase): Krátký textový popis stavového kódu (např. OK).

Hlavičky (Headers)

  • Poskytují dodatečné informace o odpovědi nebo o serveru (např. Content-Type: text/html, Content-Length: 39).

Prázdný řádek (CRLF)

  • Odděluje hlavičky od těla odpovědi.

Tělo odpovědi (Body)

  • Obsahuje požadovaný zdroj nebo chybovou zprávu (např. HTML kód stránky).

HTTP Metody

  • Metody specifikují požadovanou akci

  • Idempotence

    • Idempotentní metody jsou ty, u kterých má vícenásobné identické provedení stejný efekt jako jediné provedení
    • např. GET, PUT, DELETE a bezpečné HEAD, OPTIONS
    • POST a PATCH obecně idempotentní nejsou.

  • Bezpečnost

    • Bezpečné metody nemění stav zdroje na serveru
    • Lze je typicky cacheovat
    • např. GET, HEAD, OPTIONS
Metoda Popis Idempotentní Bezpečná
GET Vyžádá reprezentaci specifikovaného zdroje.
Neměla by měnit stav serveru (je safe a idempotentní).
Používá se pro zobrazení stránek, vyhledávání.		 ✅ ✅
POST Odesílá data ke zpracování na specifikovaný zdroj.
Často způsobuje změnu stavu nebo vedlejší efekty na serveru (není ani safe, ani idempotentní).
Používá se pro odesílání formulářů, vytváření nových zdrojů.		 ❌ ❌
PUT Nahrazuje veškeré aktuální reprezentace cílového zdroje daty z požadavku.
Je idempotentní (opakované volání má stejný efekt jako jedno).		 ✅ ❌
DELETE Maže specifikovaný zdroj.
Je idempotentní.		 ✅ ❌
HEAD Podobné GET, ale odpověď serveru neobsahuje tělo, pouze hlavičky.
Používá se pro získání metadat o zdroji bez přenosu celého obsahu.		 ✅ ✅
PATCH Aplikuje částečné modifikace na zdroj.
Není ani safe, ani idempotentní.		 ❌ ❌
OPTIONS Vrací HTTP metody, které server podporuje pro danou URL. ✅ ✅
CONNECT Vytváří tunel k serveru identifikovanému cílovým zdrojem.
Např. pro použití SSH nebo FTP přes HTTP(S) protokol.		 ❌ ❌

HTTP Stavové kódy

  • Stavové kódy informují klienta o výsledku zpracování jeho požadavku.
  • Dělí se do pěti tříd:
    • 1xx (Informační): Požadavek byl přijat, proces pokračuje. (Např. 100 Continue)
    • 2xx (Úspěch): Požadavek byl úspěšně přijat, pochopen a akceptován.
      • 200 OK: Standardní odpověď pro úspěšné HTTP požadavky.
      • 201 Created: Požadavek byl splněn a jako výsledek byl vytvořen nový zdroj (typicky po POST nebo PUT).
      • 204 No Content: Server úspěšně zpracoval požadavek, ale nevrací žádný obsah (např. po DELETE).
    • 3xx (Přesměrování): K dokončení požadavku je třeba provést další akci.
      • 301 Moved Permanently: Požadovaný zdroj byl trvale přesunut na novou URL. Prohlížeče by si měly novou adresu zapamatovat.
      • 302 Found (dříve Moved Temporarily): Požadovaný zdroj je dočasně na jiné URL. Prohlížeče by měly nadále používat původní URL.
      • 304 Not Modified: Odpověď na podmíněný GET požadavek (využívající hlavičky jako If-None-Match nebo If-Modified-Since). Indikuje, že zdroj se od poslední žádosti nezměnil a klient může použít cachovanou verzi.
    • 4xx (Chyba klienta): Požadavek obsahuje chybnou syntaxi nebo nemůže být splněn.
      • 400 Bad Request: Server nemůže nebo nechce zpracovat požadavek kvůli něčemu, co je vnímáno jako chyba klienta (např. chybná syntaxe požadavku).
      • 401 Unauthorized: Požadavek vyžaduje autentizaci. Klient se musí autentizovat, aby získal požadovanou odpověď.
      • 403 Forbidden: Server rozuměl požadavku, ale odmítá jej autorizovat. Autentizace nepomůže.
      • 404 Not Found: Server nenalezl požadovaný zdroj
      • 405 Method Not Allowed: Metoda specifikovaná v řádku požadavku není pro daný zdroj povolena.
    • 5xx (Chyba serveru): Server selhal při plnění zjevně platného požadavku.
      • 500 Internal Server Error: Obecná chybová zpráva, když server narazil na neočekávanou podmínku, která mu zabránila splnit požadavek.
      • 503 Service Unavailable: Server není momentálně schopen zpracovat požadavek (např. z důvodu přetížení nebo údržby).

HTTP Hlavičky

  • Hlavičky přenášejí dodatečné informace.

  • Dělí se na obecné, hlavičky požadavku a hlavičky odpovědi.

  • Některé důležité hlavičky:

    • Host (požadavek): Doménové jméno serveru (povinná v HTTP/1.1).
    • User-Agent (požadavek): Informace o klientovi (prohlížeči).
    • Accept (požadavek): Typy médií, které klient akceptuje (např. text/html, application/json).
    • Content-Type (požadavek/odpověď): Typ média těla zprávy.
    • Content-Length (požadavek/odpověď): Délka těla zprávy v bajtech.
    • Authorization (požadavek): Autentizační údaje klienta.
    • WWW-Authenticate (odpověď): Výzva k autentizaci (používá se s kódem 401).
    • Location (odpověď): Používá se při přesměrování (s kódy 3xx) k určení nové URL.
    • Set-Cookie (odpověď): Nastavuje cookie u klienta.
    • Cookie (požadavek): Odesílá dříve nastavené cookies serveru.
    • Cache-Control (požadavek/odpověď): Direktivy pro cachování.
      • max-age=<sekundy>: Maximální doba platnosti cache.
      • no-cache: Cache musí být před použitím validována u serveru (např. pomocí ETag).
      • no-store: Odpověď nesmí být vůbec cachována.
      • private: Může být cachováno pouze soukromou cache (prohlížečem), nikoli sdílenými (proxy).
      • public: Může být cachováno jakoukoli cache.
    • ETag (odpověď): Identifikátor verze zdroje. Používá se pro podmíněné požadavky a efektivní cachování.
    • If-None-Match (požadavek): Používá se s ETag. Pokud se ETag shoduje, server vrátí 304 Not Modified.
    • Last-Modified (odpověď): Datum poslední modifikace zdroje.
    • If-Modified-Since (požadavek): Používá se s Last-Modified. Pokud se zdroj od té doby nezměnil, server vrátí 304 Not Modified.

Historie HTTP verzí

HTTP/0.9

  • Testovací jednořádkový protokol
  • Pouze GET metoda
  • GET /index.html
  • Vrací přímo požadovanou stránku

Request:

GET /index.html

Response:

<html>
<body>Ahoj světe!</body>
</html>

HTTP/1.0

  • Podpora hlaviček
  • Odpověď, status kódy

Request:

GET /index.html HTTP/1.0
Accept: text/html

Response:

HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 39

<html>
<body>Ahoj světe!</body>
</html>

HTTP/1.1

  • Povinná hlavička Host (kvůli VirtualHost, více domén na jedné IP)
  • Možnost poslat odpověď ve více částech (chunk)
  • Podpora trvalého spojení (Connection: Keep-Alive)
  • Pokročilejší cacheování

HTTP/2

  • Rozšíření HTTP/1.1
  • Binární přenos
  • Multiplexovaný
  • Stačí jediné spojení se serverem
  • Efektivní komprese hlaviček
  • Podpora server-push

HTTP/3

  • Rozšíření HTTP/2
  • Funguje nad UDP (protokol QUIC)
  • Zdokonaluje paralelní zpracování
  • Umožňuje jednoduší přechod mezi sítěmi (QUIC)

Stav webové aplikace

  • HTTP je bezstavový protokol, což znamená, že server si nepamatuje nic o předchozích interakcích s klientem.
  • Každý požadavek musí obsahovat všechny informace potřebné k jeho zpracování.
  • Pro webové aplikace, které vyžadují udržování kontextu (např. nákupní košík, přihlášený uživatel), je nutné stav explicitně spravovat.

Stav reprezentovaný v URL (query parametry)

  • Informace o stavu mohou být zakódovány přímo do URL, typicky jako parametry dotazu (query parameters).

  • Příklad: http://localhost/search?user=Svobo*&page=2

  • Výhody

    • Jednoduché sdílení stavu (např. odkaz na konkrétní stránku výsledků vyhledávání).
    • Možnost bookmarkování.
    • Stav je řízen odkazy (<a href="...">).

  • Nevýhody

    • Nevhodné pro citlivá data (viditelné v URL, logy serveru, historie prohlížeče).
    • Omezená délka URL.
    • Může být nepraktické pro komplexní stavy.

Cookies

  • Cookies jsou malé datové fragmenty, které server může uložit na straně klienta (v prohlížeči) a které klient následně posílá s každým dalším požadavkem na stejný server.

  • Server nastavuje cookie pomocí hlavičky Set-Cookie v odpovědi.

  • Klient posílá cookie na stejnou doménu pomocí hlavičky Cookie v požadavku.

  • Vlastnosti a parametry cookies

    • Název-hodnota: Základní data cookie.
    • Expires nebo Max-Age: Doba platnosti cookie. Expires udává konkrétní datum a čas, Max-Age dobu v sekundách od nastavení. Pokud není nastaveno, jedná se o session cookie, která se smaže po zavření prohlížeče.
    • Domain: Určuje domény, pro které je cookie platná.
    • Path: Určuje cesty na serveru, pro které je cookie platná.
    • Secure: Pokud je nastaven, cookie bude odesílána pouze přes HTTPS spojení.
    • HttpOnly: Pokud je nastaven, cookie není přístupná přes JavaScript (document.cookie), což pomáhá chránit proti XSS útokům, které by se snažily cookie ukrást. Toto je důležité bezpečnostní opatření, protože i když XSS zranitelnost existuje, útočník nemůže přímo přečíst session cookie.
    • SameSite: Kontroluje, zda je cookie odesílána s cross-site požadavky. Pomáhá chránit proti CSRF útokům.
      • Strict: Cookie se neposílá s žádnými cross-site požadavky, ani při navigaci.
      • Lax: Cookie se posílá při top-level navigaci (např. kliknutí na odkaz), ale ne při cross-site subrequestech (např. načítání obrázků, iframů) nebo POST požadavcích. Toto je často výchozí hodnota v moderních prohlížečích.
      • None: Cookie se posílá se všemi cross-site požadavky. Vyžaduje atribut Secure.
  • Výhody
    • Umožňují perzistentní stav napříč více požadavky a sessions.
    • Široká podpora.
  • Nevýhody
    • Omezená velikost (typicky 4KB).
    • Posílají se s každým HTTP požadavkem, což může zvyšovat datový přenos.
    • Mohou představovat bezpečnostní riziko, pokud nejsou správně zabezpečeny (např. session cookie hijacking).
    • Uživatel je může smazat nebo blokovat.
    • Na autenticitu dat v cookie se nelze spolehnout, server musí vždy validovat vstup z cookie, pokud ovlivňuje logiku aplikace.

Sessions (Relace)

  • Sessions představují mechanismus, kde server ukládá data o stavu klienta na své straně a klientovi posílá pouze unikátní identifikátor relace (Session ID), typicky prostřednictvím cookie.

  • Správa session je klíčová pro bezpečnost. Je důležité generovat silné, náhodné Session ID, pravidelně je měnit (session regeneration), používat HTTPS a atributy HttpOnly a Secure pro session cookie.

  • Princip

    1. Klient odešle požadavek.
    2. Pokud Session ID neexistuje nebo je neplatné, server vygeneruje nové unikátní Session ID.
    3. Server uloží data relace (např. obsah nákupního košíku) do svého úložiště (soubor, databáze, paměť) asociovaného s tímto Session ID.
    4. Server odešle Session ID klientovi (nejčastěji jako cookie, např. JSESSIONID, PHPSESSID).
    5. Při dalších požadavcích klient posílá Session ID zpět serveru.
    6. Server použije Session ID k načtení dat relace a obnovení stavu.

  • Párování klienta a session

    • Cookie (preferované): Session ID se uloží do cookie. Je to nejběžnější a relativně bezpečný způsob, pokud se používá HttpOnly a Secure atributy.
    • URL parametr: Session ID se přidává do každé URL. Méně bezpečné (Session ID je viditelné, může být sdíleno, problémy s cacheováním).

  • Výhody

    • Citlivá data jsou uložena na serveru, nikoli u klienta, což je bezpečnější.
    • Větší kapacita pro ukládání dat než u cookies.

  • Nevýhody

    • Zátěž na serveru (ukládání a správa session dat).
    • Složitější implementace v distribuovaných systémech (sdílení session).
    • Stále závisí na bezpečném přenosu a uložení Session ID u klienta.
    • Problémy s vypršením platnosti relace (session timeout).

  • Úložiště session dat

    • Souborový systém: Jednoduché, ale může být pomalé a problematické s konkurenčním přístupem.
    • Relační databáze: Robustní, transakční, ale může být bottleneck.
    • Key-value databáze (např. Redis, Memcached): Velmi rychlé, vhodné pro distribuované session.
    • Paměť serveru: Nejrychlejší, ale data se ztratí při restartu serveru, nevhodné pro produkční prostředí s více instancemi.

WebStorage (LocalStorage a SessionStorage)

  • Moderní alternativa ke cookies pro ukládání dat na straně klienta, která nejsou automaticky posílána s každým HTTP požadavkem.

  • K Web Storage má nativní přístup pouze klient (JavaScript)

  • Pokud chceme data z Web Storage poslat na backend server, musí to JavaScript udělat explicitně (manuálně). Typicky je načte z úložiště a vloží do těla (body) nebo do hlaviček AJAX/Fetch požadavku.

  • LocalStorage

    • Ukládá data trvale (dokud nejsou explicitně smazána).
    • Data jsou dostupná pro všechny okna/záložky se stejným původem (origin).
    • Kapacita typicky 5-10 MB.
    • Vhodné pro uživatelská nastavení, offline data.

  • SessionStorage

    • Ukládá data pouze pro aktuální session (životnost okna/záložky).
    • Data nejsou sdílena mezi okny/záložkami.
    • Kapacita typicky 5-10 MB.
    • Vhodné pro dočasná data, např. obsah formuláře před odesláním.

  • Bezpečnost

    • Protože do Web Storage má přístup klientský JavaScript, je toto úložiště extrémně náchylné na XSS (Cross-Site Scripting) útoky
    • Pokud útočník propašuje na tvou stránku svůj škodlivý JS kód, stačí mu zavolat localStorage.getItem('tajnyToken') a data si odeslat na svůj server.
    • Zatímco u cookies ses mohl bránit atributem HttpOnly (který JS zablokoval úplně), u Web Storage taková obrana neexistuje – z podstaty věci je to úložiště určené pro JavaScript.
    • Proto by se do localStorage ani sessionStorage neměly ukládat vysoce citlivé údaje, u kterých hrozí katastrofa při jejich odcizení.

Vytvořeno: 18. 6. 2026, 16:26
Poslední aktualizace: 20. 6. 2026, 14:37