Protokol HTTP Ondřej Dolejš 17.5.2007
Úvod HTTP – Hypertext transport protocol, jak už z názvu vyplývá, původně sloužil k přenosu Hypertextových dokumentů. Dnes však již pomocí rozšíření MIME může přenášet jakékoliv soubory. Využívá spolehlivý protokol TCP transportní vrstvy na portu 80, bezpečnější verze HTTPS pak na portu 443. O úspěchu protokolu HTTP svědčí i to, že má na svědomí 75% provozu na páteřních sítích. Jedná se o bezestavový protokol, a tak není možnost jakkoliv rozeznat souvislost mezi dvěma požadavky, což může být někdy nepříjemné. Jak z toho ven se dozvíme za okamžik.
Verze HTTP 0.9 - První verze HTTP z roku 1991 – 0.9 je dnes k vidění jen vzácně a je deprecated díky vážným nedostatkům. Měla jedinou metodu GET, nepodporovala MIME určení obsahu, určení verze HTTP ani headery. 1.0 - První, dodnes hojně rozšířenou revizí je verze 1.0, která zavedla verze HTTP, další metody, headery a práci s multimediálním obsahem. 1.1 - Aktuální verzí protokolu je HTTP 1.1, který přináší persistentní spojení (čímž šetří traffic a zpoždění o handshaky), metodu OPTIONS, možnost požadovat jen části dokumentu a mnoho dalších vylepšení
HTTPS HTTPS je nadstavba protokolu HTTP, která poskytuje zvýšenou bezpečnost před odposlechem a podvrhy dat. Není to přímo zvláštní protokol, ale data jsou pomocí protokolu přenášena ne jako plaintext, ale zašifrována pomocí SSL nebo TLS. HTTPS komunikuje na portu 443. Bezpečnost HTTPS závisí na implementaci jak na serveru tak na klientovi
HTTP – Jak to funguje Komunikace mezi serverem a klientem probíhá pomocí textových zpráv systémem požadavek-odpověď. Textová forma není zcela vhodná na parsování, ale čitelnost člověkem je daleko větší výhodou. Zpráva se skládá ze tří částí – Úvodní řádky, hlavičky a těla zprávy. <Úvodní řádka> U požadavku: <metoda>
U odpovědi: <status> <jméno>: [CRLF] <prázdná řádka> Na úvodní řádce požadavku je uvedena metoda následovaná URL a zakončená verzí protokolu. Metoda je vlastně co má server udělat – jde o jedno slovo, jako například GET. K
metodám se ještě dostaneme. URL je cesta k požadovaným datům a verze HTTP je verze protokolu, kterou používáme. Na úvodní řádce odpovědi pak najdeme verzi HTTP následovanou statusem a krátkým textovým popisem statusu. Status je tříciferný kód popisující, co se během požadavku stalo. Ke kódům se ještě dostaneme. Text statusu je krátký textový popis – je však určen jen pro lidské účely, parser se podle něj nerozhoduje. Další částí jsou hlavičky ukončené prázdnou řádkou, kde najdeme rozšiřující popis požadavku či odpovědi. Hlaviček může být 0 – n. Tělo zprávy je nepovinné (a má smysl jen u některých metod) a nese samotná data ať už v textové či binární formě.
Příklad http požadavku odpovědi GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Gecko/20040803 Firefox/0.9.3 Accept-Charset: UTF-8,*
HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Content-Length: 438 Content-Type: text/html; charset=UTF-8 ...
Metody HTTP HTTP definuje 8 metod:
GET HEAD POST OPTIONS PUT DELETE TRACE CONNECT
, což ovšem není úplný výčet, jelikož se během času ustálily i další, ve specifikaci neuvedené. Ne všechny metody musí být nutně na serveru implementovány – aby server vyhověl HTTP 1.1, musí implementovat alespoň metody GET a HEAD. Modrým metodám se říká bezpečné, to znamená, že na serveru se v důsledku požadavku nic nezmění.
Metoda GET Nejběžnější metodou HTTP je GET, která vrací požadovaný objekt.
Metoda HEAD Obdobou GET je metoda HEAD, která však nevrací žádná data, ale pouze hlavičku. Lze tak zjistit informace o souboru, jestli vůbec existuje případně kdy byl změněn.
Metoda POST Metoda POST slouží k odesílání uživatelských dat na server – obvykle z formulářů. S vrácenými daty se zachází obdobně jako při metodě GET.
Metoda OPTIONS Metodou OPTIONS se můžeme zeptat serveru, jaké metody podporuje. Vzhledem k tomu, že na různých prostředcích může poskytovat různé metody, lze se ptát buď obecně (*) nebo na konkrétní prostředek.
Metoda PUT Metoda PUT slouží pro uložení dat na serveru. Používá se zřídka, místo toho se používá FTP nebo SCP.
Metoda DELETE Metoda DELETE dělá přesně to co byste čekali – smaže objekt ze serveru. Pochopitelně jsou na to většinou potřeba nějaká oprávnění…
Metoda TRACE Požadavek po cestě od klienta k serveru prochází množstvím proxy, firewallů a bran - metoda TRACE slouží k vyzkoušení, přes jaké prostředníky požadavek putuje a jaké změny se ve zprávě po cestě staly. Klient vyšle zprávu k serveru a každá proxy k ní přidá svoji identifikaci. Server pak jen vloží přijatou zprávu do těla odpovědi a odešle zprávu zpět. Problém je v předpokladu, že se prostředníci chovají ke zprávám s různými metodami stejně, což zdaleka nemusí být pravda. A tak ve skutečnosti zjistíme jen jak se cesta k serveru chová k metodě TRACE s nadějí, že tomu tak bude i pro ostatní metody.
Kódy odpovědí Kódy odpovědí mají své rozsahy podle typu události, kterou oznamují. Výhodou je, že dokážeme určit charakter odpovědi i z kódu, který neznáme. Zdaleka dnes nejsou použity všechny a počítá se s rozšiřováním s novými verzemi HTTP.
100 – 199: informační 200 – 299: úspěšné 300 – 399: přesměrování 400 – 499: chyba na straně klienta 500 – 599: chyba na straně serveru
1xx 100 Continue Kód 100 slouží pro případy, kdy klient nechce posílat samotná data na server a chce se nejdřív ujistit, zda je server bude schopen přijmout. Do hlaviček zprávy tedy umístí hlavičku Expect: 100-continue a než začne posílat samotná data, čeká na zprávu od serveru 100 Continue. Servery by měly tedy neměly posílat status 100 nikomu kdo na něj už nečeká, ale u horších serverů se i to stát může.
101 Switching protocols Kód 101 oznamuje, že server přechází na jiný protokol, tak jak to požadoval v hlavičce Upgrade klient.
2xx 200 OK – Je zřejmě nejčastějším kódem a oznamuje úspěch.
201 Created – Oznamuje, že objekt na serveru byl úspěšně vytvořen. Vrací se při metodách jako PUT a v těle odpovědi najdeme URL uloženého prostředku.
202 Accepted – Říká, že server přijal požadavek, ale ještě se nedostal k jeho zpracování. V těle zprávy by se měl objevit stav požadavku.
203 Non-Authoritative Information (od HTTP/1.1) – Hlavičky nepochází z originálního serveru
204 No Content – Odpověď neobsahuje tělo – slouží k obnovení prohlížeče bez přechodu na novou stránku.
205 Reset Content – Říká prohlížeči, aby resetoval formulář.
206 Partial Content – Říká, že požadavek na část objektu byl úspěšný. Tělo pak obsahuje požadovanou část.
3xx 300 Multiple Choices – Vrací se v případě, že dané URL odpovídá více prostředků – například pokud server hostuje více jazykových verzí. V těle je pak seznam možností
301 Moved Permanently – Požadovaný prostředek byl trvale přesunut – v headeru zprávy Location je uvedena nová adresa
302 Found – Podobné jako 301 s tím rozdílem, že novou URL by měl klient použít jen dočasně a pro další požadavky opět použít starou. Hezký příklad ovlivnění standardu praxí – oblíbené
vyhledávače totiž kód 302 implementovali jako 303 – See Other, a tak HTTP 1.1 zavedlo nové kódy 303 a 307 pro jejich rozlišení.
303 See Other (od HTTP/1.1) – Odpověď na požadavek je k nalezení na jiné adrese.
304 Not Modified – Vrátí se, pokud byl v požadavku uveden header If-modified-since a prostředek změněn nebyl.
305Use Proxy (since HTTP/1.1) – Říká, že pro přístup k prostředku je třeba použít proxy, jejíž umístění je v headeru location. Explorer a Mozilla zpracovávají tento kód chybně.
306 Switch proxy – Už se nepoužívá.
307 Temporary Redirect (since HTTP/1.1) – To samé jako 302 (lépe řečeno jak mělo být implementováno 302).
4xx 400 Bad Request – Říká klientovi, že poslal špatně zformovaný požadavek.
401 Unauthorized – Klient se musí autorizovat – úroveň a zóna do které se musí autorizovat jsou v headeru WWW-autenticate.
402 Payment Required – Momentálně se nepoužívá, kód byl zamýšlen pro systémy plateb přes internet.
403 Forbidden – Požadavek byl serverem odmítnut. V těle zprávy může být důvod, ale většinou servery tento kód používají právě když důvod sdělit nechtějí.
404 Not Found – Objekt nebyl nalezen – často je v těle zprávy obsah, který se má zobrazit uživateli.
405 Method Not Allowed – Metoda není na požadovaném prostředku povolena – v headeru Allowed by měl být seznam povolených metod.
406 Not Acceptable – Objekt nesplňuje požadavky na typ dokumentu uvedené v hlavičkách požadavku.
407 Proxy Authentication Required – Proxy vyžaduje autorizaci.
408 Request Timeout – Pokud klient nedokončí svůj požadavek ve stanovené době.
409 Conflict – Indikuje hrozící konflikt na požadovaném prostředku.
410 Gone – Stejné jako kód 404 s tím rozdílem, že server kdysi prostředek měl.
411 Length Required – Pokud schází a je vyžadován header Content-Length.
412 Precondition Failed – Pokud nejsou splněny podmínky z hlaviček.
413 Request Entity Too Large – Odesílaná entita je příliš velká.
414 Request-URI Too Long – Požadované URI je příliš dlouhé.
415 Unsupported Media Type – Typ dat není podporován.
416 Requested Range Not Satisfiable – Požadavek na rozsah v objektu nelze uspokojit.
417 Expectation Failed – Nemohla být splněna podmínka v hlavičce Expect.
5xx 500 Internal Server Error – Požadavek nemohl být splněn kvůli vnitřní chybě serveru.
501 Not Implemented – Část serveru potřebná ke splnění požadavku není implementována.
502 Bad Gateway – Pokud gateway nebo proxy dostane od dalšího uzlu na cestě k serveru chybnou zprávu.
503 Service Unavailable – Server momentálně není scopen požadavek vyřídit, ale někdy v budoucnosti bude. Pokud ví kdy, může to v headeru Retry-After specifikovat.
504 Gateway Timeout – Podobné jako 408, jen ne pro server, ale pro proxy.
505 HTTP Version Not Supported – Verze protokolu není serverem podporována.
Jak se vyrovnat s bezestavovostí http? HTTP je bezestavový protokol – mezi dvěma požadavky tedy server nevidí žádnou souvislost. Z různých důvodů můžeme potřebovat uchovávat o uživateli procházejícím stránky informace (například internetový obchod, …). Protokol HTTP nám k tomu prostředky nenabízí, a tak máme následující možnosti: Jednak můžeme informace o spojení ukládat u uživatele pomocí cookies (ty však nemusí být vždy k dispozici), druhak mít informace ve skrytých formulářových prvcích na stránce a nebo informace ukládat do URL.
Cookies HTTP cookies jsou drobné soubory uložené na klientovi sloužící k uchovávání informací o uživateli – řeší problém bezestavového protokolu HTTP. Soubory mohou mít maximálně 4Kb (v MSIE 4Kb na všechny cookies z jedné domény) a jejich počet na doménu je v jednotlivých prohlížečích omezen: MSIE: 20 Opera: 30 Firefox: 50 Nedostatkem cookies je, že vážně pronikají do soukromí – jde o to že cookies může ukládat nejen server, kde je uložená námi chtěná stránka, ale i servery třetích stran, kde jsou uložené některé části načítané stránky. Speciálně například reklamní společnosti, které pak mohou přes více domén sledovat uživatele a vytvářet si jeho profil. Dalším nedostatkem je nepřesná identifikace, protože každý browser má své úložiště cookies, nehledě na jednoho uživatele pracujícího na více počítačích, takže cookie nakonec neidentifikuje uživatele, ale kombinaci uživatele, počítače a browseru.
Cookies – příklad GET /index.html HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value
… GET /something.html HTTP/1.1 Host: www.example.com Cookie: name=value Accept: */*
HTTP autorizace HTTP Autorizace má dva stupně – základní a „digest“. Při základní autorizaci server na požadavek nejdřív vrátí 401 a v headeru WWWAuthenticate, browser otevře popup okno, uživatel vyplní jméno a heslo, to se, oddělené dvojtečkou překóduje kódováním base-64 a odešle na server v hlavičce Authorization. Server pak vrátí příslušná data. (Kódování base 64 převádí text na znaky ze speciální 64 znakové abecedy, ve které jsou znaky, které v hlavičce HTTP zprávy nevadí – vlastně jen bere místo 8 bitů 6 a dělá z nich znaky) Základní autorizace má spoustu nedostatků: hlavním je posílání loginu a hesla prakticky v plaintextu. Informace sice jsou zakódovány pomocí base-64, ale to se dá dekódovat rychle i pomocí tužky a papíru, takže může sloužit pouze administrátorům, aby heslo neviděli omylem. Heslo je tak k dispozici komukoliv po cestě serveru. I kdybychom však tvrdili, že nám to nevadí je to nebezpečné – lidé si neuvědomují nebezpečí slabé autorizace a pokud budou mít heslo na víc míst stejné (běžná praktika), způsobíme průlom do cizího systému. Základní autorizace je tedy použitelná pouze tam, kde soukromí není nezbytné. Digest autorizace funguje podobně jako základní s tím rozdílem, že neposílá heslo, ale jen jeho MD5 hash, tudíž nejde zpětně zrekonstruovat, a k heslu je navíc před spočítáním MD5 připojen timestamp ze serveru, čímž se zabrání útoku opakováním.
Odesílání formuláře 1. Identifikace „úspěšných prvků“ o Disabled prvky nejsou úspěšné o Pouze stisknuté submit tlačítko je úspěšné (pokud je jich víc) o Nezaškrtnuté checkboxy nejsou úspěšné o U radiobuttonů se stejným názvem je úspěšný pouze ten zvolený o Pouze zvolené prvky OPTION jsou úspěšné a pouze prvky SELECT s nějakými zvolenými OPTION jsou úspěšné 2. Vytvoření množiny dat o Z úspěšných prvků: název/hodnota 3. Zakódování množiny dat o podle atributu enctype prvku form o V HTTP zprávě bude kódování uvedeno v MIME hlavičce Content-Type 4. Odeslání pomocí zadané metody na server o GET či POST
Zdroje -
Wikipedie O’Reily - HTTP The Definitive Guide
