HTTP
HTTP (Hypertext Transfer Protocol) je internetový protokol určený pro komunikaci s WWW servery. Slouží pro přenos hypertextových dokumentů ve formátu HTML, XML, i jiných typů souborů. 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.
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.
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 (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í:
První řádek odpovědi je stavový řádek obsahující verzi protokolu a informaci, zda byl dotaz úspěšný ve stylu FTP („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 roku 1991 lze nalézt na webu w3.org [1]. Používala pouze metodu GET s 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[1], definitivní standard byl vydán v květnu 1996 jako RFC 1945. Protokol zavádí stavový řádek v odpovědi, HTTP hlavičky v požadavku i odpovědi, nové metody HEAD a POST, a pro rozlišení 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 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ší metody OPTIONS, PUT, DELETE, TRACE a CONNECT.
Existuje 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á.
HTTP/2 je verze protokolu přijatá 14. května 2015 jako RFC 7540. Podíl serverů, které jsou schopny komunikovat touto verzí HTTP, v září roku 2018 překročil 30 %.[2], podíl na provozu stoupá a je zatím v řádu jednotek procent.
HTTP/3 je 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>
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ší.
Metoda podobná GET, avšak nepředává data. Poskytne pouze metadata o požadovaném cíli (velikost, typ, datum změny, …).
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).
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.
Smaže uvedený objekt ze serveru. K tomu je zapotřebí jistých oprávnění stejně jako u metody PUT.
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í.
Dotaz na server, jaké podporuje metody.
Spojí se s uvedeným objektem přes uvedený port. Používá se při průchodu skrze proxy pro ustanovení kanálu SSL.
Na tuto kapitolu je přesměrováno heslo Bezpečná metoda.
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, tedy Pouze 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é můžou 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 je Tenable Nessus a Microsoft URLScan informují o přítomnosti těchto metod jako bezpečnostních problémech.
Na tuto kapitolu je přesměrováno heslo Idempotentní metoda.
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: "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í: 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.
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 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:
Server:
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.