V předchozích dílech jsme se zabývali především stavbou stránek a jejich působením na uživatele. Mlčky jsme předpokládali, že přenosový mechanismus WWW nějak funguje a server s klientem se domluví a vymění si potřebná data. Tentokrát se podíváme, jak vlastně Web pracuje. Dovolíme si prohřešit se proti názvu našeho seriálu. Dnešní díl nebude o HTML, ale o přenosových mechanismech. Nebude také doprovázen příkladem.

Jedná se o protokol bezstavový. To znamená, že server si neudržuje žádné informace o svých klientech. Obdrží-li dotaz, odpoví na něj a tím pro něj skončila jedna ucelená HTTP transakce. Pokud zanedlouho dostane dotaz od téhož klienta, nedává si jej do žádných souvislostí s dotazem předchozím (přestože byl třeba vyvolán některým z odkazů na stránce, kterou tomuto klientovi před chvilkou odeslal). Veškeré stavové informace (např. adresu aktuální stránky) si musí pamatovat klient.

Jedna WWW transakce se skládá z dotazu a odpovědi na něj. Vše samozřejmě začíná pokynem uživatele - například výběrem některého z odkazů na stránce. Z něj si klient určí URL informace, kterou má získat. Připomeňme, že z lokátoru se dozví

• který protokol použít ke komunikaci
• jaký server kontaktovat
• co po něm chtít

Protokol HTTP prošel během několika let své existence nezanedbatelným vývojem. Jeho první verze, označená 0.9, byla velmi primitivní. Umožňovala vlastně jen syrový přenos dat ze serveru ke klientovi a v současnosti je považována za zastaralou. Dnešním standardem je verze 1.0, definovaná v RFC 1945. Jejím nejdůležitějším přínosem je možnost doprovodit dotaz i odpověď řadou doplňujících informací. V nich lze uvést typ dokumentu, dobu jeho vzniku či schopnosti a požadavky klienta. Několikaleté používání této verze však odhalilo jisté slabiny a proto vývoj pokračoval verzí 1.1. Během psaní článku byla dokončena a připravena k prohlášení za standard. Je možné, že v době, kdy budete tento text číst, bude HTTP 1.1 existovat již ve formě RFC.

Verze 1.1 není takovým krokem vpřed, jako svého času 1.0. Nicméně přináší několik užitečných rozšíření. Zaměřují se na zvýšení efektivity HTTP, lepší práci vyrovnávacích pamětí a serverů (proxy cache) a pro nás užitečnou zdokonalenou podporu neanglických jazyků.

Podívejme se nyní na základní části HTTP. Upozorňujeme, že se bude jednat o pohled značně zjednodušený. Specifikace HTTP 1.1 má totiž více než 100 stran.

Jistě si vzpomínáte, že při sestavování formuláře můžete atributem METHOD ve značce <FORM> předepsat, kterou z těchto dvou metod má klient použít k odeslání dat. Formuláře a obecně spouštění CGI skriptů jsou prakticky jediné případy, kdy se používá metoda POST. Umožňuje přidat k dotazu i velmi objemný balík dat. Pro vyzvedávání běžných stránek bohatě stačí GET. HTTP verze 1.1 přidalo i metody pro další činnosti. Umožňuje např. umístění odeslaných dat přímo na server (metoda PUT) nebo naopak likvidaci některého z nabízených souborů (DELETE).

Pomocí hlaviček může klient svůj dotaz upřesnit či doprovodit doplňkovými informacemi. Například hlavička Accept oznamuje, jaké typy informací je klient ochoten přijmout. Pošle-li serveru dotaz

