Nejprve si řekněme některá základní fakta. Protokol HTTP je postaven na principu dotaz – odpověď. Jakákoliv aktivita musí být vyvolána klientem. Komunikace se serverem probíhá přes TCP (server většinou používá port 80, ale není to podmínkou). Úplný dotaz/odpověď musí mít specifikovánu metodu, URI (absolutní nebo relativní cesta k souboru nebo úplné URL dokumentu), verzi a hlavičky. V některých případech následuje po hlavičkách i tělo dotazu oddělené jedním prázdným řádkem. Všechno si můžete v klidu ihned vyzkoušet – stačí vám telnet klient a připojení k internetu nebo lokální webserver. Nezapomeňte za každým dotazem 2× odřádkovat.
#>telnet www.root.cz 80 GET / HTTP/1.1 Host: www.root.cz |
Jednoduchý HTTP 1.1 dotaz |
(hlavička Host: by neměla být v tomto případě povinná, ale zdá se, že Apache na ní trvá – pozn. redakce)
Server podporující protokol 1.0 vrátí odpověď a spojení ihned uzavře. Protokol 1.1 definuje tzv. perzistentní spojení a proto servery podporující verzi 1.1 spojení neuzavřou hned, ale čekají chvíli na další příkazy. Klient může pokračovat v dotazování na ostatní prvky HTML stránky (obrázky…) a spojení ukončit sám. Odpověď na takovýto HTTP dotaz může vypadat asi takto:
HTTP/1.1 200 OK Date: Mon, 05 Feb 2001 10:18:22 GMT Server: Apache/1.3.12 (Unix) (Debian/Linux) Content-Type: text/html <HTML> ... </HTML> |
Příklad jednoduché HTTP 1.1 odpovědi |
Odpověď obsahuje verzi protokolu, kód odpovědi (1×x – informativní, 2×x – úspěch, 3×x – přesměrování, 4×x – chyba na straně klienta nebo 5×x – chyba na straně serveru) a textovou hlášku odpovědi (zde je to „OK“). Odpověď obsahuje dále hlavičky, prázdný řádek coby oddělovač a většinou i tělo odpovědi (ovšem ne vždy, viz OPTIONS nebo HEAD). Výše uvedený příklad je vlastně špatný, protože jsem ho poněkud pozměnil. Díky tomu, že spojení v HTTP 1.1 je perzistentní, musí být v hlavičce uvedena přesná délka těla odpovědi (nebo alespoň typ kódování), aby klient věděl, kde odpověď končí a mohl se případně dotázat znovu (na základě získaných dat). Klienti také mohou zasílat dotazy aniž by čekali na odpovědi – server je v tomto případě povinen vyřizovat požadavky ve stejném pořadí, v jakém je přijal.
Metody dotazu
GET
je nejpoužívanější metoda. Slouží k vyzvednutí objektu (html soubor, obrázek, cokoliv…) ze serveru. Odpověď je „kešovatelná“. Proto GET dotaz doprovází spoustu hlaviček ve kterých se specifikuje, jak je dokument starý, zda byl modifikován atd. GET dotaz obvykle nemá tělo.
POST
Pomocí této metody se dají v těle dopravit na server informace od uživatele (velmi často se POST používá pro odeslání rozsáhlejších dat z webových formulářů, pro upload souboru a podobně).
HEAD
se chová naprosto stejně jako GET, ale v odpovědi se nepřenáší tělo. Tento dotaz se hodí například ke zjištění, zda objekt existuje (při kontrole odkazů na stránce).
PUT/DELETE
vytvoří/smaže daný objekt ze serveru. Tyto metody se v praxi příliš nevyužívají.
OPTIONS
slouží ke zjištění informací o daném kontextu (nebo „*“ pro celý server). Klient může zjistit, které dotazy může na daný kontext zaslat.
OPTIONS * HTTP/1.1 Host: www.root.cz HTTP/1.1 200 OK Date: Mon, 05 Feb 2001 10:13:52 GMT Server: Apache/1.3.12 (Unix) Vary: Accept-Charset,Accept-Language Allow: GET, HEAD, OPTIONS, TRACE Transfer-Encoding: chunked Content-Type: text/plain 0 |
Ukázka implicitního nastavení serveru |
TRACE
se používá ke sledování cesty celého dotazu. V těle odpovědi klient dostane pěkně seřazené všechny dotazy jednotlivých systémů, kterými požadavek procházel. Tato metoda je používaná administrátory a webovými programátory, kteří chtějí zjistit, proč jim server vrací například prošlý (expirovaný) dokument apod.
TRACE / HTTP/1.1 Host: www.root.cz HTTP/1.0 200 OK Date: Mon, 05 Feb 2001 10:34:04 GMT Server: Apache/1.3.12 (Unix) Content-Type: message/http X-Cache: MISS from proxy.firma.cz Connection: close TRACE / HTTP/1.0 Cache-Control: max-age=259200 Connection: keep-alive Host: www.root.cz Via: 1.1 proxy.firma.cz:3128 (Squid/2.3.STABLE1) X-Forwarded-For: 172.20.0.111 |
Sledování dotazu přes http proxy |
CONNECT
slouží k tunelování HTTP protokolu (například SSL).
Hlavičky
Protokol HTTP verze 1.1 definuje velké množství hlaviček pro dotazy i odpovědi. Zde jsou některé z nich:
Dotazové hlavičky
Accept*
Hlavičky tohoto typu indikují, co všechno je schopen klient zpracovat. Server pak vybere nejvhodnější alternativu. Patří sem hlavičky Accept (MIME typy dokumentů), Accept-Charset (znaková sada, v českém prostředí velmi důležité), Accept-Encoding (kódování přenášených dat, většinou slouží k výběru komprese) a Accept-Language (jazyk dokumentu).
Connection
V protokolu HTTP 1.1 je definován parametr „close“, který požaduje okamžité uzavření spojení po přenosu prvního vyžádaného dokumentu.
Referer
Klient touto hlavičkou sděluje URI stránky, ze které byl odkaz vygenerován.
Host
HTTP 1.1 zavádí podporu tzv. name-based virtuálních serverů. Tato metoda umožňuje provozovat více virtuálních serverů na jediné IP adrese, klient ovšem musí pomocí této hlavičky specifikovat jméno serveru, s nímž chce komunikovat.
User-Agent
Touto hlavičkou by se měl klientský program identifikovat, ať už pro účely statistické či pro poskytování odlišného obsahu různým prohlížečům a podobně.
Hlavičky odpovědi
Content*
Hlavičky popisující obsah (tělo) odpovědi. Mohou obsahovat například délku obsahu (Content-Length), jeho MD5 digest (Content-MD5), jazyk (Content-Language), typ dokumentu (Content-Type) a další atributy. Nutno podotknout, že tyto hlavičky se nepoužívají pouze v odpovědích – pakliže obsahuje požadavek i tělo (např. při metodě POST), je obvykle nutné je rovněž použít.
Server
Tato hlavička slouží serveru k vlastní identifikaci (obvykle zde najdeme jeho jméno, verzi a někdy i další informace).
Expires
Server může prostřednictvím tohoto údaje sdělit, kdy vyprší platnost dokumentu. Po uplynutí této doby by si měl klient stáhnout novou verzi.
Existuje i řada dalších hlaviček, kterými může například klient řídit stažení dokumentu („stahuj pouze pokud byl dokument modifikován od …“) nebo třeba předat serveru uživatelské jméno a heslo pro přístup k neveřejným částem serveru. Podobně i server může jemněji popsat svou odpověď a například sdělit klientovi, kdy byl naposledy dokument modifikován nebo zda je povoleno jeho kešování ve veřejných či privátních keších.
V tomto článku jsem v žádném případě nepopsal všechny vlastnosti HTTP protokolu. Jen jsem nastínil principy, na nichž je založen, což doufám ocení zejména začínající administrátoři či weboví programátoři. Pro bližší studium bych všechny zájemce odkázal v první řadě na patřičná RFC: