Hypertext Transfer Protocol

HTTP (Hypertext Transfer Protocol) je [url= 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í [[Multipurpose Internet Mail Extensions|MIME]url= neumožňuje šifrování ani zabezpečení integrity dat. +more Pro zabezpečení[/url]url= se často používá [[Transport Layer Security|TLS][internet]]ový 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[/url]] 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[/url]] 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 [url= říká bezestavový protokol - protokol neumí uchovávat stav komunikace, dotazy spolu nemají souvislost. +more Tato vlastnost je nepříjemná pro implementaci složitějších procesů přes[/url]url= (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[/url]url= rozšířen o tzv. [[HTTP cookie][Webový prohlížeč|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ěď. +more Z hlediska serveru nelze poznat, jestli tento druhý dotaz jakkoli souvisí s předchozím. Kvůli této vlastnosti se protokolu[/url]]s, 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. +moreorg, sděluje svou totožnost ([url=/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.

První řádek odpovědi je stavový řádek obsahující verzi protokolu a informaci, zda byl dotaz úspěšný ve stylu [[File Transfer Protocol|FTP][Opera (webový prohlížeč)|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í:

[/url]] („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.

Verze HTTP

Nejstarší verze protokolu HTTP byla zpětně označena číslem verze 0.9 a její popis z roku [url=/1.0.

První popisy protokolu[/url]url=/1. 0 byly publikovány již v roce 1992, definitivní standard byl vydán v květnu [[1996]url= hlavičky v požadavku i odpovědi, nové metody HEAD a POST, a pro rozlišení typu dokumentů používá [[Multipurpose Internet Mail Extensions|MIME]url=/1. +more2, ale v praxi se zřejmě nepoužívá.

[[url=HTTP/2]url=, v září roku 2018 překročil 30 %., podíl na provozu stoupá a je zatím v řádu jednotek procent.

[[HTTP/3][1991]] lze nalézt na webu w3. org. +more 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[/url]] jako RFC 1945. Protokol zavádí stavový řádek v odpovědi,[/url]].

HTTP/1. 1 bylo původně popsáno v RFC 2068 (leden 1997), v červnu 1999 nahrazeno RFC 2616. +more 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, nebo RFC 2774), které bylo jeden čas označováno jako[/url]]]je verze protokolu přijatá 14. května 2015 jako [[rfc:7540|RFC 7540[/url]]. +more Podíl serverů, které jsou schopny komunikovat touto verzí[/url]] je nově vyvíjená verze protokolu, označovaná také „HTTP over QUIC“, která byla publikována jako Internet draft dne 24. října 2018.

Dotazovací metody

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

GET : Požadavek na uvedený objekt se zasláním případných dat (proměnné prohlížeče, [url= požadavku). PUT : Nahraje data na server. +more 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][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[/url]] 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: 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. +more 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. +more 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 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: "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.

Nedodržení účelu metod

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. +more 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.

Zabezpečené HTTP

Existují dvě metody zabezpečeného http připojení: [url= 1. 1 představená v [[RFC 2817][url=HTTPS]]][[Uniform Resource Identifier|URI[/url]] a nadstavba[/url]]. +more 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 [url=, protože dokáže poskytnout ochranu přenosu, i když je pouze jedna strana komunikace ověřená. Typicky je ověřen pouze server (např. +more uživatel potvrdí certifikát). Aby pomocí[/url]url= bylo možné rozlišovat virtuální servery, existuje rozšíření [[Server Name Indication|SNI][Secure Sockets Layer|SSL]]/TLS k přenosu dat. SSL je vhodné pro[/url]].

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 [url=/1.1 Host: www.example.com

Server:

[/url]url=/1.1 426 Upgrade Required Upgrade: TLS/1.0,[/url]url=/1.1 Connection: Upgrade

Server vrátí kód 426, protože kódy začínající čtyřkou značí selhání klienta (viz [url=http://www. w3. +moreorg/Protocols/rfc2616/rfc2616-sec10. html]url= status kódů[/url]url= přenos nemůže být specifikován v [[Uniform Resource Identifier|URI][Transport Layer Security|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[/url]seznam[/url])

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ý[/url]]. 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.

Odkazy

Reference

Související články

[url= protokolu * [[Stavové kódy HTTP][Basic access authentication]] - jednoduchá autentizace v rámci[/url]] * HTTP/2 * HTTP/3

Externí odkazy

Kategorie:Aplikační protokoly IP Kategorie:Standardy W3C Kategorie:Otevřené standardy