Jak už název napovídá (HTTP = HyperText Transfer Protocol), byl síťový protokol HTTP vytvořen pro přenos HTML-souborů a dalších s ním souvisejících zdrojů (jako jsou například obrázky, skripty či stylová data; obecně tzv. resources) mezi klientem a serverem.

Veškerá tato komunikace probíhá na textové úrovni a je v základu bezestavová.

Dnes je převážně používána verze protokolu HTTP 1.1, která je sice poněkud komplikovanější na tvorbu a obsluhu než verze 1.0, ale podstatně lépe využívá zdrojů a prostředků – mimo jiné umožňuje využít mezipaměti (cache) a zasílat data, aniž by byla dopředu známa jejich celková délka (tzv. chunked encoding).

Jak jsme si už ukazovali v kapitole o práci webového prohlížeče, základním dotazem, který můžeme po protokolu HTTP poslat z klienta na HTTP-server je dotaz GET na konkrétní cílový zdroj:

Na uvedený textový dotaz v našem případě server odpověděl následující textovou odpovědí:

Shrňme si přechozí ukázku komunikace mezi HTTP-klientem a HTTP-serverem:

1. klient naváže spojení se serverem
2. klient zašle na server svůj požadavek (request message)
3. server zpracuje požadavek od klienta a zašle nazpátek odpověď (response message)
4. server ukončí spojení

Poslední bod znamená, že HTTP-protokol je bezestavový (stateless) – server si v základním nastavení podle standardu mezi jednotlivými transakcemi neudržuje a nepamatuju žádné informace (o jednotlivých klientech a jejich dotazech)! Na druhou stranu s pomocí nejrůznějších prostředků je možné tuto základní vlastnost HTTP-protokolu celkem obejít a svým způsobem z něj udělat protokol stavový.

Jak dotaz (request), tak odpověď (response) mají prakticky stejnou strukturu:

1. úvodní řádka zprávy Zde se od sebe dotaz a odpověď nejvíce odlišují.
2. posloupnost hlavičkových řádek V HTTP/1.1 alespoň jedna, v HTTP/1.0 se komunikace obešla prakticky bez nich.
3. prázdná řádka Je představována právě dvěma znaky CRLF (tedy sekvencí \r\n).
4. nepovinné tělo zprávy Může být různě dlouhé a kromě textových může obsahovat klidně i binární data.

Úvodní řádka zprávy má tři části (navzájem oddělené mezerami), jejichž význam se liší podle typu/směru dotazu/odpovědi. Řádka končí posloupností znaků CRLF (ale programy by si měly poradit i se samotným LF):

Úvodní řádka požadavku (request) má následující strukturu:

metoda   lokální-cesta-ke-zdroji   verze-protokolu↵

Příklady:

Úvodní řádka odpovědi (response), též zvaná status line, má následující strukturu:

verze-protokolu   kód-odpovědi   popis-odpovědi↵

Příklady:

Hlavičkové řádky mají všechny stejnou strukturu (definovanou v RFC 822):

jméno-hlavičky:   hodnota↵

Platí pro ně následující pravidla:

• končí posloupností znaků CRLF (ale programy by si měly poradit i se samotným LF)
• jméno hlavičky nerozpoznává velká a malá písmena
• počet mezer mezi jménem s dvojtečkou a vlastní hodnotou není významný
• řádky začínající mezerou nebo tabulátorem jsou pokračováním hodnoty předchozí řádky

Protokol HTTP/1.1 (bez rozšíření) definuje 47 hlaviček, z nich pouze jedna jediná (Host: u dotazu) je skutečně povinná. Další slouží k určení dodatečných informací o dotazu nebo odpovědi, a to včetně informací o těle zprávy.

Pro detailnější přehled (i nestandardních) hlaviček se podívejte třeba na Wikipedii.

Příklad hlaviček ze skutečné komunikace mezi klientem a serverem pří načtení této stránky:

Pár komentářů k požadavku:

• Host – povinná hlavička dotazu; určuje kořenovou adresu dotazu
• Accept – typy odpovědi, které klient umí zpracovat
• Accept-Encoding – typy komprese odpovědi, které klient umí rozkódovat
• Referer – adresa předchozí stránky, ze které jsme se dostali na tento zdroj
• If-Modified-Since – nebyl-li zdroj modifikován od uvedeného data, může server vrátit odpověď 304 Not Modified a klient může použít verzi z keše

Pár komentářů k odpovědi:

• Date – datum odeslání odpovědi
• Last-Modified – datum modifikace zdroje (ve formátu podle RFC 2822)
• Content-Type – MIME-typ odpovědi (tedy těla odpovědi)
• Content-Length – délka těla odpovědi v bajtech
• Accept-Ranges – podporované typy rozsahů, s jakými dokáže server odpovědět na požadavek (tedy že je schopen poslat z těla odpovědi vybraný rozsah)

Tělo zprávy slouží ke dvěma účelům:

• K přenosu vlastního zdroje (respektive odpovědi daného zdroje) zpět ke klientovi.
• K přenosu potřebných dat při dotazu od klienta směrem na server. Tohle je místo, kterým se přenáší data z vyplněných formulářů nebo třeba aploudované soubory.

Obsahuje-li zpráva tělo, zpravidla ho v hlavičkové části doprovází následující dvě hlavičky:

