HTTP protokol

Hypertext Transfer Protokol (HTTP) je protokol aplikační vrstvy. Používá se pro distribuované hypermediální informační systémy. Pro službu WWW se používá od roku 1990.

První používaná verze HTTP 0.9 byla jednoduchá. Zajišťovala pouze přenos dat po Internetu bez dalších doplňkových informací o přenášených datech. Klient musel odhadnou podle koncovky souboru o jaká data se jedná.

Brzy se ukázalo, že tato varianta nepostačuje a nastoupila verze nová HTTP 1.0. Verze 1.0 se snažila doplnit popisující informace do dotazu a odpovědi a použila pro to již existující formát MIME (Multipurpose Internet Mail Extension). Rozšířila tvar dotazu a odpovědi o standardizované doplňující informace charakterizující přenášená data ve tvaru typ/podtyp. HTTP 1.0 je definováno v RFC 1945.

S rozvojem služby WWW se objevovaly další požadavky na HTTP protokol. šlo především o práci hierarchickou strukturou proxy, využívání cache, požadavek na trvalé spojení mezi klientem a serverem a požadavky na virtuální servery. Tyto nedostatky řeší nová verze protokolu HTTP 1.1, která je definována v RFC 2068 v lednu 1997.

Pravidla komunikace jsou definována, ale otázkou zůstává jaká je praxe v jejich využití. Většina WWW serverů dnes (počátek roku 1997) používá protokol HTTP 1.0. Novější verze serverů pak podporují některá rozšíření verze 1.1.

HTTP protokol je protokol aplikační vrstvy. Vlastní přenos dat zajišťuje protokol vrstvy nižší např. TCP. HTTP protokol tedy předpokládá, že na jednom konci předá data pro přenos a na druhém konci obdrží data v nezměněné podobě.

Pomocí HTTP protokolu komunikuje na příslušných portech klient se serverem. HTTP server je obvykle spuštěn na portu 80. Je možné ho ale provozovat i na portu jiném.

Jak pracuje HTTP protokol?

HTTP protokol verze 1.0 vychází z modelu dotaz-odpověď. Klient pošle požadavek na server, server klientovi odpoví a komunikace se uzavírá. Požaduje-li opakovaně klient stejná data od serveru, navazuje se nové spojení a server opět posílá data. Případné uchování některých informací o komunikaci mezi klientem a serverem (např. o tom, která data již dříve klient obdržel) je ponecháno zcela na klientovi. Protokol si informace o již provedených spojeních neudržuje, je to protokol bezstavový.

Většina HTTP komunikace je iniciována klientem a sestává z požadavku na nějaký server. Tento jednoduchý příklad může být realizován jedním spojením mezi klientem a serverem.

Předpokládejme, že klient chce získat od serveru se jménem server soubor. Klient tedy vyšle dotaz začínající dotazovým řádkem:

GET /cesta/soubor  HTTP/1.1

Rozšíření verze 1.1

Trvalé spojení

Verze HTTP 1.1 zavádí možnost trvalého spojení. V rámci tohoto spojení pak klient posílá všechny své požadavky na server a server mu po tomto spojení posílá své odpovědi. Je definovám mechanismus ukončení spojení. Ve verzi HTTP 1.1 je trvalé spojení chápáno jako implicitní pro všechny HTTP spojení. Není-li tedy řečeno jinak, může klient předpokládat, že server udržuje trvalé spojení a naopak. Spojení zůstavá otevřeno do té doby, dokud klient nebo server spojení neukončí. Spojení se ukončuje vysláním hlavičky Connection: close, požadavek obsahující tuto hlavičku je poslední na daném spojení. Je-li signalizováno ukončení spojení od serveru, nesmí již klient poslat po spojení další požadavek. Všechny zprávy posílané v trvalém spojení musí mít definovanou délku v hlavičce Message-length.

Zřetězené zpracování

Virtuální WWW servery

