Http

http
název Hypertext Transfer Protocol
Úroveň (podle modelu OSI ) Aplikovaný
Rodina TCP/IP
Vytvořeno v 1992
Port/ID 80/ TCP
Specifikace RFC 124 , RFC 1945 , RFC 2616 , RFC 2617 , RFC 6266 , RFC 7230 , RFC 7240 , RFC 8446 .
Hlavní implementace (klienti) Webové prohlížeče , například Internet Explorer , Mozilla Firefox , Opera , Google Chrome , Yandex Browser , Microsoft Edge atd.
Implementace jádra ( servery ) Apache , IIS , nginx , Google Web Server atd.
 Mediální soubory na Wikimedia Commons

HTTP ( HyperText  Transfer Protocol  - „ hypertext transfer protocol “) je protokol pro přenos dat aplikační vrstvy , původně ve formě hypertextových dokumentů ve formátu HTML , který se v současnosti používá k přenosu libovolných dat.

Základní vlastnosti

Základem HTTP je technologie „klient-server“ , tedy existence:

HTTP je nyní všudypřítomný na World Wide Web pro získávání informací z webových stránek . V roce 2006 překonal HTTP provoz v Severní Americe provoz P2P sítí o 46 %, z čehož téměř polovinu tvořilo streamování videa a zvuku [1] .

HTTP se také používá jako „přenos“ pro další protokoly aplikační vrstvy, jako je SOAP , XML-RPC , WebDAV .

Hlavním předmětem manipulace v HTTP je zdroj, na který ukazuje URI (Uniform Resource Identifier) ​​v požadavku klienta. Tyto prostředky jsou obvykle soubory uložené na serveru , ale mohou to být logické objekty nebo něco abstraktního. Charakteristickým rysem protokolu HTTP je možnost specifikovat v požadavku a odpovědi , jak je stejný zdroj reprezentován různými parametry: formát , kódování , jazyk atd. (k tomu se používá zejména HTTP hlavička ). Díky možnosti určit, jak je zpráva zakódována, si klient a server mohou vyměňovat binární data , i když je tento protokol textový.

HTTP je protokol aplikační vrstvy ; jeho protějšky jsou FTP a SMTP . Zprávy se vyměňují podle obvyklého schématu „žádost-odpověď“. HTTP používá k identifikaci zdrojů globální identifikátory URI . Na rozdíl od mnoha jiných protokolů je HTTP bezstavový. To znamená, že mezi páry požadavek-odpověď není uložen žádný mezistav. Komponenty používající HTTP mohou nezávisle ukládat informace o stavu související s nedávnými požadavky a odpověďmi (např. " cookies " na straně klienta, "relace" na straně serveru). Prohlížeč, který odesílá požadavky, může sledovat zpoždění odpovědí. Server může ukládat IP adresy a hlavičky požadavků posledních klientů. Samotný protokol však nezná předchozí požadavky a odpovědi, neposkytuje vnitřní státní podporu, takové požadavky nemá.

Většina protokolů zajišťuje vytvoření relace TCP, během níž dojde k autorizaci jednou, a další akce se provádějí v kontextu této autorizace. HTTP vytvoří samostatnou TCP relaci pro každý požadavek; novější verze HTTP umožňovaly provádět více požadavků v jedné TCP relaci, ale prohlížeče si obvykle vyžádají pouze stránku a objekty v ní obsažené (obrázky, kaskádové styly atd.) a poté TCP relaci okamžitě ukončí. HTTP používá cookies k podpoře autorizovaného (neanonymního) přístupu ; Tato metoda autorizace navíc umožňuje uložit relaci i po restartování klienta a serveru.

Při přístupu k datům přes FTP nebo souborové protokoly je typ souboru (přesněji typ dat v něm obsažených) určen příponou názvu souboru, což není vždy vhodné. HTTP před samotným přenosem dat přenese hlavičku Content-Type: typ / podtyp, která klientovi umožňuje jednoznačně určit, jak má odesílaná data zpracovat. To je důležité zejména při práci se skripty CGI , kdy přípona názvu souboru neoznačuje typ dat odesílaných klientovi, ale nutnost spustit tento soubor na serveru a odeslat klientovi výsledky programu zapsaného v tomto souboru. (v tomto případě stejný soubor v závislosti na argumentech požadavku a vlastních úvahách může generovat odpovědi různých typů - v nejjednodušším případě obrázky v různých formátech).

HTTP navíc umožňuje klientovi odesílat parametry na server, které budou předány spuštěnému CGI skriptu. Za tímto účelem byly formuláře zavedeny do HTML .

Tyto vlastnosti HTTP umožnily vytvářet vyhledávače (prvním z nich byl AltaVista , vytvořený DEC ), fóra a internetové obchody. Tím se internet komercializoval, objevily se firmy, jejichž hlavním oborem činnosti bylo poskytování přístupu k internetu (poskytovatelé) a tvorba webových stránek.

Software

Veškerý software pro práci s protokolem HTTP je rozdělen do tří širokých kategorií:

Pro rozlišení koncových serverů od proxy používá oficiální dokumentace termín původní server .  Jeden a tentýž softwarový produkt může současně vykonávat funkce klienta, serveru nebo zprostředkovatele v závislosti na úkolech. Specifikace protokolu HTTP podrobně popisuje chování každé z těchto rolí.

Klienti

Protokol HTTP byl původně navržen pro přístup k hypertextovým dokumentům na World Wide Web. Proto jsou hlavní klientské implementace prohlížeče (user agenti). Pro prohlížení uloženého obsahu stránek na počítači bez připojení k internetu byly vynalezeny offline prohlížeče . Pokud je připojení nestabilní, ke stažení velkých souborů se používají manažeři stahování ; umožňují vám stáhnout zadané soubory kdykoli po ztrátě připojení k webovému serveru. Některé virtuální atlasy (například Google Earth a NASA World Wind ) také používají HTTP.

Protokol HTTP je často používán programy ke stahování aktualizací.

V internetových vyhledávačích se používá celá řada robotických programů . Mezi nimi jsou webové pavouky ( crawlery ), které procházejí hypertextovými odkazy, sestavují databázi serverových zdrojů a ukládají jejich obsah pro další analýzu.

Zdrojové servery

Hlavní implementace: Apache , Internet Information Services (IIS), nginx , LiteSpeed ​​​​Web Server (LSWS), Google Web Server , lighttpd .

Proxy servery

Hlavní implementace: Squid , UserGate , Multiproxy , Naviscope , nginx .

Struktura zprávy HTTP

Každá zpráva HTTP se skládá ze tří částí, které se odesílají v uvedeném pořadí:

  1. Starting line ( angl.  Starting line ) - určuje typ zprávy;
  2. Záhlaví ( anglicky  Headers ) - charakterizují tělo zprávy, parametry přenosu a další informace;
  3. Tělo zprávy ( anglicky  Message Body ) - přímo data zprávy. Musí být odděleny od záhlaví prázdným řádkem.

Tělo zprávy může být vynecháno, ale počáteční řádek a záhlaví jsou povinné prvky. Výjimkou je verze 0.9 protokolu, kde zpráva požadavku obsahuje pouze počáteční řádek a zpráva odpovědi obsahuje pouze tělo zprávy.

U protokolu verze 1.1 musí zpráva požadavku obsahovat hlavičku hostitele .

Počáteční řádek

Počáteční řetězce se liší pro požadavek a odpověď. Řetězec dotazu vypadá takto:

GET URI — pro verzi protokolu 0.9; Метод URI HTTP/Версия - pro ostatní verze.

Tady:

Chcete-li požádat o stránku pro tento článek, musí klient předat řetězec (uvedeno pouze jedno záhlaví):

ZÍSKEJTE /wiki/HTTP HTTP/1.0 Hostitel: en.wikipedia.org

Počáteční řádek odpovědi serveru má následující formát: HTTP/Версия КодСостояния Пояснение, kde:

Počáteční řádek odpovědi serveru na předchozí požadavek může například vypadat takto:

HTTP/1.0 200 OK

Metody

Metoda HTTP ( anglicky  HTTP Method ) - sekvence libovolných znaků, kromě ovládacích prvků a oddělovačů, označující hlavní operaci na zdroji. Obvykle je metodou krátké anglické slovo napsané velkými písmeny. Všimněte si, že název metody rozlišuje malá a velká písmena.

Server může používat libovolné metody, pro server nebo klienta neexistují žádné povinné metody. Pokud server nerozpozná metodu zadanou klientem, měl by vrátit stav 501(Neimplementováno). Pokud je metoda známa serveru, ale není použitelná pro konkrétní zdroj, 405vrátí se zpráva s kódem (Metoda není povolena). V obou případech BY MĚL server Allowve zprávě s odpovědí obsahovat hlavičku se seznamem podporovaných metod.

Kromě metod GETa HEADse často používá metoda POST.

MOŽNOSTI

Používá se k určení možností webového serveru nebo možností připojení pro konkrétní zdroj. Jako odpověď BY MĚL server obsahovat hlavičku Allowse seznamem podporovaných metod. Záhlaví odpovědi může také obsahovat informace o podporovaných rozšířeních.

Předpokládá se, že požadavek klienta může obsahovat tělo zprávy označující informace, které ho zajímají. Formát těla a pořadí práce s ním není v současné době definováno; server by to měl prozatím ignorovat. Situace je podobná s tělem v odpovědi serveru.

Aby bylo možné zjistit schopnosti celého serveru, musí klient zadat hvězdičku - " *" - v URI. Požadavky " OPTIONS * HTTP/1.1" lze také použít ke kontrole stavu serveru (podobně jako " ping ") a k otestování, zda server podporuje protokol HTTP verze 1.1.

Výsledek provedení této metody se neukládá do mezipaměti .

GET

Používá se k dotazování na obsah zadaného zdroje. GETProces můžete také spustit pomocí metody . V tomto případě by měla být informace o průběhu procesu zahrnuta do těla zprávy s odpovědí.

Klient může předat parametry provádění požadavku v URI cílového zdroje za ?znakem „ “:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Podle standardu HTTP GETjsou požadavky typu považovány za idempotentní [2]

