Hypertext Transfer Protocol

HTTP (Hypertext Transfer Protocol) je internetový protokol určený pro výměnu hypertextových dokumentů ve formátu HTML. Používá obvykle port TCP/80, verze 1.1 protokolu je definována v RFC 2616. Společně s elektronickou poštou je HTTP nejvíce používaným protokolem, který se zasloužil o obrovský rozmach internetu v posledních letech.

V současné době je používán i pro přenos dalších informací. Pomocí rozšíření MIME umí přenášet jakýkoli soubor (podobně jako e-mail), používá se společně s formátem XML pro tzv. webové služby (spouštění vzdálených aplikací) a pomocí aplikačních bran zpřístupňuje i další protokoly, jako je např. FTP nebo SMTP.

HTTP používá jako některé další aplikace tzv. jednotný lokátor prostředků (URL, Uniform Resource Locator), který specifikuje jednoznačné umístění nějakého zdroje v Internetu.

Samotný protokol HTTP neumožňuje šifrování ani zabezpečení integrity dat. Pro zabezpečení HTTP se často používá TLS spojení nad TCP. Toto použití je označováno jako HTTPS.

Činnost protokolu

Protokol funguje způsobem dotaz-odpověď. Uživatel (pomocí programu, obvykle internetového prohlížeče) pošle serveru dotaz ve formě čistého textu, obsahujícího označení požadovaného dokumentu, informace o schopnostech prohlížeče apod. Server poté odpoví pomocí několika řádků textu popisujících výsledek dotazu (zda se dokument podařilo najít, jakého typu dokument je atd.), za kterými následují data samotného požadovaného dokumentu.

Pokud uživatel bude mít po chvíli další dotaz na stejný server (např. proto, že uživatel v dokumentu kliknul na hypertextový odkaz), bude se jednat o další, nezávislý dotaz a odpověď. Z hlediska serveru nelze poznat, jestli tento druhý dotaz jakkoli souvisí s předchozím. Kvůli této vlastnosti se protokolu HTTP říká bezestavový protokol – protokol neumí uchovávat stav komunikace, dotazy spolu nemají souvislost. Tato vlastnost je nepříjemná pro implementaci složitějších procesů přes HTTP (např. internetový obchod potřebuje uchovávat informaci o identitě zákazníka, o obsahu jeho „nákupního košíku“ apod.). K tomuto účelu byl protokol HTTP rozšířen o tzv. HTTP cookies, které umožňují serveru uchovávat si informace o stavu spojení na počítači uživatele.

Ukázka komunikace

Uživatelský program (klient) se připojí na server cs.wikipedia.org a zašle následující dotaz:

GET /wiki/Wikipedie HTTP/1.1
Host: cs.wikipedia.org
User-Agent: Opera/9.80 (Windows NT 5.1; U; cs) Presto/2.5.29 Version/10.60
Accept-Charset: UTF-8,*

Tímto dotazem žádá o dokument /wiki/Wikipedie na serveru cs.wikipedia.org, sděluje svou totožnost (Opera verze 10.60) a oznamuje, že podporuje kódování UTF-8 (ve skutečném dotazu je podobných informací ještě více, toto je zjednodušený příklad).

Server pak odpoví:

HTTP/1.0 200 OK
Date: Fri, 15 Oct 2004 08:20:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.8
X-Powered-By: PHP/4.3.8
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: cs
Content-Type: text/html; charset=utf-8

Za touto hlavičkou následuje jeden prázdný řádek (označující její konec) a pak požadovaný HTML dokument. Hlavička obsahuje informaci o tom, že dotaz se podařil (první řádek: „200 OK“), datum a čas vyřízení dotazu, popis serveru, který odpovídá, informace o typu vráceného dokumentu (MIME typ text/html v kódování UTF-8) a další informace.

Verze HTTP

