Hypertextový přenosový protokol

hypertextový přenosový protokol
Rodina	Rodina internetových protokolů
Funkce	hypertextový přenos
Poslední verze	3,0 (2018)
porty	80/TCP
Umístění v zásobníku protokolů
Aplikace HTTP Přeprava TCP Síť IP
standardy
Původní HTTP (HTTP/0.9, 1991 ) RFC 1945 (HTTP/1.0, 1996 ) RFC 2616 (HTTP/1.1, 1999 ) RFC 2774 ( HTTP/1.2 [ nutná citace ] , 2000 ) RFC 721 , RFC3230 , RFC 7230 7233 , RFC 7234 , RFC 7235 (revize HTTP/1.1, 2014 ) RFC 7540 ( HTTP/2 , 2015 ) Hypertext Transfer Protocol verze 3 ( HTTP/3 , 2018 ) ( Internet Draft )

Hypertext Transfer Protocol (v angličtině Hypertext Transfer Protocol , zkráceně HTTP ) je komunikační protokol , který umožňuje přenos informací prostřednictvím souborů (XML, HTML ...) na World Wide Web . Byl vyvinut konsorciem World Wide Web Consortium a Internet Engineering Task Force , spolupráce, která vyvrcholila vydáním série RFC v roce 1999 , z nichž nejdůležitější byl RFC 2616, který specifikoval verzi 1.1. HTTP definuje syntaxi a sémantiku, kterou používají softwarové prvky webové architektury (klienti, servery, proxy ) ke komunikaci.

HTTP je bezstavový protokol , takže neukládá žádné informace o předchozích připojeních. Vývoj webových aplikací často potřebuje udržovat stav. K tomu se používají soubory cookie , což jsou informace, které může server uložit na klientském systému . To umožňuje webovým aplikacím zavést pojem relace a také umožňuje sledování uživatelů, protože soubory cookie mohou být u klienta uloženy na dobu neurčitou.

Popis

Je to transakčně orientovaný protokol a řídí se schématem požadavek-odpověď mezi klientem a serverem. Klient (často nazývaný „ uživatelský agent “ ) zadá požadavek odesláním zprávy v určitém formátu na server. Server (běžně nazývaný webový server) vám zašle zprávu s odpovědí. Příkladem klientů jsou webové prohlížeče a weboví pavouci (známí také pod anglickým termínem webcrawlers ).

Zprávy

Zprávy HTTP jsou ve formátu prostého textu , takže jsou čitelnější a snadněji se ladí. To má však nevýhodu v prodlužování zpráv. Zprávy mají následující strukturu:

• Počáteční řádek (končí návratem vozíku a posunem řádku) s
  • Pro požadavky: akce vyžadovaná serverem ( metoda požadavku ), za níž následuje URL zdroje a verze HTTP podporovaná klientem.
  • Pro odpovědi: Použitá verze HTTP následovaná kódem odpovědi (který označuje, co se stalo s požadavkem, za nímž následuje URL zdroje) a fráze spojená s uvedeným návratem.
• Záhlaví zpráv , které končí prázdným řádkem. Jsou to metadata . Tyto hlavičky poskytují protokolu velkou flexibilitu.
• Tělo zprávy. Je to volitelné. Jeho přítomnost závisí na předchozím řádku zprávy a typu zdroje, na který adresa URL odkazuje. Obvykle obsahuje data, která jsou vyměňována mezi klientem a serverem. Například požadavek může obsahovat určitá data, která chcete odeslat na server ke zpracování. Jako odpověď můžete zahrnout data, která klient požadoval.

Způsoby požadavku

HTTP požadavek pomocí telnetu . Požadavek , záhlaví odpovědi a tělo odpovědi jsou zvýrazněny.

HTTP definuje předdefinovanou sadu metod požadavků (někdy označovaných jako „slovesa“), které lze použít. Protokol má flexibilitu přidávat nové metody a tím přidávat nové funkce. Počet metod požadavků se s postupem verzí zvyšoval. Tento seznam obsahuje metody přidané pomocí WebDAV .

Každá metoda označuje akci, kterou chcete provést s identifikovaným prostředkem. Co tento prostředek představuje, závisí na serverové aplikaci. Prostředek může například odpovídat souboru, který je umístěn na serveru.

ZÍSKEJTE

Metoda GET požaduje reprezentaci zadaného zdroje. Požadavky, které používají GET, by měly pouze načítat data a neměly by mít žádný jiný účinek. (To platí také pro některé další metody HTTP.)

HLAVA

RFC 2616 . Požádá o odpověď identickou s tou, která by odpovídala požadavku GET, ale tělo se v odpovědi nevrátí. To je užitečné, abyste mohli načíst metadata z hlaviček odpovědí, aniž byste museli přenášet celý obsah.

PŘISPĚT

RFC 2616 . Odesílá data ke zpracování zdrojem uvedeným v URL řádku požadavku. Údaje budou uvedeny v těle žádosti. Na sémantické úrovni je zaměřen na vytvoření nového zdroje, jehož charakter bude specifikován hlavičkou Content-Type . Příklady:

• Pro data formuláře zakódovaná jako URL (ačkoli putují v těle požadavku, nikoli v URL): application/x-www-form-urlencoded
• Aby se bloky šplhaly, např. soubory: multipart/form-data
• Kromě výše uvedeného neexistuje žádný povinný standard a mohou to být i jiné, jako je text/plain , application/json , application/octet-stream ,...

PUT

( RFC 2616 ) Odesílá data na server, ale na rozdíl od metody POST se URI řádku požadavku neodkazuje na zdroj, který jej zpracuje, ale identifikuje samotná data (viz podrobné vysvětlení v RFC ). Dalším rozdílem oproti POST je sémantika (viz REST ): zatímco POST je orientován na vytváření nového obsahu, PUT je orientován spíše na jeho aktualizaci (i když by jej také mohl vytvořit).

Příklad:

PUT /cesta/název souboru.html HTTP/1.1

ODSTRANIT

RFC 2616 . Odstraní zadaný prostředek.

TRACE

( RFC 2616 ) Tato metoda žádá server, aby do odpovědi vložil všechna data, která obdrží ve zprávě požadavku. Používá se pro účely ladění a diagnostiky, protože klient vidí, co přichází na server, a tímto způsobem vidí vše, co zprostředkující servery přidávají do zprávy.

MOŽNOSTI

RFC 2616 . Vrátí metody HTTP, které server podporuje pro konkrétní adresu URL. To lze použít ke kontrole funkčnosti webového serveru na základě požadavku namísto konkrétního zdroje.

PŘIPOJIT

RFC 2616 . Používá se k tomu, abyste věděli, zda máte přístup k hostiteli, nikoli nutně, že požadavek dorazí na server, tato metoda se používá hlavně ke zjištění, zda nám proxy poskytuje přístup k hostiteli za zvláštních podmínek, jako jsou šifrované obousměrné datové toky. (podle požadavků protokolu SSL).

PATCH

( RFC 5789 ). Jeho funkce je stejná jako PUT, který zcela přepíše zdroj. Slouží k částečné aktualizaci jedné nebo více částí. Je také orientován na použití s ​​proxy . ]

PŘESUNOUT

RFC 2518

MKCOL

RFC 2518

PROPFIND

RFC 2518

PROPPATCH

RFC 2518

SLOUČIT

RFC 3253

AKTUALIZACE

RFC 3253

LABEL

RFC 3253

Kódy odpovědí

Odpověď nebo návratový kód je číslo, které označuje, co se stalo s požadavkem. Zbytek obsahu odpovědi bude záviset na hodnotě tohoto kódu. Systém je flexibilní a ve skutečnosti se seznam kódů rozšiřuje, aby se přizpůsobil změnám a identifikoval nové situace. Každý kód má specifický význam. Počet kódů je však zvolen tak, že v závislosti na tom, zda patří ke stovce nebo jinému, lze identifikovat typ odpovědi poskytnuté serverem:

• Kódy formátu 1xx: Informativní odpovědi. Označuje, že požadavek byl přijat a zpracovává se.
• Kódy ve formátu 2xx: Správné odpovědi. Označuje, že požadavek byl zpracován správně.
• Kódy ve formátu 3xx: Přesměrování odpovědí. Označuje, že klient musí provést další akci, aby dokončil požadavek.
• Kódy ve formátu 4xx: Chyby způsobené klientem. Označuje, že při zpracování požadavku došlo k chybě, protože klient udělal něco špatně.
• Kódy formátu 5xx: Chyby způsobené serverem. Označuje, že při zpracování požadavku došlo k chybě kvůli selhání serveru.

Záhlaví

Jsou to metadata , která se odesílají v požadavcích nebo odpovědích HTTP, aby poskytla základní informace o aktuální transakci. Každé záhlaví je určeno názvem záhlaví, za nímž následuje dvojtečka, mezera a hodnota tohoto záhlaví, za kterou následuje znak návratu na začátek řádku a odřádkování. Pro označení konce záhlaví se používá prázdný řádek. Pokud nejsou žádná záhlaví, měl by zůstat prázdný řádek.

Záhlaví poskytují protokolu velkou flexibilitu a umožňují přidávat nové funkce bez nutnosti měnit základnu. To je důvod, proč s přibývajícími verzemi HTTP přibývalo stále více povolených hlaviček.

Záhlaví mohou obsahovat metadata, která musí být zpracována klientem (např. v reakci na požadavek může být uveden typ obsahu, který obsahuje), serverem (např. typy reprezentace obsahu, který požaduje, přijatelné pro klienta) nebo zprostředkovatelé (např. jak spravovat ukládání do mezipaměti pomocí proxy )

V závislosti na typu zprávy, do které může hlavička vstoupit, je můžeme rozdělit na hlavičky požadavků, hlavičky odpovědí a hlavičky, které mohou být součástí požadavku i odpovědi.

Hlavičky můžeme klasifikovat podle jejich funkce. Například:

• Záhlaví, která označují možnosti akceptované odesílatelem zprávy: Accept (označuje přijatý MIME ), Accept-Charset (označuje přijatý znakový kód), Accept-Encoding (označuje přijatou metodu komprese), Accept-Language (označuje přijatý kód jazyk), User-Agent (pro popis klienta), Server (označuje typ serveru), Povolit (metody povolené pro zdroj)
• Záhlaví popisující obsah: Content-Type (označuje MIME obsahu), Content-Length (délka zprávy), Content-Range , Content-Encoding , Content-Language , Content-Location .
• Záhlaví, která odkazují na URI: Umístění (označuje, kde je obsah), Referer (označuje původ požadavku).
• Záhlaví pro ukládání streamu : Datum (datum vytvoření), If-Modified-Since , If-Unmodified-Since , If-Match , If-None-Match , If-Range , Expires , Last-Modified , Cache-Control , Via , Pragma , Etag , Age , Retry-After .
• Záhlaví kontroly souborů cookie: Set-Cookie , Cookie
• Hlavičky pro autentizaci: Authorization , WW-Authenticate
• Záhlaví popisující komunikaci: Host (označuje cílový stroj zprávy), Connection (označuje, jak navázat spojení)
• Ostatní: Rozsah (ke stažení pouze částí zdroje), Max-Forward (limit záhlaví přidaných v TRACE).

Příklad dialogu HTTP

Chcete-li získat zdroj s adresou URL http://www.example.com/index.html

1. Připojení je otevřeno na portu 80 hostitele www.example.com . Port 80 je výchozí port pro HTTP. Pokud byste chtěli použít port XXXX, museli byste jej zakódovat do adresy URL ve tvaru http://www.example.com:XXXX/index.html
2. Zpráva je odeslána v následujícím stylu:

ZÍSKEJTE /index.html HTTP/1.1
 Hostitel: www.example.com
 Referent: www.google.com
 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
 Spojení: keep-alive
 [Prázdný řádek]

Odpověď serveru se skládá z hlaviček následovaných požadovaným zdrojem v případě webové stránky:

HTTP/1.1 200 OK
Datum: pá, 31. prosince 2003 23:59:59 GMT
Typ obsahu: text/html
Obsah-délka: 1221

<html lang="eo">
<hlava>
<meta charset="utf-8">
<title>Název webu</title>
</head>
<body>
<h1>Domovská stránka vašeho hostitele</h1>
(Obsah)
  .
  .
  .
</body>
</html>

Verze

HTTP prošel několika verzemi protokolu, z nichž mnohé jsou zpětně kompatibilní. RFC 2145 popisuje použití čísel verzí HTTP. Klient na začátku požadavku sdělí serveru, kterou verzi používá, a server ve své odpovědi použije stejnou nebo dřívější verzi.

0.9 (vydáno v roce 1991)

zastaralý. Podporuje pouze jeden příkaz, GET, a také neuvádí číslo verze HTTP. Nepodporuje záhlaví. Vzhledem k tomu, že tato verze nepodporuje POST, klient nemůže odeslat mnoho informací na server.

HTTP/1.0 (květen 1996)

Toto je první revize protokolu, která specifikuje jeho verzi v komunikaci, a je stále široce používán, zejména v proxy serverech. Umožňuje metody požadavků GET, HEAD a POST.

HTTP/1.1 (červen 1999) ]

V současnosti nejpoužívanější verze; ^{[ pochvalná zmínka potřebovaný ]} Trvalá připojení jsou ve výchozím nastavení povolena a fungují dobře se servery proxy . Umožňuje také klientovi posílat více požadavků současně přes stejné připojení ( pipelining ), což umožňuje eliminovat zpoždění Round-Trip pro každý požadavek.

HTTP/1.2 (únor 2000)

První návrhy dokumentu PEP — An Extension Mechanism for HTTP (který navrhuje Protocol Extension Protocol , zkráceně PEP) z roku 1995 byly vytvořeny konsorciem World Wide Web Consortium a předloženy Internet Engineering Task Force . PEP bylo původně zamýšleno stát se charakteristickou řadou HTTP/1.2. V pozdějších konceptech však byl odkaz na HTTP/1.2 odstraněn. RFC 2774 ( experimentální), HTTP Extension Framework , silně zahrnuje PEP. Vyšlo v únoru 2000.

HTTP/2 (květen 2015)

V roce 2012 se objevují první návrhy nové verze HTTP ( HTTP/2 ). Tato nová verze nemění aplikační sémantiku http (všechny základní pojmy zůstávají nezměněny). Jeho vylepšení se zaměřují na způsob balení dat a na přepravu. Přidejte například použití jediného připojení, kompresi záhlaví nebo službu „server push“. Hlavní prohlížeče podporují pouze HTTP 2.0 přes TLS pomocí rozšíření ALPN ​které vyžaduje TLSv1.2 nebo vyšší. ]

HTTP/3 (říjen 2018)

HTTP/3 je navrhovaným nástupcem HTTP/2, ​, který se již na webu používá a jako základní transportní protokol používá UDP místo TCP . Stejně jako HTTP/2 není v předchozích hlavních verzích protokolu zastaralý. Podpora HTTP/3 byla přidána do Cloudflare a Google Chrome v září 2019, ​ a lze ji povolit ve stabilních verzích Chrome a Firefox . ]

Viz také

• Zabezpečení transportní vrstvy
• HTTPS
• HTTP Strict Transport Security
• HTTP (P2P)
• HTTP/2
• .har

Externí odkazy

• RFC-2616
• HTTP - Hypertext Transfer Protocol. W3C
• HTTP je opravdu snadné. od Jamese Marshalla, 1997
• Ověření záhlaví HTTP Online ověření adresy URL
• Test kompatibility HTTP/2