Kromě obvyklé metody GETexistují také

Pořadí provádění takových požadavků je standardy definováno samostatně.

HEAD

Podobné jako metoda GET, s tím rozdílem, že v odpovědi serveru není žádné tělo. Dotaz HEADse obvykle používá k načtení metadat , kontrole existence zdroje ( ověření adresy URL ) a zjištění, zda se od posledního přístupu změnil.

Záhlaví odpovědí lze uložit do mezipaměti. Pokud metadata zdroje neodpovídají odpovídajícím informacím v mezipaměti, je kopie zdroje označena jako zastaralá.

POST

Například v blozích mohou návštěvníci obvykle zadat své komentáře k příspěvkům do HTML formuláře, poté jsou odeslány na server metodou POST a ten je vloží na stránku. V tomto případě jsou přenášená data (v příkladu blogu text komentáře) zahrnuta do těla požadavku.POST

Na rozdíl od metody GETnení metoda POSTpovažována za idempotentní [2] , to znamená, že opakované opakování stejných dotazů POSTmůže vracet různé výsledky (například po každém odeslání komentáře se objeví další kopie tohoto komentáře).

Pokud je výsledek provedení 200(OK), tělo odpovědi by mělo obsahovat zprávu o výsledku požadavku. Pokud byl zdroj vytvořen, server BY MĚL vrátit odpověď 201(Vytvořeno) s URI nového zdroje v souboru Location.

Zpráva o odpovědi serveru pro provedení metody POSTnení uložena v mezipaměti.

PUTS

Slouží ke stažení obsahu požadavku na URI specifikovaný v požadavku. Pokud zdroj pro daný URI neexistuje, server jej vytvoří a vrátí stav 201(Vytvořeno). Pokud byl zdroj změněn, server vrátí 200(OK) nebo 204(žádný obsah). Server NESMÍ ignorovat neplatné hlavičky Content-*zaslané klientem spolu se zprávou. Pokud některá z těchto hlaviček nelze rozpoznat nebo je za aktuálních podmínek neplatná, 501musí být vrácen chybový kód (Neimplementováno).

Základní rozdíl mezi metodami POSTspočívá PUTv pochopení záměru URI zdrojů. Metoda POSTpředpokládá, že obsah přenášený klientem bude zpracován na zadaném URI. Při použití PUT, klient předpokládá, že načítaný obsah odpovídá prostředku na daném URI.

Zprávy odpovědí serveru na metodu PUTse neukládají do mezipaměti.

PATCH

Podobné jako PUT, ale vztahuje se pouze na fragment zdroje.

VYMAZAT

Odstraní zadaný prostředek.

TRACE

Vrátí přijatý požadavek, takže klient může vidět, jaké informace zprostředkující servery přidávají nebo upravují v požadavku.

PŘIPOJIT

Převádí připojení požadavku na transparentní tunel TCP/IP , obvykle k usnadnění navázání zabezpečeného připojení SSL prostřednictvím nešifrovaného proxy serveru .

Stavové kódy

První číslice označuje třídu stavu. Po kódu odpovědi obvykle následuje mezerou oddělená vysvětlující fráze v angličtině, která dané osobě vysvětluje důvod takové odpovědi. Příklady:

201 Webová stránka vytvořena 403 Přístup povolen pouze registrovaným uživatelům 507 Nedostatek úložiště

Klient se z kódu odpovědi dozví o výsledcích svého požadavku a určí, jaké kroky podnikne dále. Sada stavových kódů je standardem a je popsána v příslušných dokumentech RFC . Klient nemusí znát všechny stavové kódy, ale musí reagovat podle třídy kódu.

В настоящее время выделено пять классов кодов состояния

Kód Třída Účel
1xx Informační

(angl. informační )

Информирование о процессе передачи.

В HTTP/1.0 — сообщения с такими кодами должны игнорироваться.

V HTTP/1.1 musí být klient připraven přijmout tuto třídu zpráv jako normální odpověď, ale na server není třeba nic odesílat.

Samotné zprávy ze serveru obsahují pouze počáteční řádek odpovědi a v případě potřeby několik polí záhlaví specifických pro odpověď. Proxy servery by takové zprávy měly odesílat dále ze serveru klientovi.

2xx Úspěch

(Anglický úspěch )

V závislosti na stavu může server stále odesílat záhlaví a tělo zprávy.
3xx přesměrovat

(angl. Redirection )

To umožňuje použití fragmentů v cílovém URI. 301302303305307Location
4xx Chyba klienta

( Chyba klienta v angličtině )

Indikace chyb ze strany klienta.HEAD
5xx Chyba serveru

( Chyba serveru v angličtině )

Informování o případech neúspěšné operace z důvodu poruchy serveru. Ve všech situacích musí server kromě použití metody HEADobsahovat vysvětlení, že klient zobrazí uživatele v těle zprávy.

Tituly

HTTP hlavičky ( anglicky  http hlavičky ) jsou řádky ve zprávě HTTP obsahující parametr s významem parametru. Formát nadpisů odpovídá obecnému formátu nadpisů textových síťových zpráv ARPA (viz RFC 822 ). Záhlaví musí být odděleno od těla zprávy alespoň jedním prázdným řádkem.