První byla publikována verze 0.9 v roce 1991 [1]. Existovala tehdy pouze metoda GET s jediným parametrem, a to názvem požadovaného dokumentu. Server jako odpověď poslal přímo požadovaný dokument bez hlavičky (HTTP/… 200 OK…) uvedené v předchozí kapitole. Jednodušší už to být nemohlo. Případná chybová hlášení vracel server také ve formě HTML dokumentu.

HTTP/1.0 je popsáno v RFC 1945 z května 1996 a přináší HTTP hlavičky, nové metody HEAD a POST, pro identifikaci typu dokumentů používá MIME.

HTTP/1.1 bylo původně popsáno v RFC 2068 (leden 1997), v červnu 1999 nahrazeno RFC 2616. Tato verze umožňuje udržovat TCP spojení (tzv. keep-alive connection), tím pádem umožňuje i zpracování více požadavků po sobě v jednom spojení. Dále přidává další metody OPTIONS, PUT, DELETE, TRACE a CONNECT.

Existuje ještě experimentální rozšíření PEP (Protocol Extension Protocol, viz [2] nebo RFC 2774), které bylo jeden čas označováno jako HTTP/1.2, ale v praxi se zřejmě nepoužívá.

Dotazovací metody

HTTP definuje několik metod, které se mají provést nad uvedeným objektem (dokumentem). <metoda> <objekt> HTTP/<verze>

GET

Požadavek na uvedený objekt se zasláním případných dat (proměnné prohlížeče, session id, …). Výchozí metoda při požadavku na zobrazení hypertextových stránek, RSS feedů aj. Celkově nejpoužívanější.

HEAD

Metoda podobná GET, avšak nepředává data. Poskytne pouze metadata o požadovaném cíli (velikost, typ, datum změny, …).

POST

Odesílá uživatelská data na server. Používá se například při odesílání formuláře na webu. S předaným objektem se pak zachází podobně jako při metodě GET. Data může odesílat i metoda GET, metoda POST se však používá pro příliš velký objem dat (víc než 512 bajtů, což je velikost požadavku GET), nebo pokud není vhodné přenášená data zobrazit jako součást URL (data předávaná metodou POST jsou obsažena v HTTP požadavku).

PUT

Nahraje data na server. Objekt je jméno vytvářeného souboru. Používá se velmi zřídka, pro nahrávání dat na server se běžně používá FTP nebo SCP/SSH.

DELETE

Smaže uvedený objekt ze serveru. K tomu je zapotřebí jistých oprávnění stejně jako u metody PUT.

TRACE

Odešle kopii obdrženého požadavku zpět odesílateli, takže klient může zjistit, co na požadavku mění nebo přidávají servery, kterými požadavek prochází.

OPTIONS

Dotaz na server, jaké podporuje metody.

CONNECT

Spojí se s uvedeným objektem přes uvedený port. Používá se při průchodu skrze proxy pro ustanovení kanálu SSL.

Bezpečné metody

Některé metody (například, HEAD, GET,OPTIONS a TRACE) jsou definovány jako bezpečné, což znamená, že jsou určeny pouze k získávání informací a neměly by změnit stav serveru. Jinými slovy, neměly by mít vedlejší účinky, mimo relativně neškodných účinků, jako je protokolování, ukládání do vyrovnávací paměti, které slouží pro bannerové reklamy, případně zvyšování web counter. Tvorba libovolných GET požadavků bez ohledu na souvislost aplikace může být proto považována za bezpečnou.

Naproti tomu metody jako POST, PUT a DELETE jsou určeny pro akce, které mohou způsobovat nežádoucí účinky třeba na serveru. Tyto metody jsou proto obvykle používány v souladu webových robotů nebo webového prohledávače, některé, které neodpovídají, obvykle podávají žádosti bez ohledu na kontext nebo důsledky.

Navzdory stanovené bezpečnosti GET požadavků, v praxi jejich zpracování na serveru není technicky omezeno žádným způsobem. Proto může neopatrným nebo záměrným programováním způsobit netriviální změny na server. Toto se nedoporučuje, protože to může způsobit problémy pro webovou mezipamět, vyhledávačům a jiným automatickým prostředkům, které můžou způsobovat nežádoucí změny na serveru.

