Hypertext Transfer Protocol

HyperText Transfer Protocol(HTTP) jeinternetovýprotokolurčený pro komunikaci sWWWservery. Slouží pro přenoshypertextovýchdokumentů ve formátuHTML,XML, i jiných typů souborů. Používá obvykle portTCP/80, verze 1.1 protokolu je definována vRFC 2616. Společně selektronickou poštouje HTTP nejvíce používaným protokolem, který se zasloužil o obrovský rozmach internetu.
Je však používán i pro přenos dalších informací. Pomocí rozšířeníMIMEumí přenášet jakýkoli soubor (podobně jakoe-mail), používá se společně s formátemXMLpro 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ř.FTPneboSMTP.
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áTLSspojení nad TCP. Toto použití je označováno jakoHTTPS.
Protokol funguje způsobem dotaz-odpověď. Uživatel (pomocí programu, obvykleinternetového prohlížeče) pošleserverudotaz 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.
Uživatelský program (klient) se připojí na server cs.wikipedia.org a zašle následující dotaz:
Tímto dotazem žádá o dokument /wiki/Wikipedie na serveru cs.wikipedia.org, sděluje svou totožnost (Operaverze 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í:
První řádek odpovědi je stavový řádek obsahující verzi protokolu a informaci, zda byl dotaz úspěšný ve styluFTP(„200 OK“), další řádky jsou hlavičky, za nimi následuje jeden prázdný řádek (označující konec hlaviček) a požadovaný soubor. Hlavičky obsahují datum a čas vyřízení dotazu, popis serveru, informace o typu vráceného dokumentu (MIME typ text/html v kódování UTF-8) a další informace.
Nejstarší verze protokolu HTTP byla zpětně označena číslem verze 0.9 a její popis z roku1991lze nalézt na webu w3.org.Používala pouze metoduGETs jediným parametrem, a to názvem požadovaného dokumentu. Server jako odpověď vrátil přímo požadovaný dokument bez hlaviček (HTTP/… 200 OK…) uvedené v předchozí kapitole. Případná chybová hlášení vracel server také ve formě HTML dokumentu. Kvůli svým omezením byl rychle nahrazen postupně vyvíjeným protokolem HTTP/1.0.
První popisy protokolu HTTP/1.0 byly publikovány již v roce 1992, definitivní standard byl vydán v květnu1996jakoRFC 1945. Protokol zavádí stavový řádek v odpovědi, HTTP hlavičky v požadavku i odpovědi, nové metodyHEADaPOST, a pro rozlišení typu dokumentů používáMIME.
HTTP/1.1 bylo původně popsáno vRFC 2068(leden1997), v červnu1999nahrazenoRFC 2616. Tato verze umožňuje mimo jiné provozovat více WWW serverů na jedné adrese, přenos více souborů po sobě v jednom spojení a udržování TCP spojení (tzv. keep-alive connection). Dále přidává další metodyOPTIONS,PUT,DELETE,TRACEaCONNECT.
Existuje experimentální rozšíření PEP (Protocol Extension Protocol, neboRFC 2774), které bylo jeden čas označováno jako HTTP/1.2, ale v praxi se zřejmě nepoužívá.
HTTP/2je verze protokolu přijatá 14. května 2015 jakoRFC 7540. Podíl serverů, které jsou schopny komunikovat touto verzí HTTP, v září roku 2018 překročil 30 %., podíl na provozu stoupá a je zatím v řádu jednotek procent.
HTTP/3je nově vyvíjená verze protokolu, označovaná také „HTTP over QUIC“, která byla publikována jako Internet draft dne 24. října 2018.
HTTP definuje několik metod, které se mají provést nad uvedeným objektem (dokumentem).
<metoda> <objekt> HTTP/<verze>
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: Bezpečné z pohledu změny dat, tedyPouze ke čtení(read only). 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:k zápisu(write). 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 serveru. Toto se nedoporučuje, protože to může způsobit problémy pro webovou mezipaměť, vyhledávačům a jiným automatickým prostředkům, které mohou způsobovat nežádoucí změny na serveru.
Kromě toho jsou metody TRACE, TRACK a DEBUG některými profesionály v oblasti bezpečnosti považovány za potenciálně „nebezpečné“ (z pohledu útoku na server, jiný pohled), protože mohou být použity útočníky k získání informací, nebo k obejití bezpečnostní kontroly při útocích. Bezpečnostní softwarové nástroje, jako jeTenable Nessusa MicrosoftURLScaninformují o přítomnosti těchto metod jako bezpečnostních problémech.
Metody PUT a DELETE jsou definovány jakoidempotentní, což znamená, že více totožných požadavků by mělo mít stejný účinek jako jeden požadavek: „Idempotence 1“. Již zmíněné metody GET, HEAD, OPTIONS a TRACE, jsou předepsány jako bezpečné, tedy jsou idempotentní implicitně, když data vůbec nemění: „Idempotence 0“.
Oproti tomu metoda POST idempotentní být nutně nemusí: Zaslání shodného POST požadavku vícekrát může stav na serveru ovlivňovat opakovaně a způsobit tak i nežádoucí účinky.
V některých případech může být opakování stejného požadavku vhodné a žádoucí, většinou to však bývá zdroj problémů: Například když si uživatel neuvědomí, že jeho činnost bude mít za následek odeslání další žádosti na server, potom nedostane přiměřenou odpověď, že jeho první žádost byla úspěšná, typicky při zdvojeném kliknutí na tlačítko. I když webové prohlížeče mohou zobrazovat upozornění v dialogových oknech a tím uživatele varovat, v některých případech se například i pouhým aktualizováním stránky stejný požadavek odešle znovu, což už může způsobit problém.
Zda je metoda idempotentní či bezpečná není určeno protokolem ani webovým serverem. Technicky vskutku je možné psát webové aplikace s takovými vnitřními mechanismy, že například databázové operace INSERT, či jiné neidempotentní akce, budou spouštěny voláním metodou GET, či jiné HTTP metody, která běžně bývá považována za bezpečnou. Jenže ignorováním doporučení na bezpečnost/idempotentnost metod riskujeme nežádoucí následky, kdy uživatel předpokládá, že opakování stejného požadavku bezpečné je. Ale ono není, a dojde k nechtěnému zpracování.
Je tedy vhodné nejen vycházet vstříc očekáváním uživatelů, ba dokonce riziku nepochopení, nejednoznačnosti a střetu nevyjádřených předpokladů již v zárodku předcházet, a to volbou vhodné architektury a technologie, které by předcházení vůbec umožňovaly.
Existují dvě metody zabezpečeného http připojení:HTTPSURIa nadstavba HTTP 1.1 představená vRFC 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.
Je syntakticky identické jako http, pouze přidává signalizaci prohlížeči, aby použil šifrovací metoduSSL/TLSk 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 představilo podporu pro aktualizaci hlavičky. Klient začíná komunikaci prostým textem, který je později nahrazenTLS. 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:
Server:
Server vrátí kód 426, protože kódy začínající čtyřkou značí selhání klienta (vizseznam http status kódů)
Výhody použití této metody zabezpečení spočívají v:
Slabina této metody je v tom, že požadavek na zabezpečený http přenos nemůže být specifikován vURI. 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.