Příklady záhlaví:

Server: Apache/2.2.11 (Win32) PHP/5.3.0 Naposledy změněno: so, 16. ledna 2010 21:16:42 GMT Content-Type: text/plain; charset=windows-1251 Jazyk obsahu: en

Ve výše uvedeném příkladu představuje každý řádek jedno záhlaví. V tomto případě se to, co je před dvojtečkou, nazývá název ( anglický  název ), a to, co je za ním, se nazývá hodnota ( anglicky  value ).

Všechny nadpisy jsou rozděleny do čtyř hlavních skupin:

  1. Obecné záhlaví (“Hlavní titulky”) – mohou být zahrnuty do jakékoli zprávy klienta a serveru;
  2. Záhlaví požadavků ("Záhlaví požadavků") - používá se pouze v požadavcích klientů;
  3. Záhlaví odpovědí ("záhlaví odpovědí") - pouze pro odpovědi ze serveru;
  4. Záhlaví entity ("Záhlaví entity") - doprovází každou entitu zprávy.

Toto je pořadí, ve kterém se doporučuje odesílat hlavičky příjemci.

Všechny hlavičky potřebné pro fungování HTTP jsou popsány v základních RFC . Pokud není dostatek stávajících, můžete zadat vlastní. Tradičně se názvy těchto dodatečných nadpisů přidávají k předponě „ X-“, aby se předešlo konfliktu názvů s možnými existujícími. Například jako v záhlaví X-Powered-Bynebo X-Cache. Někteří vývojáři používají své vlastní předpony. Příklady takových hlaviček jsou Ms-Echo-Requesttaké Ms-Echo-Replypředstaveny společností Microsoft Corporation pro rozšíření WebDav .

Tělo zprávy

Tělo zprávy HTTP ( message-body), pokud je přítomno, se používá k přenosu těla objektu spojeného s požadavkem nebo odpovědí. Tělo zprávy se liší od těla objektu ( entity-body) pouze tehdy, když je použito kódování přenosu, jak ukazuje pole záhlaví Transfer-Encoding.

message-body = entita-body | <entita-tělo zakódováno podle přenosové kódování>

Pole Transfer-Encodingse používá k označení jakéhokoli kódování přenosu použitého aplikací, aby se zajistilo, že zpráva je přenášena bezpečně a správně. Pole Transfer-Encoding je vlastností zprávy, nikoli objektu, a proto může být přidáno nebo odebráno jakoukoli aplikací v řetězci žádost/odpověď.

Pravidla upravující platnost těla zprávy ve zprávě se liší pro požadavky a odpovědi.

Přítomnost zprávy zprávy v požadavku je označena přidáním hlavičky Content-Lengthnebo Transfer-Encoding. Tělo zprávy lze přidat do požadavku pouze v případě, že metoda požadavku umožňuje tělo objektu.

Tělo zprávy je zapnuto nebo není zapnuto – záleží jak na metodě požadavku, tak na kódu stavu odpovědi. Všechny odpovědi na požadavek s metodou HEADby neměly obsahovat tělo zprávy, i když existují pole záhlaví objektu ( entity-header), nutící věřit v přítomnost objektu. Žádné odpovědi se stavovými kódy 1xx(informacemi) 204(bez obsahu, bez obsahu) a 304(nezměněno, nezměněno) by měly obsahovat těla zprávy. Všechny ostatní odpovědi obsahují tělo zprávy, i když má nulovou délku.

Příklady HTTP dialogů

Pravidelný požadavek GET

Požadavek zákazníka:

ZÍSKEJTE stránku /wiki/ HTTP/1.1 Hostitel: en.wikipedia.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Přijmout: text/html Připojení: zavřít (prázdný řádek)

Odpověď serveru:

HTTP/1.1 200 OK Datum: středa, 11. února 2009 11:20:59 GMT Server: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Poslední změna: středa, 11. února 2009 11:20:59 GMT Jazyk obsahu: en Content-Typ: text/html; charset=utf-8 Délka obsahu: 1234 Připojení: zavřít (prázdný řetězec) (požadovaná stránka v HTML )

Odpověď vypadá stejně 203. Co jsou výrazně přímo požadovaná data, jsou oddělena od HTTP hlav pomocí CR , LF , CR, LF.

Přesměrování

Předpokládejme, že fiktivní společnost "Example Corp." existuje hlavní stránka „http://example.com“ a doména alias „example.org“ . Klient odešle požadavek na stránku „O společnosti“ do sekundární domény (část nadpisů je snížena):

ZÍSKEJTE /about.html HTTP/1.1 Hostitel: example.org User Agent: MyLonelyBrowser/5.0

Vzhledem k tomu, že doména Example.org není hlavní a společnost ji v budoucnu nebude používat pro jiné účely, jejich server bude vracet kód pro neustálé přesměrování, přičemž v záhlaví Locationcílové adresy URL uvede:

HTTP/1.x 301 trvale přesunuto Umístění: http://example.com/about.html#contacts Datum: Čt, 19. února 2009 11:08:01 GMT Server: Apache/2.2.4 Content-Typ: text/html; charset=windows-1251 Délka obsahu: 110 (prázdný řádek) <html><body><a href="http://example.com/about.html#contacts">Klikněte sem</a></body></html>

V nadpisu Locationmůžete určit fragmenty jako v tomto příkladu. Prohlížeč v požadavku neuvedl fragment, protože ho zajímá celý dokument. Jakmile však stránku načte, automaticky posouvá stránku na fragment „Kontakty“. Do těla odpovědi byl také umístěn krátký HTML dokument s odkazem, kterým by se návštěvník dostal na cílovou stránku, pokud se na ni prohlížeč automaticky nepřepne. Název Content-Typeobsahuje charakteristiky tohoto konkrétního vyslovovaného HTML, a nikoli dokumentu, který se nachází na cílovém URI.

Řekněme, že stejná společnost "Example Corp." má několik regionálních poboček po celém světě. A pro každou agenturu mají webové stránky s odpovídající ccTLD . Požadavek na domovskou stránku pro hlavní web „example.com“ může vypadat takto:

GET /HTTP/1.1 hostitel: example.com User Agent: MyLonelyBrowser/5.0 Přijmout: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Přijímací jazyk: ru,en-us;q=0,7,en;q=0,3 Accept-Charset: windows-1251,utf-8;q=0,7,*;q=0,7

Server vzal v úvahu titulek Accept-Languagea vytvořil odpověď s dočasným přesměrováním na ruský server "Example.ru" s uvedením jeho adresy v záhlaví Location:

HTTP/1.x Nalezeno 302 Umístění: http://example.ru/ Cache-Control: soukromé Datum: Čt, 19. února 2009 11:08:01 GMT Server: Apache/2.2.6 Content-Typ: text/html; charset=windows-1251 Délka obsahu: 82 (prázdný řádek) <html><body><a href="http://example.ru">Example Corp.</a></body></html>

Věnujte pozornost hlavičce Cache-Control: hodnota "private" říká zbytku serverů (především proxy), že odpověď může být uložena do mezipaměti pouze na straně klienta. Jinak je možné, že následující návštěvníci z jiných zemí pojedou vždy do jiného zastoupení.

Pro přesměrování se také používají kódy odezvy 303(Viz Ostatní) a 307(Dočasné přesměrování) .

Stažení životopisu a fragmentu

Předpokládejme, že fiktivní organizace nabízí stažení videa z poslední konference z webové stránky na adrese: „http://example.org/conf-2009.avi“ – ​​asi 160 MB . Zvažte, jak je soubor znovu zobrazitelný v případě selhání a jak by správce čerpání zorganizoval víceproudové zatížení několika fragmentů.

V obou případech klient zadá svůj první požadavek takto:

GET /conf-2009.avi HTTP/1.0 Hostitel: example.org Akceptovat: */* User Agent: Mozilla/4.0 (kompatibilní; MSIE 5.0; Windows 98) Referent: http://example.org/

Název Refereroznačuje, že soubor byl vyžádán z hlavní stránky webu. Správci stahování jej obvykle také specifikují, aby napodobili přechod ze stránky webu. Bez něj může server odpovědět 403(přístup zakázán), pokud nejsou povoleny požadavky z jiných stránek. V našem případě server vrátil úspěšnou odpověď:

HTTP/1.1 200 OK Datum: Čt, 19. února 2009 12:27:04 GMT Server: Apache/2.2.3 Poslední úprava: středa, 18. června 2003 16:05:58 GMT Etag: "56d-9989200-1132c580" Content-Type: video/x-msvideo Obsah-délka: 160993792 Accept-Ranges: bytes Připojení: zavřít (prázdný řetězec) (binární obsah celého souboru)

Hlavička Accept-Rangesinformuje klienta, že si může vyžádat fragmenty ze serveru, zadáním jejich offsetů od začátku souboru v bajtech. Pokud tato hlavička chybí, pak MŮŽE klient varovat uživatele, že se soubor s největší pravděpodobností nepodaří stáhnout.

Na základě hodnoty záhlaví Content-Lengthrozdělí správce stahování celý svazek na stejné části a vyžádá si je samostatně, přičemž uspořádá několik streamů. Pokud server nespecifikuje velikost, pak klient nebude moci implementovat paralelní stahování, ale bude stále moci stahovat soubor, dokud server neodpoví 416(Požadovaný rozsah není splněn).

Допустим, на 84-м мегабайте соединение с Интернетом прервалось и процест закигрус Когда соединение с Интернетом было восстановлено, менеджер закачек автоматически послал новый запрос на сервер, но с указанием выдать содержимое с 84-го мегабайта:

GET /conf-2009.avi HTTP/1.0 Hostitel: example.org Akceptovat: */* User Agent: Mozilla/4.0 (kompatibilní; MSIE 5.0; Windows 98) Rozsah: bajtů=88080384- Referent: http://example.org/

V tomto ohledu server vrátí odpověď: RefererRange