HTTP 1.1 zavádí hlavičku Host a definuje zpracování této hlavičky na straně klienta i serveru. Pokud tato hlavička chybí, vrací chybu. Pomocí této hlavičky se až k http serveru dostanou informace o jméně počítače a server může vracet na různá jména různé odpovědi.

Vyjednávání o obsahu

• serverem řízené dohadování
• klientem řízené dohadování

Serverem řízené dohadování

Klientem řízené dohadování

Formát dotazu a odpovědi

Dotaz a odpověď mají podobnou strukturu:

Formát dotazu dotazový řádek hlavičky blíže popisující dotaz prázdný řádek (tělo dotazu)

Příklad: GET /index.html HTTP/1.0 Accept: text/html Accept: image/gif User-Agent: mozilla Form: alena@info.pvt.net * prazdny radek *

Odpověď stavový řádek hlavičky blíže popisující odpověď prázdný řádek tělo odpovědi

Příklad kladné odpovědi: HTTP/1.0 200 OK Server: Netscape-Enterprise/2.0a Date: Thu, 06 Mar 1997 16:23:43 GMT Accept-ranges: bytes Last-modified: Fri, 22 Dec 1995 17:41:00 GMT Content-length: 1032 Content-type: text/html </table> <P ALIGN=CENTER> <B><I> <FONT SIZE=+3>Obrazky ze sveta</B> </I></P> .... Příklad záporné odpovědi: HTTP/1.0 404 Not found Server: Netscape-Enterprise/2.0a Date: Thu, 06 Mar 1997 16:12:04 GMT Content-length: 207 Content-type: text/html</font><H1>Not Found</H1> The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it. Fungování HTTP protokolu si můžete jednoduše vyzkoušet pomocí protokolu telnet. Telnetem navážete spojení se serverem na portu 80. Po vzniklém spojení vyšlete dotaz na server viz. předchozí příklad. Od serveru obdržíte odpověď. Příklady fungování HTTP. Proxy a gateway Na cestě mezi originálním WWW klientem a originálním WWW serverem se často vyskytují prostřednící ve formě proxy nebo gateway. Proxy Proxy je program, který pracuje současně jako server i klient. Jeho úkolem je vydávat se za klienty, kteří stojí za proxy, tj. posílat jejich dotazy do Internetu svým jménem. V případě proxy nenavazuje originální klient spojení přímo s originálním serverem, ale se serverovou částí proxy. Ta přepíše celý dotaz nebo jeho část a předá jej svým jménem směrem k originálnímu serveru. Opačným směrem pak přijme odpověď a předá ji originálnímu klientovi. Všimněte si, že dotaz klienta v tomto případě obsahuje celé URL včetně specifikace serveru. Klient stojící za proxy totiž nemusí umět ani přeložit jméno počítače na IP adresu. Teprve proxy provede překlad. Naváže spojení se serverem a v dotazu specifikuje pouze cestu k souboru. Dostane-li proxy požadavek v HTTP protokolu, předá je dále opět v HTTP protokolu. Proxy si může obdržené odpovědi ukládat na disk. V případě výskytu stejného požadavku pak může využít cachovaná data z disku a zkrátit tak cestu k získání dokumentu. Gateway Gateway na rozdíl od proxy provádí konverzi mezi dvěma protokoly Obdrží požadavek jako cílový server a pokud je potřeba provede překlad požadavku do jiného protokolu např. ftp. Protokol HTTP přímo podporuje gateway, proto se v URL používá název příslušného protokolu. Metody protokolu Metoda určuje druh služby, kterou klient od serveru požaduje. Metoda se uvádí velkými písmeny. Server nemusí vždy všechny metody podporovat. Při dotazu nepodporovanou metodou pak vrací chybové hlášení. OPTIONS Metoda OPTIONS představuje dotaz na možnosti komunikace spojené s uvedeným URL. Metoda umožňuje klientovi určit možnosti a omezení spojené se zdrojem nebo schopnostmi serveru. Pokud je URL v dotazu ve tvaru "*", pak se jedná o dotaz na možnosti serveru jako celku. GET Metoda GET představuje požadavek na poslání dokumentu určeného pomocí URL. V souvislosti s proxy se může metoda GET změnit na "podmíněný GET", která požaduje poslat dokument pouze za určitých podmínek definovaných v hlavičce dotazu. HEAD HEAD metoda je identická s metodou GET, server však nemusí posílat tělo odpovědi. Metodu je možné použít k získání doplňkových informací o dokumentu, často se používá k testování hypertextových linek, jejich dostupnosti a poslední modifikace. Klient může získané hlavičky analyzovat a případně požádat o data novým dotazem GET (např. test zda dokument není příliš dlouhý). POST POST metoda se používá v případě, kdy má cílový server přijmout data z požadavku. Skutečná funkce metody závisí na URL s ní spojené. Výsledkem POST metody může být poslání mailu, předání dat do procesu, který data zpracuje, rozšíření databáze. Posílaná data nejsou nijak omezená a je možné v hlavičkách tělo zprávy popsat. PUT PUT metoda představuje požadavek na uložení posílaných dat pod specifikované URL na server. Takto uložená data budou dostupná např. následnými dotazy GET. Metoda PUT předpokládá, že uložení dat do souboru na server provádí přímo server nikoli externí aplikace (CGI program). DELETE Požadavek na zrušení dokumentu na serveru. Rušený dokument je specifikován v URL. TRACE Metoda použitá k testování originálního serveru. Originální server má vrátit klientovi kladnou odpověď bez dat. WWW servery používané v současné době podporují vždy metody GET, POST a HEAD. URL v dotazu Url v dotazu může být uvedeno ve tvaru: * absolutní URL absolutní cesta Konkrétní tvar URL závisí na typu požadavku. Hvězdička znamená, že se požadavek nevztahuje na dokument, ale na server jako celek. Např.: OPTIONS * HTTP/1.1 Absolutní URL se používá, pokud je požadavek směrován na proxy. Např: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 Nejčastěji se v dotazu používá absolutní cesta, která identifikuje soubor na originálním serveru, se kterým bylo navázáno spojení. Verze HTTP 1.1 posílá navíc jméno nebo IP adresu originálního serveru v hlavičce Host. Např: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org Absolutní cesta nesmí být prázdná, pro root serveru se musí uvést znak "/". Výsledkové kódy Výsledkové kódy jsou rozděleny do pěti tématických skupin podle své první číslice. 1xx - informační - Požadavek byl obdržen. 100 Continue Klient může pokračovat v posílání požadavku. Jde o meziodpověď od serveru. Po obdržení celého požadavku ho server začne obsluhovat a pošle konečný výsledkový kód. 101 Switching Protokols Server rozuměl požadavku a mění protokol podle specifikace v hlavičce Upgrade. 2xx - úspěch - Dotaz byl serverem pochopen a akceptován. 200 OK Dotaz byl obsloužen bez chyb. Server posílá odpověď. 201 Created Výsedkem zpracování dotazu bylo vytvoření nového objektu, který lze identifikovat pomocí URL. URL vytvořeného dokumentu je posíláno v těle odpovědi. 202 Accepted Dotaz byl přijat, jeho zpracování však dosud neskončilo. Klient nemusí čekat na dokončení. 203 Non-Autoritative Information Vrácené meta informace nejsou poslané z originálního serveru. 204 No Content Dotaz byl akceptován a v pořádku obsloužen, nevznikla však žádná data, která by server klientovi poslal. 206 Reset Content Server obsloužil požadavek a klient má nastavit původní obsah dokumentu, který předpokládá vložení uživ. dat. 3xx - přesměrování - Klient musí provést další akce, aby získal požadovaný dokument. 300 Multiple Choices Požadovaný dokument je dostupný na několika místech, klient musí vybrat jeden z dokumentů a znovu vyslat dotaz. 301 Moved Permanently Objekt byl trvale přestěhován na nové URL (server je oznámí v hlavičce Location). Klient se musí zeptat na novém místě. 302 Moved Temporarily Objekt byl dočasně přesunut jinam. Klient se musí obrátit na nové místo, neměl by si však například přepisovat URL objektu ve svých záložkách, protože přemístění je jen dočasné. 303 See Other Odpověď je dostupná na jiném URL. Není však náhradou za URL původní. 304 Not Modified Server odpoví tímto kódem, pokud klient poslal podmíněný dotaz GET na dokument, který má uložený v cache a odpovídající dokument na originálním serveru nebyl modifikován. 305 Use Proxy Požadavek musí být znovu poslám prostřednictvím proxy uvedené v URL. 4xx - klientova chyba - Klient položil chybný dotaz nebo nemá oprávnění získat dokument požadovaný v dotazu. 400 Bad Request Chybná syntax dotazu. 401 Unauthorized Obsloužení dotazu je vázáno na určité identifikační požadavky, které klient nesplnil. 402 Payment Required Tento kód je rezervován pro budoucí použití. 403 Forbidden Server má od správce zakázáno odpovídat na dotaz. 404 Not Found Objekt s požadovaným URL neexistuje. Tento chybový kód je nejčastější. Příčinou může být buď překlep v URL nebo zánik objektu. 405 Method Not Allowed Použitá metoda není pro uvedené URL povolena. 5xx - chyba serveru - Server není z nějakého důvodu schopen obsloužit požadavek. 500 Internal Server Error Během zpracování dotazu došlo v programu serveru k jakési blíže neurčené chybě. 501 Not Implemented Server nepoznal metodu, kterou je poslán požadavek. 502 Bad Gateway Chybu 502 pošle zprostředkující server, pokud na váš dotaz dostal od původního serveru špatnou odpověď. 503 Service Unavailable Server momentálně nedokáže váš dotaz obsloužit - například je přetížen nebo právě probíhá jeho údržba. Chyba je dočasná a pokud později svůj dotaz zopakujete, máte šanci, že budete vyslyšeni. 504 Gateway Timeout Server pracující s proxy nebo gateway nedostal včas odpověď, aby mohl vyřídit váš požadavek. 505 HTTP Version Not Supported Server nepodporuje verzi protokolu použitou v požadavku. Hlavičky HTTP Hlavičky HTTP protokolu mají tvar podobný hlavičkám elektronické pošty: název hlavičky: hodnota[;parametr=hodnota] CRLF Každá hlavička tedy začíná na samostatném řádku. Parametry jsou nepovinné, používají se jen u některých hlaviček. Příklad hlaviček: Content-length: 1032 Content-type: text/html; charset=ISO-8859-1 Hlavičky jsou rozděleny do tří skupin. Obecné hlavičky poskytující univerzální informace o zprávě. Hlavičky dotazu/odpovědi, které popisují dotaz/odpověď. Hlavičky těla,které popisují tělo zprávy. Na pořadí hlaviček nezáleží, nicméně ve standardu se doporučuje, aby hlavičky zprávy byly uspořádány podle svých tematických kategorií v uvedeném pořadí. Obecné hlavičky Date informuje o okamžiku vytvoření zprávy. Doporučuje se používat pro zápis času formát, definovaný v RFC 822: Sun, 06 Nov 1994 08:49:37 GMT Pragma umožňuje přidávat ke zprávě instrukce, jejichž zpracování je implementačně závislé. Například zmíněné Pragma: no-cache zakazuje umístit zprávu ve vyrovnávací paměti. HTTP 1.1 nahrazuje tuto hlavičku hlavičkou Cache-Control. Mime-Version hlavička specifikuje použitou verzi MIME při konstrukci zprávy. HTTP 1.1 přídává další hlavičky: Connection umožňuje odesilateli specifikovat podmínky spojení. Například Connection: close umožňuje vyslat signál, že spojení bude po vyřízení požadavku ukončeno. HTTP 1.1 aplikace, které nepodporují trvalé spojení musí vložit tuto hlavičku do každé zprávy. Transfer-Encoding definuje použitou transformaci (pokud je použitá) pro zajištění bezpečného přenosu. Transformace se používá na celé tělo zprávy. Tělo zprávy se např. rozdělí na několik částí, každou se svými hlavičkami. To umožňuje postupně posílat dynamicky vznikající odpověď. Via hlavička je seznamem protokolů a uzlů,přes které projde dotaz od originálního klienta k originálnímu serveru. Používá jí proxy a gateway. Je analogií hlavičky Received v elektronické poště. Hlavičky dotazu Authorization slouží pro autentizaci uživatele. From elektronická adresa uživatele, řídícího činnost klienta. Lze ji použít například pro zaznamenávání transakcí. If-Modified-Since se používá především pro aktualizaci obsahu vyrovnávací paměti. Je-li přítomna tato hlavička, je dotaz považován za podmíněný. Hodnotou hlavičky je časový údaj a dotaz znamená "dokument mne zajímá jen pokud se změnil od tohoto okamžiku". Jestliže v dokumentu není nic nového, server odpoví 304 Not Modified. V takovém případě lze použít verzi z vyrovnávací paměti. Došlo-li ke změně dokumentu, chová se server stejně, jako při normálním nepodmíněném dotazu. Referer oznamuje URL zdroje, ze kterého pochází URL právě kladeného dotazu. Pokud například ze stránky http://www.kdesi.cz/home.html uživatel vybere značku <A HREF="top.html">, vznikne dotaz GET http://www.kdesi.cz/top.html HTTP/1.0 Referer: http://www.kdesi.cz/home.html Tato informace může být užitečná například při chybných odkazech. Jestliže se změnilo URL některého dokumentu, můžete díky hlavičce Referer identifikovat stránky, které se odkazují na původní (nyní již neplatné) URL. pirátství (viz strana odkaz). User-Agent umožňuje klientovi představit se. Příklad: User-Agent: Mozilla/2.0b3 (X11; I; Linux 1.2.11 i586) Dotaz byl vznesen klientem Netscape verze 2.0 beta 3. Jak vidíte, Netscape podal také informace o operačním systému, ve kterém pracuje. HTTP 1.1 přidává další hlavičky: Accept specifikuje požadovaný typ dat v odpovedi, případně preference formátů. Hvězdička se použije pro skupinu např. image/* pro libovolný formát obrázku. Hlavička může obsahovat parametr q=n, kde n je číslo od 0 do 1. Parametr q určuje preferenci typů, menší číslo znamená vyšší preferenci. Implicitní hodnota q je1. Např: Accept: text/html; q=0.3, text/plain; q=0.7, text/x-dvi znamená servře máš-li pošli mi odpověď ve formátu text/html, nemáš-li pak ve formátu text/plain a pokud nemáš ani ten pošli alespoň formát text/x=dvi. Host uvádí jmého serveru a případně port, na který je směrován požadavek. Např: Host: info.pvt.net:8087 Accept-Charset specikuje, která znaková sada je pro klienta přijatelná v odpovědi. V hlavičce se uvádí znakové sady s případnou preferencí obdobně jako v hlavičce Accept. Např: Accept-Charset: iso-8859-2, iso-8859-1;q=0.8 Accept-Encoding specifikuje kódování přijatelné klientem. Kódování v tomto případě znamená např. kompresi. Např: Accept-Encoding: gzip Hlavičky odpovědi Location správné umístění odpovědi. Tvoří doplněk kódů ze skupiny 3xx, oznamujících přemístění dokumentu. Např: HTTP/1.1 301 Moved Permanently Location: http://www.abc.cz/text.html Server identifikuje programové vybavení serveru. Pokud klient zjistí, že server používá "ten pravý" program, může pak požadovat nějaké nestandardní služby. WWW-Authenticate stanoví způsob prověrky oprávnění pro daný cíl. Tato hlavička je povinným doplňkem návratového kódu 401 Unauthorized. HTTP 1.1 přidává další hlavičky: Retry-After používá se spolu s odpovědí 503 (service Unavailable) a říká jak dlouho asi bude server nedostupný. Čas se uvádí v počtu sekund nebo ve formátu definovaném RFC 822. Hlavičky těla Allow seznam metod, které lze použít pro získání dokumentu - např. Allow: GET, HEAD Expires čili "spotřebujte do". Hodnotou této hlavičky je časový údaj, udávající okamžik vypršení platnosti dokumentu. Po jeho uplynutí je dokument považován za neplatný a je zakázáno ukládat jej do vyrovnávacích pamětí. Last-Modified okamžik poslední změny v datech. Content-Encoding je jednou z hlaviček, převzatých od poštovního MIME standardu. Oznamuje, jakým způsobem je kódováno tělo dokumentu. Hodnotou je název některého z MIME kódování, řekněme Content-Encoding: x-gzip Content-Length udává délku těla v bajtech (přesněji oktetech). Content-Length: 5216 Content-Type určuje formát posílaných dat. Tato hlavička by neměla v odpovědi chybět, neboť podle ní se klient rozhoduje, jak obdržený dokument uživatelovi zobrazit či nezobrazit a raději uložit na disk. Hodnotou je MIME dvojice typ/podtyp. Některé typy jsou blíže specifikované pomocí parametrů. Hlavička má tvar: Content-Type: typ/podtyp[;parametr=hodnota;...] Nejdůležitějším parametrem (u českých textů) je Charset - specifikace znakové sady. Klientský program by měl použít tuto informaci k výběru správné znakové sady nebo překódování dokumentu. Výsledkem by měl být čitelný dokument. Příklad: Content-Type: text/html;Charset=iso-8859-1 HTTP 1.1 přidává další hlavičky: Content-Range posílá se s jednotlivými částmi odpovědi, pokud je tato rozdělena do částí. Určuje kam patří dotyčná část a velikost celé odpovědi. Např: Content-Range: 0-499/1234 pro první 500 bytů odpovědi, které je dlouhá 1234 bytů. Přístup podle autentizace HTTP protokol zavádí mechanismus prokazování totožnosti. Server při použití tohoto mechanismu odešle data jen oprávněným žadatelů, kteří se prokáží správným jménem a heslem. Takto chráněný přístup lze definovat k celému serveru nebo jeho částem (adresářům). S každou částí je spojená databáze oprávněných uživatelů. Používá se jednoduché autentizační schéma Basic. Jméno a heslo posílá klient v hlavičce Authorization. Příklad komunikace klienta a serveru při přístupu do chráněné oblasti (v příkladu uvádím pro přehlednost jen hlavičky týkající se autentizace): Klient vyšle běžný požadavek: GET /soukrome/text.html HTTP/1.1 Server vrátí odpověď: HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="tajne" Klient zobrazí uživatelovi dialogové okno pro zadání jména a hesla. Dialogové okno obsahuje i název oblasti (realm) z hlavicky v našem příkladu řetězec tajne. Po zadání jména ahesla opakuje klient původní dotaz, do kterého přidá hlavičku Authorization. Jméno a heslo se kóduje standardním base64 algoritmem. GET /soukrome/text.html HTTP/1.1 Authorization: Basic QWxhZGRpbjGVuIH== Pokud je jméno a heslo správné vrátí server odpověď HTTP/1.1 200 OK Použitý autentizační mechanismus je velmi jednoduchý a z hlediska bezpečnosti nedostatečný. Nezabývá se vůbec bezpečností cesty mezi klientem a serverem. Navíc algoritmus base64 je znám. Podaříli-li se tedy odchytit na některém z routerů nebo proxy uzlů autorizační řetězec, je možné ho bez problémů rozluštit.