GET / HTTP/1.0
Accept: text/html, text/plain, image/*

Tvar hlaviček se shoduje s hlavičkami elektronického dopisu. Každá je na samostatném řádku a začíná vždy jménem hlavičky. Za ním následuje dvojtečka a hodnota hlavičce přiřazená.

Pro celkové posouzení odpovědi je nejdůležitější první řádek. Z něj se klient dozví, zda byl jeho dotaz úspěšně zodpovězen a jak má chápat celý zbytek odpovědi. Rozhodující je stavový_kód a s ním svázaný popis. Oba mají stejný význam - oznamují výsledek zpracování dotazu, jsou však určeny různým čtenářům. stavový_kód je číselný a slouží klientovi. popis obsahuje stručný textový popis odpovídajícího kódu a je určen případnému lidskému čtenáři.

Stavové kódy jsou trojciferné a podle své první číslice se dělí do několika skupin. Jistě nejvítanější jsou kódy skupiny 2xx, signalizující úspěch. Většina dotazů naštěstí skončí s výsledkem 200 (OK), kterým server oznamuje "dotaz byl v pořádku, tady ti posílám odpověď". O něco smutnější, ale ještě ne beznadějná je skupina 3xx. Tyto kódy oznamují přesměrování - server sděluje klientovi, že požadovaný objekt byl přesunut jinam. Součástí odpovědi musí být hlavička Location, obsahující nové URL požadovaného objektu. Nejvýznamnějšími představiteli této skupiny jsou kódy 301 (Moved Permanently - přesunuto trvale, příště se již vždy obracej na novou adresu) a 302 (Moved Temporarily - přesunuto dočasně, teď zrovna je tenhle objekt jinde, ale příště přijď zase ke mně, protože by se měl vrátit). Pokud klient požaduje soubor, který byl trvale přesunut např. na adresu http://www.jinde.cz/soubor.html, odpoví server následovně:

HTTP/1.0 301 Moved Permanently
Location: http://www.jinde.cz/soubor.html
Content-Type: text/html

Soubor je umístěn
<A HREF="http://www.jinde.cz/soubor.html">jinde</A>.

Skupina 4xx není mezi uživateli příliš populární, protože signalizuje chybu ze strany klienta. Patří sem nejčastější chybové hlášení 404 (Not Found), které bývá způsobeno chybným lokátorem. Do skupiny 5xx jsou zařazeny chyby serveru, proti kterým se klient nemůže příliš bránit. Naštěstí takovou odpověď uvidíte jen zřídka.

Odpovědi mívají tělo a s ním je spojeno několik hlaviček, charakterizujících jeho obsah. Patří sem především Content-Type (jakého druhu je přenášené tělo) a Content-Length (kolik bajtů měří). Tyto hlavičky by se měly objevit i v dotazu, pokud nese tělo. HTTP verze 1.1 navíc požaduje, aby každá odpověď obsahovala hlavičku Date, obsahující čas jejího odeslání.

Má-li WWW provoz projít hradbou, musí na hradebním počítači běžet tak zvaný zprostředkující server (proxy server). Klienti z lokální sítě pak neposílají své dotazy přímo cílovým serverům, ale zprostředkovateli. Ten je předá serveru a jeho odpověď pak zašle klientovi. Jakmile byl tento mechanismus jednou vymyšlen, stačil jen krůček k vytvoření vyrovnávacího serveru (proxy cache), který významně redukuje objem WWW provozu v Internetu. Vyrovnávací server je vlastně zprostředkovatel, který si ukládá odpovědi do lokální paměti. Pokud se v brzké době zopakuje stejný dotaz, neobtěžuje původní server, ale rovnou odešle klientovi uloženou dřívější odpověď.

Kvalitní programy (velmi populární je například volně šiřitelný Squid) navíc umožňují vzájemnou spolupráci vyrovnávacích serverů a vytváření různých vazeb mezi nimi. Praktická sledování na našem vyrovnávacím serveru (cache.vslib.cz) ukazují, že přibližně polovinu dotazů dokáže obsloužit z vlastních zdrojů, další čtvrtinu získá od spolupracujících vyrovnávacích serverů a pouze pro čtvrtinu odpovědí se obrací na cílové servery.

Pro potřeby vyrovnávacích pamětí a serverů je určen tak zvaný podmíněný dotaz. Jedná se o běžný HTTP dotaz, který je však opatřen hlavičkou If-Modified-Since. Posílá se v případě, že klient či vyrovnávací server má v paměti jistou verzi dokumentu a chce ověřit, zda neexistuje novější. Pokud server skutečně má mladší verzi, pošle ji stejným způsobem, jako při normálním dotazu (použije stavový kód 200). Jestliže však nic novějšího neexistuje, odpoví stavovým kódem 304 (Not Modified). Taková odpověď je samozřejmě bez těla. Tazatel se z ní dozví, že jeho verze je stále ještě platná.

HTTP verze 1.1 věnuje problematice vyrovnávacích pamětí značnou pozornost. Nabízí dokonalejší metody pro identifikaci dokumentů a jejich verzí, hlavičku Cache-Control, kterou mohou klient i server ovlivňovat vyrovnávací servery mezi sebou.

Nová verze HTTP již tuto vlastnost zahrnuje. Navíc přidává řetězení dotazů (pipelining). Při něm klient nemusí s odesláním dotazu čekat na odpověď. Odešle transportním spojením všechny dotazy, které má, a pak jen čeká na odpovědi. Díky těmto mechanismům podstatným způsobem klesne počet datagramů, přepravovaných Internetem.