HTTP/1.1 206 Částečný obsah Datum: Čt, 19. února 2009 12:27:08 GMT Server: Apache/2.2.3 Poslední úprava: středa, 18. června 2003 16:05:58 GMT Etag: "56d-9989200-1132c580" Accept-Ranges: bytes Rozsah obsahu: bajty 88080384-160993791/160993792 Obsah-délka: 72913408 Připojení: zavřít Content-Type: video/x-msvideo (prázdný řetězec) (binární obsah od 84. MB)

Accept-RangesSkutečnost, že je přenášen fragment, je klientovi známa podle kódu 206(částečný obsah). Content-RangeVěnujte pozornost hlavičce Content-Length - udává velikost těla zprávy, tedy přenášeného fragmentu. Pokud server vrátí několik fragmentů, Content-Lengthbude obsahovat jejich celkový objem.

Nyní zpět ke správci stahování.

Počáteční správce se načte hned při prvním požadavku a přeruší připojení, jakmile dosáhne začátku druhého požadavku. Zbytek bude požadován samostatně. Například 4. oddíl bude požadován s následujícími záhlavími (některá záhlaví vynechána – viz úplný příklad výše):

GET /conf-2009.avi HTTP/1.0 Rozsah: bytes=64397516-80496894

Odpověď serveru v tomto případě bude následující (část hlaviček je vynechána – viz úplný příklad výše):

HTTP/1.1 206 Částečný obsah Accept-Ranges: bytes Rozsah obsahu: bajty 64397516-80496894/160993792 Délka obsahu: 16099379 (prázdný řetězec) (4. část binárního obsahu)

Pokud je takový požadavek odeslán na server, který nepodporuje fragmenty, vrátí standardní odpověď 200(OK), jak je uvedeno na samém začátku, ale bez hlavičky Accept-Ranges.

Viz také částečný GET , rozsahy bajtů , odpověď 206 , odpověď 416 .

Základní mechanismy protokolu

Částečné GETy

HTTP umožňuje požadovat ne celý obsah zdroje najednou, ale pouze zadaný fragment. Takové žádosti se nazývají částečné GET; schopnost je spouštět je pro servery volitelná (ale žádoucí). Částečné části se GETpoužívají hlavně pro obnovení souborů a rychlé paralelní stahování ve více vláknech. Některé programy stáhnou hlavičku archivu, zobrazí uživateli vnitřní strukturu a poté si vyžádají fragmenty se zadanými prvky archivu.

Aby klient přijal fragment, odešle požadavek na server s hlavičkou Rangespecifikující požadované rozsahy bajtů v něm . Pokud server nerozumí dílčím požadavkům (ignoruje hlavičku Range), vrátí veškerý obsah se statusem 200, stejně jako u normálního GET. V případě úspěšného dokončení vrátí server místo kódu 200odpověď se stavem 206(Partial Content) včetně hlavičky v odpovědi Content-Range. Samotné fragmenty lze předat dvěma způsoby:

Podmíněné GETy

Metoda GETse změní na "podmíněnou GET", pokud zpráva požadavku obsahuje pole záhlaví If-Modified-Since. V reakci na "podmíněné GET" je tělo požadovaného zdroje odesláno pouze v případě, že se změnilo od data uvedeného v záhlaví If-Modified-Since. Algoritmus pro určení tohoto zahrnuje následující případy:

Použití metody "podmíněného GET" je zaměřeno na uvolnění sítě, protože umožňuje nepřenášet nadbytečné informace po síti.

Vyjednávání obsahu

Vyjednávání obsahu je  mechanismus pro automatické určení požadovaného zdroje v přítomnosti několika různých verzí dokumentu. Předměty vyjednávání mohou být nejen prostředky serveru, ale také vrácené stránky s chybovými hláškami ( 403 , 404 atd.).

Existují dva hlavní typy dohod:

Oba typy lze používat současně nebo každý z nich samostatně.

Hlavní specifikace protokolu ( RFC 2616 ) také zdůrazňuje tzv. transparentní vyjednávání jako preferovanou kombinaci obou typů .  Tento druhý mechanismus by neměl být zaměňován s nezávislou technologií Transparent Content Negotiation (TCN) , která není součástí protokolu HTTP, ale lze s ním použít. Oba mají podstatný rozdíl v principu fungování a samotném významu slova „transparent“ (průhledný). Ve specifikaci HTTP transparentnost znamená, že proces je pro klienta a server neviditelný, a v technologii TCN transparentnost znamená dostupnost úplného seznamu možností zdrojů pro všechny účastníky procesu doručování dat.

Spravováno serverem

Pokud existuje více verzí prostředku, server může analyzovat hlavičky požadavků klienta a vrátit to, co považuje za nejlepší. Nadpisy Accept, Accept-Charset, Accept-Encodinga Accept-Languagesjsou převážně analyzovány User-Agent. Je žádoucí, aby server zahrnul do odpovědi hlavičku Varyudávající parametry, kterými se obsah odlišuje požadovaným URI.

Geografické umístění klienta lze určit ze vzdálené IP adresy . To je možné díky skutečnosti, že IP adresy, stejně jako názvy domén , jsou registrovány na konkrétní osobu nebo organizaci. Při registraci určíte region, ve kterém se bude požadovaný adresní prostor používat. Tato data jsou veřejně dostupná a na internetu lze nalézt odpovídající volně distribuované databáze a hotové softwarové moduly pro práci s nimi (měli byste se zaměřit na klíčová slova „Geo IP“).