Kromě toho jsou metody, jako TRACE, TRACK a DEBUG považovány za potenciálně "nebezpečné" některými profesionály v oblasti bezpečnosti, protože mohou být použity útočníky k získání informací, nebo k obejítí bezpečnostní kontroly při útocích. Bezpečnostní softwarové nástroje, jako je Tenable Nessus a Microsoft URLScan informují o přítomnosti těchto metod jako bezpečnostních problémech.

Idempotentní metody

Metody PUT a DELETE jsou definovány jako idempotentní, což znamená, že více totožných požadavků by mělo mít stejný účinek jako jeden požadavek. Metody GET, HEAD, OPTIONS a TRACE, jsou předepsány jako bezpečné, a měly by být rovněž idempotentní.

Oproti tomu POST metoda nemusí být nutně idempotentní, a proto se zasláním shodného POST požadavku vícekrát, může navíc ovlivňovat stav nebo způsobit další nežádoucí účinky.

V některých případech to může být vhodné, ale v jiných případech by to mohl být důvod problémů, například když si uživatel neuvědomí, že jeho činnost bude mít za následek odeslání další žádosti, potom nedostane přiměřenou odpověď, že jeho první žádost byla úspěšná. I když webové prohlížeče mohou zobrazovat upozornění v dialogových oknech a tím tak varovat uživatele, v některých případech třeba aktualizování stránky se provede další odeslání shodného požadavku a to způsobí problém.

Všimněte si, že jestli je metoda idempotentní není uplatňována podle protokolu nebo webového serveru. Je zcela možné psát webové aplikace, ve které (například) je databáze, INSERT nebo jiné neidempotentní akce spouštěné GET nebo jinou žádostí. Ignorováním tohoto doporučení však může dojít k nežádoucím následkům, pokud uživatel předpokládá, že opakování stejného požadavku je bezpečné. Ale ono není. Poté dojde k nesprávnému zpracování.

Zabezpečené HTTP

Existují dvě metody zabezpečeného http připojení: HTTPS URI a nadstavba HTTP 1.1 představená v RFC 2817. Druhou metodu ovšem zatím prohlížeče moc nepodporují, takže HTTPS se k vytvoření zabezpečené komunikace používá nejčastěji.

HTTPS URI

Je syntakticky identické jako http, pouze přidává signalizaci prohlížeči, aby použil šifrovací metodu SSL/TLS k přenosu dat. SSL je vhodné pro HTTP, protože dokáže poskytnout ochranu přenosu, i když je pouze jedna strana komunikace ověřená. Typicky je ověřen pouze server (např. uživatel potvrdí certifikát). Aby pomocí HTTPS bylo možné rozlišovat virtuální servery, existuje rozšíření SNI.

HTTP 1.1 Aktualizovaná hlavička

HTTP 1.1 představilo podporu pro aktualizaci hlavičky. Klient začíná komunikaci prostým textem, který je později nahrazen TLS. Buď server nebo klient mohou vyžadovat (na požádání), aby byla komunikace převedena na zabezpečenou. Nejběžněji klient začíná prostým textem a to je následováno požadavkem serveru na převod na zabezpečenou komunikaci. Vypadá to následovně:

Klient:

GET /encrypted-area HTTP/1.1
Host: www.example.com

Server:

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

Server vrátí kód 426, protože kódy začínající čtyřkou značí selhání klienta (viz seznam http status kódů)

Výhody použití této metody zabezpečení spočívají v:

• odstraňuje problematické přesměrování a přepisování URL adresy na straně serveru
• umožňuje virtuální hosty (na jedné IP adrese více doménových jmen) na zabezpečených serverech

Slabina této metody je v tom, že požadavek na zabezpečený http přenos nemůže být specifikován v URI. V praxi je pak (neověřený) server zodpovědný za aktivaci zabezpečené komunikace, místo aby za ni byl odpovědný (ověřený) klient.

Související články

• Basic access authentication – jednoduchá autentizace v rámci HTTP protokolu
• Stavové kódy HTTP