Reklama: Test vrozené inteligence

HTTP protokol - požadavky a odpovědi



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: 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.

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):

  1. Klient vyšle běžný požadavek:
    GET /soukrome/text.html HTTP/1.1
    
  2. Server vrátí odpověď:
    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Basic realm="tajne"
    
  3. 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==
    
  4. 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.