Je třeba si uvědomit, že tato metoda je schopna určit polohu s maximální přesností města (zde se určuje země). V tomto případě jsou informace relevantní pouze v době registrace adresního prostoru. Pokud si například moskevský poskytovatel zaregistruje rozsah adres označujících Moskvu a začne poskytovat přístup zákazníkům z nejbližších předměstí, mohou jeho předplatitelé na některých stránkách pozorovat, že jsou z Moskvy, a nikoli z Krasnogorsku nebo Dzeržinského .

Serverem řízené vyjednávání má několik nevýhod:

  • Server pouze předpokládá, která možnost je pro koncového uživatele nejvýhodnější, ale nemůže přesně vědět, co je v tuto chvíli potřeba (například verze v ruštině nebo angličtině).
  • Existuje mnoho hlaviček skupin Accept, ale jen málo zdrojů s více možnostmi. Z tohoto důvodu je zařízení přetíženo.
  • Sdílená mezipaměť má omezenou schopnost vydávat stejnou odpověď na stejné požadavky od různých uživatelů.
  • Předávání hlaviček Accept může také odhalit některé informace o jeho preferencích, jako jsou použité jazyky, prohlížeč, kódování.
Klientsky spravované

V tomto případě je typ obsahu určen pouze na straně klienta. Za tímto účelem server vrátí v odpovědi stavový kód 300(Multiple Choices) nebo 406(Not Acceptable) seznam možností, z nichž uživatel vybere tu správnou. Klientem řízené vyjednávání funguje dobře, když se obsah liší nejběžnějšími způsoby (jako je jazyk a kódování) a je použita veřejná mezipaměť.

Hlavní nevýhodou je režie, protože k získání požadovaného obsahu musíte zadat další požadavek.

Transparentní vyjednávání

Toto vyjednávání je pro klienta i server zcela transparentní. V tomto případě se používá sdílená mezipaměť, která obsahuje seznam možností jako u klientem řízeného vyjednávání. Pokud mezipaměť rozumí všem těmto možnostem, pak se rozhodne sama, jako při vyjednávání řízeném serverem. To snižuje zatížení původního serveru a eliminuje další požadavky od klienta.

Specifikace jádra HTTP podrobně nepopisuje mechanismus transparentního vyjednávání.

Vícenásobný obsah