• Content-Type – MIME-typ přenášených dat (zda je to HTML-text nebo JPEG-obrázek apod.) Zde se server nebo klient dozví typ dat, což potřebuje k rozhodnutí, jak s nimi naložit.
• Content-Length – velikost těla v bajtech Zde se server nebo klient dozví délku dat, která potřebuje načíst.

Protokol HTTP/1.1 definuje (bez rozšíření) osm základních metod, které může klient aplikovat při zasílání požadavku:

1. OPTIONS – vyžádá si vrácení HTTP-metod, které server pro daný zdroj podporuje Užitečné pro zjištění podporovaných metod. A to i v rámci celého serveru, je-li jako zdroj zaslán řetězec *.
2. GET – požaduje zaslání konkrétního zdroje Tato metoda by z konvence na serveru neměla nic měnit (tedy neměla by mít žádné vedlejší efekty), prostě by jen měla vrátit požadovaný zdroj.
3. HEAD – jako GET, ale v odpovědi bude pouze hlavičková část zprávy, tělo nebude zasíláno Velmi výhodné pro získání metainformací (v podobě návratových hlaviček) o požadovaném zdroji, aniž by se musel celý (potenciálně velmi velký) zdroj přenášet.
4. POST – zasílá serveru data ke zpracování Tedy dané URI zpracuje obdržená data.
5. PUT – zasílá serveru data k uložení (pokud dané URI neexistuje) nebo modifikaci (pokud dané URI existuje) V kontrastu k metodě POST je dané URI změněno obdrženými daty.
6. DELETE – zasílá serveru požadavek na vymazání uvedeného zdroje
7. TRACE – zašle nazpět obraz požadavku Porovnáním zaslaného a vráceného dotazu si může klient ověřit, zda se s ním (tedy jeho hlavičkami a tělem) cestou něco nestalo. Typicky např. síťové keše doplňují procházející data o svoji identifikaci (což by ovšem měla být nekonfliktní úprava).
8. CONNECT – vyhrazeno pro převod navázané komunikaci mezi klientem a serverem přes nekryptěnou proxy na tunel Užíván často k zajištění zabezpečené komunikace.

Z hlediska své (alespoň zamýšlené) aplikace a vlivu na server se HTTP-metody rozlišují podle dalších dvou hledisek:

Metody bezpečné: Tyto metody by neměly změnit stav serveru, měly by si čistě pouze vyžádat vrácení požadovaného zdroje.

Typicky mezi ně patří HEAD, GET, OPTIONS a TRACE, ale obzvláště metoda GET často „zlobí“ a webové aplikace ji zneužívají k nejrůznějším dalším operacím.

Metody idempotentní: Jejich vícenásobná aplikace by měla mít stejný efekt jako aplikace pouze jediná.

Typicky vícenásobná aplikace metod PUT a DELETE už by více neměla změnit stav serveru. Podobně aplikace bezpečných metod HEAD, GET, OPTIONS a TRACE by stav serveru neměla měnit vůbec, takže by měly být idempotentní automaticky (ovšem pozor na GET ve stejném smyslu jako výše).

Kódy odpovědí jsou přesně zadefinovaná třímístná čísla z pěti obecnějších kategorií:

1. 1xx – informační; participují zvláště na údržbě spojení při komplikovanějších transakcích podle HTTP/1.1
2. 2xx – úspěch; požadavek klienta byl úspěšně přijat, zpracován a je na něj zasílána odpovídající odpověď
3. 3xx – přesměrování; dokončení zpracování požadavku vyžaduje z nejrůznějších důvodů (zdroj byl přesunut na jinou adresu, zdroj se od udaného data nezměnil…) další spolupráci klienta
4. 4xx – chyba klienta; klient zřejmě zaslal z nejrůznějších důvodů (chyba formátování, dotaz na neexistující zdroj…) špatný požadavek
5. 5xx – chyba serveru; při zpracování požadavku došlo k chybě na straně serveru, který tak není schopen správně odpovědět

Typickými kódy, se kterými se můžete bězně setkat, jsou například:

• 100 Continue – server obdržel hlavičku dotazu a čeká na její tělo
• 200 OK – standardní hlášení o úspěšném zpracování požadavku
• 304 Not Modified – zdroj nebyl od klientem uvedeného data změněn (klient tedy může využít zakešovanou verzi zdroje, má-li ji k dispozici)
• 404 Not Found – požadovaný zdroj se na serveru (v dané chvíli) nevyskytuje
• 500 Internal Server Error – generické hlášení o chybě na straně serveru

Pro detailnější přehled (i nestandardních) návratových kódů se podívejte třeba na Wikipedii.

URI

Uniform Resource Identifier; jistá sekvence znaků tvořící identifikátor příslušného zdroje

URL

Uniform Resource Locator; ta podmnožina URI, pro kterou je nejvýznamější částí adresa zdroje

URN

Uniform Resource Name; ta podmnožina URI, pro kterou je nejvýznamější částí jméno zdroje

MIME

Multipurpose Internet Mail Extensions; specificky ale způsob označování typů dokumentů (a to včetně abstraktních obálek nad více zdroji apod.)

RFC

Request For Comments; memoranda publikovaná skupinou Internet Engineering Task Force (IETF), některá z nich se stávají internetovými standardy