Protokol HTTP podporuje přenos více entit v rámci jedné zprávy. Entity lze navíc přenášet nejen jako jednoúrovňovou sekvenci, ale také jako hierarchii s prvky vnořenými do sebe. Typy médií se používají k označení více obsahu multipart/*. Práce s takovými typy se provádí podle obecných pravidel popsaných v RFC 2046 (pokud není u konkrétního typu média definováno jinak). Pokud přijímač neumí s typem pracovat, pak se k němu chová stejně jako multipart/mixed.

Parametr hranice znamená oddělovač mezi různými typy odesílaných zpráv. Například parametr DestAddress předaný z formuláře předá hodnotu e-mailové adresy a prvek AttachedFile1 následující za ním odešle binární obsah obrázku .jpg

Na straně serveru mohou být zprávy s více obsahem odeslány jako odpověď na částečnéGET zprávy , když je požadováno více fragmentů zdrojů. V tomto případě je použit typ média multipart/byteranges.

Na straně klienta se při odesílání formuláře HTMLPOST zobrazí soubor . Typickým příkladem jsou stránky pro odesílání e-mailů s přílohami souborů. Při odeslání takového dopisu prohlížeč vygeneruje zprávu typu multipart/form-data, integruje do ní jako samostatné části zadané uživatelem, předmět dopisu, adresu příjemce, samotný text a přiložené soubory:

POST /send-message.html HTTP/1.1 Hostitel: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b boundary="Asrf456BGe4h" Content-Length: (celková délka včetně podřízených záhlaví) Spojení: keep-alive Keep Alive: 300 (prázdný řetězec) (chybějící preambule) --Asrf456BGe4h name="DestAddress" (prázdný řádek) [email protected] --Asrf456BGe4h name="MessageTitle" (prázdný řádek) mrzí mě to --Asrf456BGe4h name="Text zprávy" (prázdný řádek) Tvůj mazlíček lev, kterého jsi tu nechal minulý týden jsem roztrhal celou pohovku. Prosím, vyzvedněte si to brzy! V příloze jsou dva obrázky následků. --Asrf456BGe4h Obsah-Dispozice: formulář-data; name="AttachedFile1"; filename="horor-photo-1.jpg" Typ obsahu: obrázek/jpeg (prázdný řetězec) (binární obsah první fotografie) --Asrf456BGe4h Obsah-Dispozice: formulář-data; name="AttachedFile2"; filename="horor-photo-2.jpg" Typ obsahu: obrázek/jpeg (prázdný řetězec) (binární obsah druhé fotografie) --Asrf456BGe4h-- (chybí epilog)

V příkladu v záhlaví se Content-Dispositionparametr nameshoduje s atributem nameve značkách HTML <INPUT>a <TEXTAREA>. Parametr filenamese rovná původnímu názvu souboru v počítači uživatele. Další informace o generování formulářů HTML a přikládání souborů naleznete v RFC 1867 .

Historie vývoje

HTTP/0.9 HTTP navrhl v březnu 1991 Tim Berners-Lee , který tehdy pracoval v Cernu jako mechanismus pro přístup k dokumentům na internetu a usnadňující navigaci pomocí hypertextu . Nejstarší verze protokolu HTTP/0.9 byla poprvé publikována v lednu 1992 (ačkoli implementace pochází z roku 1990 ). Specifikace protokolu vedla k zefektivnění pravidel pro interakci mezi HTTP klienty a servery a také k jasnému oddělení funkcí mezi těmito dvěma komponentami. Byla zdokumentována hlavní syntaktická a sémantická ustanovení. HTTP/1.0 V květnu 1996 byl vydán informační dokument RFC 1945 pro praktickou implementaci HTTP , který sloužil jako základ pro implementaci většiny komponent HTTP/1.0. HTTP/1.1 Moderní verze protokolu; přijata v červnu 1999 [4] . Novinkou v této verzi byl režim „trvalého připojení“: připojení TCP může zůstat otevřené i po odeslání odpovědi na požadavek, což umožňuje odeslání více požadavků na stejné připojení. Klient je nyní povinen zasílat informace o názvu hostitele , ke kterému přistupuje, což umožnilo snazší organizaci sdíleného hostingu . HTTP/2 Dne 11. února 2015 byly zveřejněny konečné verze návrhu další verze protokolu. Na rozdíl od předchozích verzí je protokol HTTP/2 binární . Mezi klíčové vlastnosti patří multiplexování dotazů, umisťování priorit pro požadavky, komprimace nadpisů, načítání několika prvků paralelně pomocí jednoho TCP spojení, podpora proaktivních push notifikací ze strany serveru [5] . HTTP/3 HTTP/3  je navrhovaným nástupcem HTTP/2 [6] [7] , který se již používá na webu na základě UDP namísto TCP jako transportního protokolu. Stejně jako HTTP/2 nezavrhuje předchozí hlavní verze protokolu. Podpora HTTP/3 byla přidána do Cloudflare a Google Chrome v září 2019 [8] [9] a lze ji povolit ve stabilních verzích Chrome a Firefox [10] .

Viz také

Poznámky

  1. ↑ Objem provozu HTTP poprvé překonal P2P Archivováno 22. prosince 2007 na Wayback Machine // Compulenta, 22. června 2007 ( Bílý dokument od Ellacoya Networks archivován 22. června 2007 na Wayback Machine ).
  2. ↑ 1 2 HTTP/1.1: Definice metod  (anglicky)  (downlink) . Archivováno z originálu 23. června 2012.
  3. ↑ Viz první větu části " 6.1.1 Stavový kód a Reason Phrase " v RFC 2068. Na straně 40 je také rozšířená deklarace BNF .) " extension-code = 3DIGIT" pro kódy rozšíření.
  4. ↑ Specifikace HTTP/1.1 byla poprvé publikována v lednu 1997 RFC 2068 ; v moderní verzi RFC 2616 byly opraveny překlepy, místy byla vylepšena terminologie a formátování. Rovněž objasnil přijatelné chování klienta (prohlížeče), serveru a proxy serverů v některých sporných situacích. To znamená, že verze 1.1 se přece jen objevila v roce 1997.
  5. ↑ Koncept HTTP/2 . Získáno 25. února 2015. Archivováno z originálu 20. února 2015.
  6. ↑ Bishop, Mike Hypertext Transfer Protocol verze 3 (HTTP/3  ) . tools.ietf.org (9. července 2019). Získáno 16. srpna 2019. Archivováno z originálu 31. srpna 2019.
  7. ↑ Cimpanu, Catalin . HTTP-over-QUIC bude přejmenován na HTTP/3 | ZDNet  (anglicky) , ZDNet . Archivováno z originálu 13. listopadu 2018. Staženo 10. srpna 2020.
  8. ↑ Cimpanu, Catalin Cloudflare, Google Chrome a Firefox přidávají podporu HTTP/3 . ZDNet (26. září 2019). Získáno 27. září 2019. Archivováno z originálu dne 26. září 2019.
  9. ↑ HTTP/3: minulost, přítomnost a  budoucnost . Blog Cloudflare (26. září 2019). Získáno 30. října 2019. Archivováno z originálu dne 26. září 2019.
  10. ↑ Firefox Nightly podporuje HTTP 3 – Obecné – Cloudflare Community (19. listopadu 2019). Staženo 23. ledna 2020. Archivováno z originálu dne 6. června 2020.

Odkazy

 Schémata URI
Oficiální
neoficiální
 Sémantický web
Základy
Pododdíly
Aplikace
související témata
Normy
  • Historie : Prostý starý sémantický HTML
  • DAML+OLEJ
 http
Obecné pojmy
Metody
Tituly
Stavové kódy