Co potřebujete vědět o protokolu HTTP jako webový vývojář. Pravidla protokolu HTTP

.) 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ž tento protokol je text.

Proxy servery

Historie vývoje

HTTP/0.9

Kromě obvyklé metody GET existují také . Podmíněné požadavky GET obsahují hlavičky If-Modified-Since , If-Match , If-Range a podobně. Částečné GETy obsahují v požadavku rozsah. Pořadí provedení podobné žádosti definovány normami samostatně.

HLAVA

Podobné jako metoda GET, s tím rozdílem, že v odpovědi serveru není žádné tělo. Požadavek HEAD se 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á.

POŠTA

Slouží k předání uživatelských dat danému zdroji. Například v blozích mohou návštěvníci obvykle zadávat 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 s blogy text komentáře) zahrnuta do těla požadavku. Podobně se metoda POST obvykle používá k nahrávání souborů na server.

Na rozdíl od metody GET není metoda POST považována za idempotentní, tedy za opakování téhož požadavky POST může vrátit různé výsledky (například po každém odeslání komentáře se objeví jedna kopie tohoto komentáře).

Pokud je výsledek 200 (OK), tělo odpovědi by mělo obsahovat zprávu o výsledku požadavku. Pokud byl prostředek vytvořen, server BY MĚL vrátit odpověď 201 (Vytvořeno) s URI nového prostředku v hlavičce Umístění.

Zpráva odpovědi serveru pro metodu POST není uložena v mezipaměti.

DÁT

Slouží ke stažení obsahu požadavku na URI specifikovaný v požadavku. Pokud pro daný URI neexistuje žádný zdroj, 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-* odeslané klientem spolu se zprávou. Pokud některá z těchto hlaviček nelze rozpoznat nebo není platná za aktuálních podmínek, musí být vrácen chybový kód 501 (Not Implemented).

Základní rozdíl mezi metodami POST a PUT spočívá v pochopení záměru URI zdrojů. Metoda POST předpokládá, že obsah odeslaný klientem bude zpracován na zadaném URI. Pomocí PUT klient předpokládá, že načítaný obsah odpovídá prostředku na daném URI.

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

NÁPLAST

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

VYMAZAT

Odstraní zadaný prostředek.

STOPA

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.

ODKAZ

Přidruží zadaný zdroj k ostatním.

ODPOJIT

Odpojí zadaný zdroj od ostatních.

PŘIPOJIT

Transformuje připojení požadavku na transparentní tunel TCP/IP, obvykle k usnadnění vytvoření bezpečného SSL připojení prostřednictvím nešifrovaného proxy serveru.

Stavové kódy

Stavový kód je součástí prvního řádku odpovědi serveru. Je to celé číslo tří arabských číslic. První číslice označuje třídu stavu. Po kódu odpovědi obvykle následuje mezerou oddělená vysvětlující fráze anglický jazyk, která dané osobě vysvětlí 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 standardní a jsou popsány v příslušných dokumentech RFC. Zavedení nových kodexů by mělo být provedeno pouze po konzultaci s IETF. Klient nemusí znát všechny stavové kódy, ale musí reagovat podle třídy kódu.

V současnosti existuje pět tříd stavových kódů.

1xx Informační (rus. Informační)

Tato třída obsahuje kódy, které informují o procesu přenosu. V HTTP/1.0 by zprávy s těmito kódy měly být ignorovány. 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 startovní čára odpověď 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 (rus. Úspěch)

Zprávy tato třída informovat o případech úspěšného přijetí a vyřízení požadavku klienta. V závislosti na stavu může server odesílat také záhlaví a tělo zprávy.

3xx přesměrování (rus. přesměrovat )

Kódy třídy 3xx sdělují klientovi, že pro úspěšné dokončení operace musí být proveden další požadavek (obvykle pomocí jiného URI). Z této třídy pět kódů , , , a přímo odkazuje na přesměrování (přesměrování). Adresu, na kterou má klient odeslat požadavek, určuje server v hlavičce Location. To umožňuje použití fragmentů v cílovém URI.

Chyba klienta 4xx (rus. Chyba klienta)

Třída kódu 4xx je určena k označení chyb na straně klienta. Při použití všech metod kromě HEAD musí server vrátit uživateli hypertextové vysvětlení v těle zprávy.

Pro zapamatování hodnot kódů od 400 do 417 existují metody názorných mnemotechnických pomůcek

5xx Chyba serveru (rus. Chyba serveru)

Pro případy neúspěšné operace z důvodu chyby serveru jsou přiděleny kódy 5xx. Pro všechny situace jiné než použití metody HEAD MUSÍ server zahrnout vysvětlení do těla zprávy, kterou klient zobrazí uživateli.

Tituly

Tělo zprávy

Tělo zprávy HTTP (tělo zprávy), 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 (tělo zprávy) se liší od těla entity (tělo entity) pouze v případě, že je použito kódování přenosu, jak je uvedeno v poli záhlaví Kódování přenosu.

tělo zprávy = tělo subjektu |

Pole Transfer-Encoding se 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 těla zprávy v požadavku je indikována přidáním pole záhlaví Content-Length nebo Transfer-Encoding do záhlaví požadavku. Tělo zprávy (tělo zprávy) MŮŽE být přidáno k požadavku pouze tehdy, když metoda požadavku umožňuje tělo entity.

Zda je tělo zprávy zahrnuto ve zprávě odpovědi, závisí na metodě požadavku i na kódu stavu odpovědi. Všechny odpovědi na požadavek s metodou HEAD nesmí obsahovat tělo zprávy (tělo zprávy), i když jsou přítomna pole záhlaví entity, aby se zdálo, že entita je přítomná. Žádné odpovědi se stavovými kódy 1xx (informační), 204 (žádný obsah) a 304 (nezměněno) nesmí obsahovat tělo 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

Existují dva hlavní typy dohod:

Spravováno serverem. řízený serverem).
Spravováno klientem Řízený agentem).

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

Hlavní specifikace protokolu (RFC 2616) také zdůrazňuje takzvané transparentní vyjednávání (angl. Transparentní vyjednávání) jako preferovanou kombinaci obou typů. Druhý mechanismus by neměl být zaměňován s nezávislou technologií Transparent Content Negotiation (TCN). Transparentní vyjednávání obsahu , viz RFC 2295), 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 není viditelný pro klienta a server, zatímco v technologii TCN transparentnost znamená dostupnost kompletní seznam možnosti 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ší. Analyzované hlavičky jsou Accept , Accept-Charset , Accept-Encoding , Accept-Languages a User-Agent. Je žádoucí, aby server zahrnul do odpovědi hlavičku Vary udávající parametry, kterými se obsah odlišuje požadovaným URI.

Geografickou polohu 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í osoba nebo organizace. Při registraci určíte region, ve kterém se bude požadovaný adresní prostor používat. Tyto údaje jsou veřejně dostupné a na internetu lze nalézt odpovídající volně distribuované databáze a již hotové softwarových modulů pracovat s nimi (měli byste se zaměřit na klíčová slova"GeoIP").

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 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 nejvýhodnější koncový uživatel, ale nemůže přesně vědět, co je potřeba v tento moment(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í.

Spravováno zákazníkem

V tento případ typ obsahu je určen pouze na straně klienta. Za tímto účelem server vrátí se stavovým kódem 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 extra zátěž, protože k získání požadovaného obsahu musíte podat další požadavek.

Transparentní schválení

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

HTTP protokol 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 jako hierarchii s prvky vnořenými do sebe. Typy médií Multipart/* se používají k označení více obsahu. Práce s těmito typy se provádí podle hlavní pravidla, popsané v RFC 2046 (pokud není u konkrétního typu média uvedeno jinak). Pokud přijímač neumí s typem pracovat, pak se k němu chová stejně jako k multipart/mixed .

Parametr hranice znamená oddělovač mezi různé typy přenášené zprávy. Například parametr DestAddress předaný z formuláře předá hodnotu emailová adresa a element AttachedFile1 za ním odešle binární obsah obrázku .jpg

Na straně serveru mohou být zprávy s více obsahem odesílány jako odpověď na požadavky na více fragmentů zdrojů. V tomto případě je použit typ média multipart/byteranges.

Ze strany klienta se při odesílání HTML formuláře nejčastěji používá metoda POST. 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 , do které se integruje jako samostatné části zadané uživatelem, předmět dopisu, adresa příjemce, samotný text a přiložené soubory:

POST /send-message.html HTTP/1.1 Host: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form- data; boundary="Asrf456BGe4h" Délka obsahu: (celkový objem, včetně podřízených nadpisů) Připojení: keep-alive Keep-Alive: 300 (prázdný řádek) (chybí preambule) --Asrf456BGe4h Obsah-Dispozice: formulář-data; name="DestAddress" (prázdný řádek) [e-mail chráněný]--Asrf456BGe4h Obsah-Dispozice: formulář-data; name="MessageTitle" (prázdný řádek) Nesnáším --Asrf456BGe4h Content-Disposition: form-data; name="Text zprávy" (prázdný řádek) Ahoj Vasily! Ten lev, co jsi mi minulý týden nechal, mi roztrhal gauč. 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" Content-Type: image/jpeg (prázdný řádek) (binární obsah první fotografie) --Asrf456BGe4h Obsah-Dispozice: formulář-data; name="AttachedFile2"; filename="horor-photo-2.jpg" Content-Type: image/jpeg (prázdný řádek) (binární obsah druhé fotografie) --Asrf456BGe4h-- (chybí epilog)

V příkladu v záhlaví Content-Disposition se parametr name shoduje atribut názvu ve značkách HTML A . Parametr filename je roven původnímu názvu souboru v počítači uživatele. Více <a href="https://periscopes.ru/cs/kogda-vyidet-novoe-obnovlenie-na-aifon-5s-podrobnaya-informaciya-ob.html">detailní informace</a> o generování formulářů HTML a připojování souborů v RFC 1867.</p> <h2><span>Funkce protokolu</span></h2> <p>Většina protokolů zajišťuje vytvoření relace TCP, během níž dojde k autorizaci jednou, a <a href="https://periscopes.ru/cs/status-eksport-iz-strany-otpravleniya-varianty-dalneishih-deistvii.html">další akce</a> provedené v rámci tohoto oprávnění. 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> <p>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 potřebu spustit <a href="https://periscopes.ru/cs/avtomaticheskaya-sinhronizaciya-failov-programma-dlya-sinhronizacii.html">daný soubor</a> na serveru a odesláním klientovi výsledky programu zapsaného v tomto souboru (v tomto případě může stejný soubor, v závislosti na argumentech požadavku a vlastních úvahách, generovat odpovědi <a href="https://periscopes.ru/cs/pochemu-ne-vklyuchaetsya-noutbuk-msi-noutbuk-msi-ne-zagruzhaetsya-perechen.html">odlišné typy</a>- v nejjednodušším případě obrázky v různých formátech).</p> <p>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.</p> <p>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.</p> <h2>Poznámky</h2> <h2>viz také</h2> <h2>Odkazy</h2> <table class="navbox collapsible autocollapse nowraplinks" style="margin:auto;;"><tr><th colspan="2" style="text-align:center;width:100%;"></th></tr></table> <p>Umožňuje získat různé zdroje, jako jsou dokumenty HTML. Protokol HTTP je základem komunikace na internetu. HTTP je komunikační protokol klient-server, což znamená, že požadavky na server iniciuje příjemce, obvykle webový prohlížeč. Výsledný výsledný dokument bude rekonstruován z různých dílčích dokumentů, například ze samostatně přijatého textu, popisu struktury dokumentu, obrázků, video souborů, skriptů a mnoha dalších.</p> <p>Klienti a servery se vzájemně ovlivňují výměnou <a href="https://periscopes.ru/cs/kak-ukrasit-stranicu-gruppy-v-vk-lichnye-soobshcheniya-soobshchestva.html">jednotlivé zprávy</a>(a ne datový tok). Zprávy odeslané klientem, obvykle webovým prohlížečem, se nazývají <i>dotazy</i> a jsou volány zprávy odeslané serverem <i>odpovědi</i>.</p> <p><img src='https://i1.wp.com/mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png' width="100%" loading=lazy loading=lazy>Přestože byl HTTP vyvinut na počátku 90. let, postupem času se vyvíjel díky své rozšiřitelnosti. HTTP je protokol <a href="https://periscopes.ru/cs/prikladnoi-informacionnyi-uroven-prikladnye-resursy.html">aplikační vrstva</a>, který k přeposílání svých zpráv nejčastěji využívá možností jiného protokolu - TCP (nebo TLS - secure TCP), nicméně k doručování takových zpráv lze teoreticky použít jakýkoli jiný spolehlivý transportní protokol. Díky své rozšiřitelnosti se používá nejen pro příjem hypertextových dokumentů nebo obrázků a videí klientovi, ale také pro přenos obsahu na servery například pomocí HTML formulářů. HTTP lze také použít k načtení pouze částí dokumentu za účelem aktualizace webové stránky na vyžádání.</p> <h2>Součásti systémů založených na HTTP</h2> <p>HTTP je protokol klient-server, to znamená, že požadavky jsou odesílány jednou stranou – uživatelským agentem (user-agent) (nebo proxy serverem). Nejčastěji je uživatelským agentem webový prohlížeč, ale může to být kdokoli, například robot, který surfuje na webu, aby doplnil a aktualizoval data indexování webových stránek pro vyhledávače.</p> <p>Každá jednotlivá žádost <i>žádost</i>) je odeslána na server, který jej zpracuje a vrátí odpověď. <i>Odezva</i>). Mezi těmito požadavky a odpověďmi existuje mnoho prostředníků nazývaných proxy, kteří provádějí různé operace a fungují například jako brány nebo mezipaměti.</p> <p>Ve skutečnosti je mezi prohlížečem a serverem mnohem více zprostředkujících zařízení, která hrají určitou roli při zpracování požadavku: směrovače, modemy a tak dále. Vzhledem k tomu, že Síť je postavena na základě systému úrovní (vrstev) interakce, jsou tito zprostředkovatelé „skryti“ na úrovni sítě a transportu. V tomto systému úrovní zabírá nejvíce HTTP <a href="https://periscopes.ru/cs/domen-lv-kakaya-strana-spisok-nacionalnyh-domenov-verhnego.html">nejvyšší úroveň</a>, která se nazývá "aplikační" (nebo "aplikační vrstva"). Znalost síťových vrstev, jako je prezentace, relace, transport, síť, propojení a fyzická, nezbytná pro pochopení síťového provozu a řešení problémů <a href="https://periscopes.ru/cs/pochemu-dns-server-nedostupen-kak-reshit-problemu-vozmozhnye.html">možné problémy</a>, nejsou vyžadovány k popisu a porozumění HTTP.</p> <h3>Klient: uživatelský agent</h3> <p>Uživatelský agent je jakýkoli nástroj nebo zařízení, které jedná jménem uživatele. Tato role náleží především webovému prohlížeči; v některých případech jsou uživatelští agenti programy, které používají inženýři a weboví vývojáři k ladění svých aplikací.</p> <p>Prohlížeč <b>Vždy</b> je entita, která iniciuje požadavek. Server to nikdy nedělá (ačkoli během let webu byly vytvořeny mechanismy, které dokážou simulovat požadavky ze serveru).</p> <p>Chcete-li zobrazit webovou stránku, prohlížeč odešle počáteční požadavek na načtení dokumentu HTML stránky. Poté prohlížeč tento dokument analyzuje a požádá <a href="https://periscopes.ru/cs/13-kakie-rasshireniya-mogut-imet-programmnye-prilozheniya-opredelenie-faila-tip.html">další soubory</a>, nutné k zobrazení obsahu webové stránky (spustitelné skripty, informace o rozložení stránky - <a href="https://periscopes.ru/cs/kak-sozdat-tablicu-css-v-html-atribut-tegov-i.html">CSS tabulky</a> styly, další zdroje ve formě obrázků a video souborů). Prohlížeč dále všechny tyto zdroje propojí a zobrazí je uživateli ve formě jediného dokumentu – webové stránky. Skripty spouštěné samotným prohlížečem mohou v následujících fázích zpracování webové stránky přijímat další zdroje přes síť a prohlížeč podle toho aktualizuje pohled uživatele na tuto stránku.</p> <p>Webová stránka je hypertextový dokument. To znamená, že některé části zobrazeného textu jsou odkazy, které lze aktivovat (obvykle kliknutím na tlačítko myši) za účelem získání a zobrazení nové webové stránky. To umožňuje uživateli vést svého uživatelského agenta při procházení webu. Prohlížeč překládá tyto „směry provozu“ do požadavků HTTP a poté interpretuje odpovědi HTTP uživatelsky přívětivým způsobem.</p> <h3>webový server</h3> <p>Na druhé straně <a href="https://periscopes.ru/cs/kommunikacionnyi-process-i-kanaly-peredachi-informacii-sposoby-peredachi.html">komunikační kanál</a> existuje server, který slouží <i>sloužit</i>) uživatele, který mu na požádání poskytne dokumenty. Z pohledu koncového uživatele je server vždy jeden <a href="https://periscopes.ru/cs/eksport-i-import-virtualnoi-mashiny-hyper-v-eksport-virtualnyh-mashin.html">virtuální stroj</a>, který zcela nebo částečně generuje dokument, i když ve skutečnosti se může jednat o skupinu serverů, mezi kterými je zátěž vyvážena, tj. přerozdělují se požadavky od různých uživatelů, nebo o komplexní <a href="https://periscopes.ru/cs/informacionnaya-sistema-programmnoe-obespechenie-informacionnoi-sistemy.html">software</a> který se dotazuje na jiné počítače (jako jsou mezipaměťové servery, databázové servery, aplikační servery <a href="https://periscopes.ru/cs/vse-o-e-commerce-dlya-nachinayushchih-elektronnaya-kommerciya-kak-nisha-dlya-biznesa.html">elektronický obchod</a> a další).</p> <p>Server nemusí být nutně umístěn na stejném stroji a naopak – na stejném stroji může být umístěno (hostováno) několik serverů. Podle verze HTTP/1.1 a s hlavičkou Host mohou dokonce sdílet stejnou IP adresu.</p> <h3>Proxy</h3> <p>Mezi webovým prohlížečem a serverem jsou <a href="https://periscopes.ru/cs/kak-zapretit-udalenie-papki-kak-zapretit-udalenie-faila-papki.html">velký počet</a> síťové uzly přenášející zprávy HTTP. Vzhledem k vrstvené struktuře většina z nich funguje i na dopravní síti resp <a href="https://periscopes.ru/cs/urovni-fizicheskii-setevoi-kanalnyi-kak-rabotaet-model-osi.html">fyzické úrovně</a>, stává se transparentní na vrstvě HTTP a potenciálně snižuje výkon. Tyto operace aplikační vrstvy se nazývají <u><b>proxy</b> </u>. Mohou nebo nemusí být transparentní (úpravy požadavků neprojdou) a mohou vykonávat různé funkce:</p> <ul><li>ukládání do mezipaměti (mezipaměť může být veřejná nebo soukromá jako mezipaměť prohlížeče)</li> <li>filtrování (jako antivirové skenování, <a href="https://periscopes.ru/cs/bilain-pin-kod-roditelskoi-usluga-bilain-roditelskii.html">rodičovská kontrola</a>, …)</li> <li>vyvažování zátěže (nechte více serverů obsluhovat různé požadavky)</li> <li>autentizace (řízení přístupu k různým zdrojům)</li> <li>logování (oprávnění k ukládání historie operací)</li> </ul><h2>Základní aspekty HTTP</h2> <h3>HTTP – jednoduché</h3> <p>I přes větší složitost zavedenou v HTTP/2 zapouzdřením zpráv HTTP do rámců je HTTP obecně jednoduchý a čitelný pro člověka. Zprávy HTTP mohou lidé číst a rozumět jim, což poskytuje snazší testování pro vývojáře a snižuje složitost pro nové uživatele.</p> <h3>HTTP - rozšiřitelný</h3> <p>Zavedení HTTP hlaviček v HTTP/1.0 usnadnilo rozšíření a experimentování protokolu. Novou funkcionalitu lze dokonce zavést jednoduchou dohodou mezi klientem a serverem o sémantice nové hlavičky.</p> <h3>HTTP je bezstavový, ale má relaci</h3> <p>HTTP je bezstavový: neexistuje žádný vztah mezi dvěma požadavky, které jsou prováděny postupně přes stejné připojení. To okamžitě implikuje možnost problémů pro uživatele při pokusu o interakci s určitou stránkou v sekvenci, například při použití nákupního košíku v elektronickém obchodě. Ale zatímco jádro HTTP je bezstavové, soubory cookie umožňují stavové relace. Pomocí rozšiřitelnosti záhlaví se do pracovního vlákna přidávají soubory cookie, což umožňuje relaci sdílet určitý kontext nebo stav při každém požadavku HTTP.</p> <h3>HTTP a připojení</h3> <p>Připojení je spravováno na úrovni transportu, a proto zásadně přesahuje HTTP. Zatímco HTTP nevyžaduje, aby základní transportní protokol byl založen na připojení, vyžaduje pouze <i>spolehlivost</i> nebo žádné ztracené zprávy (tj. alespoň představující chybu). Mezi dvěma nejběžnějšími internetovými přenosovými protokoly je TCP spolehlivý, zatímco UDP nikoli. HTTP se následně spoléhá na standard TCP, který je založen na připojení, i když připojení není vždy vyžadováno.</p> <p>HTTP/1.0 otevřelo připojení TCP pro každou výměnu požadavku/odpovědi se dvěma důležitými nevýhodami: otevření připojení vyžaduje výměnu více zpráv, a proto je pomalé, i když se stává efektivnější, když je odesíláno více zpráv nebo když jsou zprávy odesílány pravidelně: <i>teplý</i> sloučeniny jsou účinnější než <i>Studený</i>.</p> <p>Pro zmírnění těchto nedostatků zavedl HTTP/1.1 pipelining (který se ukázal jako obtížně implementovatelný) a <a href="https://periscopes.ru/cs/programma-dlya-ustoichivogo-internet-soedineniya-optimizaciya.html">stabilní spojení</a>: ležet v <a href="https://periscopes.ru/cs/prikladnye-servisy-setei-tcp-ip-snmp-protokol-osnovy.html">na bázi TCP</a> připojení lze částečně ovládat přes hlavičku Connection. HTTP/2 to posunulo o krok dále přidáním multiplexování zpráv přes jednoduché připojení, což pomáhá udržovat připojení teplé a efektivnější.</p> <p>Probíhají experimenty, aby se vyvinulo to nejlepší <a href="https://periscopes.ru/cs/transportnye-protokoly---udp-smotret-chto-takoe-udp-v-drugih.html">transportní protokol</a>, vhodnější pro HTTP. Google například experimentuje s QUIC, který je založen na UDP, aby poskytl spolehlivější a efektivnější přenosový protokol.</p> <h2>Co lze ovládat přes HTTP</h2> <p>Přirozená rozšiřitelnost HTTP umožnila postupem času větší kontrolu a funkčnost webu. Mezipaměť a metody ověřování byly ranými funkcemi v historii HTTP. Schopnost uvolnit původní omezení byla naopak přidána v roce 2010.</p> <p>Následující jsou <a href="https://periscopes.ru/cs/svyaz-mezhdu-impulsnoi-i-peredatochnoi-harakteristiki-obshchie-svoistva.html">obecné funkce</a>, spravované pomocí HTTP.</p> <ul><li><i> </i><br>Server může dát proxy a klientům pokyn, co ukládat do mezipaměti a jak dlouho. Klient může dát pokyn mezipaměti proxy, aby ignorovaly uložené dokumenty.</li> <li><i>Relaxační omezení zdroje</i><br>Aby se zabránilo spywaru a dalšímu narušení soukromí, webový prohlížeč vynucuje přísné oddělení webových stránek. Pouze stránky z <b>stejný zdroj</b> má přístup k informacím na webové stránce. Ačkoli taková omezení zatěžují server, hlavičky HTTP mohou uvolnit přísnou segregaci na straně serveru a umožnit dokumentu, aby byl součástí informací z různých domén (z bezpečnostních důvodů).</li> <li><i>Autentizace</i><br>Některé stránky jsou dostupné pouze speciálním uživatelům. Základní autentizaci lze zajistit přes HTTP, buď pomocí hlavičky WWW-Authenticate a podobně, nebo nastavením speciální relace pomocí cookies.</li> <li><i>Proxy a tunelování</i><br>Servery a/nebo klienti jsou často umístěni na intranetu a skrývají své skutečné IP adresy před ostatními. <a href="https://periscopes.ru/cs/connection-closed-v-pubg-chto-delat-s-etoi-oshibkoi-http-zaprosy-my-vse.html">HTTP požadavky</a> projít přes proxy tuto síťovou bariéru. Ne všechny proxy jsou HTTP proxy. Na nižší úrovni funguje například protokol SOCKS. Ostatní, jako je ftp, mohou být zpracovány těmito proxy.</li> <li><i>Relace</i><br>Používání <a href="https://periscopes.ru/cs/chto-takoe-faily-cookies-kuki-http-cookie-gde-nahodyatsya-i-hranyatsya-cookies.html">HTTP cookie</a> umožňuje přiřadit požadavek ke stavu na serveru. Tím se vytvoří relace, i když jádro HTTP je bezstavový protokol. To je užitečné nejen pro nákupní košíky v internetových obchodech, ale také pro jakýkoli web, který umožňuje uživateli přizpůsobit výstup.</li> </ul><h2>HTTP stream</h2> <p>Když chce klient komunikovat se serverem, ať už se jedná o cílový server nebo zprostředkující proxy, provede následující kroky:</p> <ol><li>Otevření TCP spojení: TCP spojení bude použito k odeslání požadavku nebo požadavků a přijetí odpovědi. Klient může otevřít nové připojení, znovu použít stávající nebo otevřít více připojení TCP k serveru.</li> <li>Odeslání zprávy HTTP: Zprávy HTTP (před HTTP/2) -- čitelné pro člověka. Počínaje HTTP/2 jsou jednoduché zprávy zapouzdřeny do rámců, což znemožňuje jejich přímé čtení, ale v zásadě zůstávají stejné. GET / HTTP/1.1 Hostitel: site Accept-Language: fr</li> <li>Přečíst odpověď ze serveru: HTTP/1.1 200 OK Datum: So, 09. října 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-74075b"47 Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</li> <li>Uzavře nebo znovu použije připojení pro další požadavky.</li> </ol><p>Pokud je povolen kanál HTTP, lze odeslat více požadavků bez čekání na přijetí první úplné odpovědi. HTTP kanál je silně zabudován do stávajících sítí, kde staré kusy softwaru koexistují s moderními verzemi. Potrubí HTTP bylo v HTTP/2 nahrazeno spolehlivějšími multiplexními požadavky v rámci.</p> <h2>HTTP zprávy</h2> <p>HTTP/1.1 a starší zprávy HTTP jsou čitelné pro člověka. Ve verzi HTTP/2 jsou tyto zprávy zasazeny do nové binární struktury, rámce, umožňující optimalizace, jako je komprese záhlaví a multiplexování. I když je část původní zprávy HTTP odeslána v této verzi HTTP, sémantika každé zprávy se nezmění a klient znovu vytvoří (prakticky) původní požadavek HTTP. Je také užitečné pro pochopení zpráv HTTP/2 ve formátu HTTP/1.1.</p> <p>HTTP (HyperText Transfer Protocol) byl vyvinut jako páteř World Wide Web.</p><p>Protokol HTTP funguje následovně: klientský program naváže TCP spojení se serverem (standardní číslo portu je 80) a odešle na něj HTTP požadavek. Server tento požadavek zpracuje a odešle klientovi odpověď HTTP.</p><h3>Struktura požadavku HTTP</h3> <p>HTTP požadavek se skládá z hlavičky požadavku a těla požadavku oddělených prázdným řetězcem. Může chybět tělo požadavku.</p><p>Hlavička požadavku se skládá z hlavního (prvního) řádku požadavku a následujících řádků, které zpřesňují požadavek v hlavním řádku. Mohou také chybět následující řádky.</p><p>Požadavek v hlavním řádku se skládá ze tří částí oddělených mezerami:</p><p><b>Metoda</b>(jinými slovy, příkaz HTTP):</p><p><b>DOSTAT</b>- žádost o dokument. Nejčastěji používaná metoda; v HTTP/0.9 říkají, že to bylo jediné.</p><p><b>HLAVA</b>- žádost o název dokumentu. Od GET se liší tím, že se vrací pouze hlavička požadavku s informacemi o dokumentu. Samotný doklad se nevydává.</p><p><b>POŠTA</b>- tato metoda se používá k předávání dat do CGI skriptů. Vlastní data následují v následujících řádcích dotazu jako parametry.</p><p><b>DÁT</b>- umístěte dokument na server. Pokud vím, používá se jen zřídka. Požadavek s touto metodou má tělo, ve kterém je předán samotný dokument.</p><p><b>Zdroj</b> je cesta ke konkrétnímu souboru na serveru, který chce klient přijmout (nebo umístit - u metody PUT). Pokud je prostředkem pouze soubor ke čtení, server jej MUSÍ vrátit v těle odpovědi na daný požadavek. Pokud je to cesta k nějakému CGI skriptu, pak server skript spustí a vrátí výsledek jeho provedení. Mimochodem, díky takovému sjednocení zdrojů je klientovi prakticky lhostejné, co na serveru je.</p><p><b>Verze protokolu</b>-verze protokolu HTTP, se kterým klientský program pracuje.</p><p>Jednoduchý HTTP požadavek tedy může vypadat takto:</p><p>To vyžaduje kořenový soubor z kořenového adresáře webového serveru.</p><p>Řádky za hlavním řetězcem dotazu mají následující formát:</p><p><b>Parametr: hodnota</b>.</p><p>Takto se nastavují parametry požadavku. Toto je nepovinné, všechny řádky za hlavním řetězcem dotazu mohou chybět; v tomto případě server akceptuje jejich výchozí hodnotu nebo na základě výsledků předchozího požadavku (při práci v režimu Keep-Alive).</p><p>Zde jsou některé z nejběžnějších parametrů požadavku HTTP:</p><p><b>spojení</b>(spojení) - může nabývat hodnot Keep-Alive a close. Keep-Alive ("uchovat naživu") znamená, že po vydání tohoto dokumentu není přerušeno spojení se serverem a lze zadávat další požadavky. Většina prohlížečů pracuje v režimu Keep-Alive, protože vám umožňuje „stáhnout“ html stránku a obrázky pro ni v jednom připojení k serveru. Jakmile je nastaveno, Keep-Alive přetrvává až do první chyby nebo explicitně specifikované v dalším požadavku Connection: close. <br>zavřít - Spojení je ukončeno po odpovědi na tento požadavek.</p><p><b>Uživatelský agent</b>- hodnota je "kódové označení" prohlížeče, například:</p><p>Mozilla/4.0 (kompatibilní; MSIE 5.0; Windows 95; DigExt)</p><p><b>akceptovat</b>- seznam typů obsahu podporovaných prohlížečem v pořadí podle jejich preference tímto prohlížečem, například pro můj IE5:</p><p>Přijmout: obrázek/gif, obrázek/x-xbitmap, obrázek/jpeg, obrázek/pjpeg, aplikace/vnd.ms-excel, aplikace/msword, aplikace/vnd.ms-powerpoint, */*</p><p>To je samozřejmě nutné pro případ, kdy server může vydat stejný dokument v různých formátech.</p><p>Hodnotu tohoto parametru využívají především CGI skripty pro generování odpovědi přizpůsobené pro daný prohlížeč.</p><p><b>Referent</b>– Adresa URL, ze které přešli na tento zdroj.</p><p><b>Hostitel</b>- název hostitele, ze kterého je zdroj požadován. Je užitečné, pokud má server několik virtuálních serverů pod stejnou IP adresou. V tomto případě je název virtuálního serveru určen z tohoto pole.</p><p><b>Přijímací jazyk</b>- podporovaný jazyk. Důležité pro server, který může poskytovat stejný dokument v různých jazykových verzích.</p><h3>Formát odpovědi HTTP</h3> <p>Formát odpovědi je velmi podobný formátu požadavku: má také záhlaví a tělo oddělené prázdným řádkem.</p><p>Záhlaví se také skládá z hlavního řádku a řádků parametrů, ale formát hlavního řádku se liší od formátu záhlaví požadavku.</p><p>Hlavní řetězec dotazu se skládá ze 3 polí oddělených mezerami:</p><p><b>Verze protokolu</b>- podobně jako odpovídající parametr požadavku.</p><p><b>Chybový kód</b>- kódové označení "úspěšnosti" požadavku. Kód 200 znamená „vše je v pořádku“ (OK).</p><p><b>Slovní popis chyby</b>- "dešifrování" předchozího kódu. Například pro 200 je to OK, pro 500 je to Internal Server Error.</p><p>Nejběžnější parametry odezvy http jsou:</p><p><b>spojení</b>- podobně jako odpovídající parametr požadavku. <br>Pokud server nepodporuje Keep-Alive (takové jsou), pak je hodnota Connection v odpovědi vždy blízko.</p><p><i>Proto je podle mého názoru správná taktika prohlížeče následující: <br>1. v žádosti o připojení zadejte: Keep-Alive; <br>2. Posuďte stav připojení podle pole Připojení v odpovědi.</i></p><p><b>typ obsahu</b>("typ obsahu") - obsahuje označení typu obsahu odpovědi.</p><p>V závislosti na hodnotě Content-Type prohlížeč zachází s odpovědí jako s HTML stránkou, obrázkem gif nebo jpeg, souborem k uložení na disk nebo něčím jiným a provede příslušnou akci. Hodnota Content-Type pro prohlížeč je stejná jako hodnota přípony souboru pro Windows.</p><p>Některé typy obsahu:</p><p>text/html - text ve formátu HTML (webová stránka); <br>text/plain - prostý text (podobně jako "poznámkový blok"); <br>image/jpeg - obrázek ve formátu JPEG; <br>image/gif - totéž, ve formátu GIF; <br>application/octet-stream – Proud „oktetů“ (tj. pouze bajtů), které mají být zapsány na disk. <br></p><p>Ve skutečnosti existuje mnohem více typů obsahu.</p><p><b>délka obsahu</b>("délka obsahu") - délka obsahu odpovědi v bajtech.</p><p><b>Naposledy změněno</b>(„Poslední úprava“) – datum, kdy byl dokument naposledy upraven.</p> <p>Protokol HTTP (HyperText Transfer Protocol) je protokol aplikační vrstvy, který umožňuje aplikacím komunikovat v rámci distribuovaných, kolaborativních nebo heterogenních informačních systémů. Protokol umožňuje aplikacím vyměňovat si data prezentovaná v lidsky čitelné formě.</p> <p>Jak již název napovídá, HTTP byl původně navržen pro přenos mezi aplikacemi tzv. hypertextu (hypertext), což je speciální druh dat vytvořený v souladu se standardem HTML (HyperText Markup Language). Hypertextový dokument se skládá z dat označených HTML tagy a je kombinací textu, obrázků, hypertextových odkazů a dalších prostředků prezentace dat. Hypertextové odkazy – jedna z nejdůležitějších součástí HTML dokumentu – jsou interaktivní oblasti, jejichž dopad vede k příjmu dat spojených s hypertextovým odkazem. To umožňuje uživateli pracujícímu s hypertextovými informacemi procházet v rámci souboru dokumentů nebo dokonce celého internetu a získávat informace, které ho zajímají, pomocí kontextových hypertextových odkazů.</p> <p>Protokol HTTP je nadstavbou nad protokolem TCP a je prostředkem kontroly obsahu přenášených dat. Na rozdíl od TCP, které nebralo v úvahu strukturu přenášených paketů, HTTP vkládá do dat metainformace, které příjemci umožňují správně interpretovat přijatá data. HTTP je základem pro globální Internet (také nazývaný World Wide Web nebo WWW). První verze protokolu - HTTP / 0.9 - měla spíše omezené možnosti, ale s aktivním rozvojem celosvětové sítě se objevily nové verze: HTTP / 1.0 a HTTP / 1.1, které umožňují řídit přenos nejen hypertextových informací. přes počítačové sítě, ale také libovolné binární soubory: zvukové, grafické, archivní atd.</p> <p>Vzhledem k tomu, že HTTP je doplněk nad protokolem TCP, existují také dvě strany přenosu dat: klient a server.</p> <p>Klient je iniciátorem připojení a požaduje od serveru některá data nebo služby. Klientem je zpravidla program zvaný prohlížeč (prohlížeč), který umožňuje jak zobrazování hypertextových informací, tak přijímání souborů v jiných formátech. Aby klient získal nějaké zajímavé informace, odešle na server požadavek obsahující popis požadovaných informací.</p> <p>Server při přenosu dat přes HTTP se nazývá web server (web-server). Tento program zpracovává požadavky klientů, předává požadovaná data ve formě odpovědí (response), obsahujících kromě požadovaných dat i metainformace, které je popisují.</p> <p>Získání údajů, které uživatele zajímají, se skládá z následujících kroků:</p> <p>Uživatel zadá adresu zdroje, který ho zajímá, do řádku prohlížeče.</p> <p>Prohlížeč na základě informací přijatých od uživatele a také s ohledem na jeho nastavení a konfiguraci operačního systému generuje požadavek.</p> <p>Prohlížeč se připojí k serveru, případně na vzdáleném počítači, a předá mu požadavek.</p> <p>Server, který požadavek analyzuje, provede potřebné akce: vygeneruje odpověď, včetně těla požadovaného dokumentu. Pokud se jedná o hypertextový dokument, je načten ze souboru nebo dynamicky generovaný skriptem. Odpověď také obsahuje informace o datech, která obsahuje.</p> <p>Server odešle odpověď do prohlížeče.</p> <p>Prohlížeč analyzuje odpověď a buď uloží přijatá data do souboru, nebo v případě hypertextového dokumentu analyzuje značky HTML a zobrazí dokument na obrazovce.</p> <p>Nutno podotknout, že klientským programem může být nejen prohlížeč, nicméně všechny kroky, snad s výjimkou toho prvního, se stejně provedou.</p> <p>Je třeba poznamenat, že zde uvažujeme o přímém připojení klienta k serveru obsahujícímu zájmové informace, to však není vždy možné vzhledem k různým okolnostem. V takovém případě může být spojení provedeno přes jeden nebo více mezilehlých spojovacích bodů. Tyto mezilehlé body lze rozdělit do tří skupin:</p> <p>Proxy servery (proxy-server) - zprostředkující program, který vykonává funkce klienta i serveru za účelem vytváření požadavků jménem jiných klientů. Požadavky jsou obsluhovány proxy serverem nebo na něj předávány se změnami (v tomto případě se proxy nazývá neprůhledný) nebo beze změn (v tomto případě se proxy nazývá transparentní). Proxy server umožňuje skupině počítačů fungovat jako jeden klient, což se často používá při připojování místních sítí k Internetu.</p> <p>Brána - jako proxy server vysílá požadavky, ale neměním je. Brána obdrží požadavek od klienta, jako by to byl server obsahující dotyčný zdroj. Klient tedy nemůže určit, zda se připojuje přes bránu nebo přímo k serveru obsahujícímu prostředek.</p> <p>Tunel – zprostředkující program, který udržuje spojení. Přestože po navázání spojení není tunel považován za součást přenosu HTTP, spojení je obvykle iniciováno požadavkem HTTP. Tunel se ukončí, pokud alespoň jeden z účastníků výměny dat uzavře spojení.</p> <p>Pro zachování funkčnosti přenosu dat při připojování přes mezilehlé body nejsou vyžadovány žádné změny požadavků a odpovědí, s výjimkou proxy serveru, kdy musí být v požadavku klienta obsažena další pole. Z pohledu serveru se však data vyměňují přímo s klientem, takže nedochází k žádným změnám požadavků. Při vývoji programu se proto nepočítalo s možností napojení přes mezilehlé body.</p> <p>Požadavek zaslaný klientem na server slouží k přesné identifikaci požadovaného zdroje a obsahuje také informace nezbytné pro správné zpracování požadavku.</p> <p>Ve své struktuře se žádost skládá ze tří částí:</p> <p>Řetězec dotazu</p> <p>Blok záhlaví</p> <p>Řetězec dotazu se skládá ze tří polí oddělených mezerami (ASCII kód 20h, dále SP) a končí kombinací dvou znaků: návrat vozíku (ASCII kód 0Dh, dále CR) a posun řádku (ASCII kód 0Ah, dále LF) . Prvky řetězce dotazu jsou reprezentovány následujícími poli:</p> <p>Metoda (metoda) - definuje metodu zpracování aplikovanou na požadovaný zdroj. V závislosti na zadané metodě se může formát požadavku lišit. Platné metody:</p> <p>Při vývoji programu byla podporována pouze metoda GET, a to z toho důvodu, že prohlížeč tuto metodu specifikuje ve standardně vytvořeném požadavku.</p> <p>URI (Universal Resource Identifier) zdroj (URI zdroje) - označuje umístění požadovaného zdroje ve standardizovaném formátu, to znamená, že je to adresa zdroje. Při použití metody GET může tento řetězec obsahovat sadu parametrů předávaných serveru ve formě řetězců ve formátu „název_parametru = hodnota_parametru“, oddělených znaky ampersand `&. Blok parametrů je na konci Řetězec URI a je oddělen od adresy znakem otazníku `?".</p> <p>Verze protokolu HTTP - při vývoji programu byla implementována podpora pro příjem požadavků odpovídajících verzím 1.0 a 1.1, které odpovídají řetězcům "HTTP/1.0" a "HTTP/1.1".</p> <p>Blok záhlaví následující za řetězcem dotazu se může skládat z jednoho nebo více záhlaví:</p> <p>Hlavička požadavku – obsahuje pole, která slouží jako modifikátory požadavku a obsahují informace o požadavku a konfiguraci klientského počítače.</p> <p>Hlavička objektu – pokud požadavek obsahuje nějaký objekt (libovolnou sadu dat), pole této hlavičky popisují objekt s uvedením jeho formátu, kódování a dalších parametrů.</p> <p>Obecná hlavička – obsahuje parametry služby nezbytné pro zajištění správného přenosu a povolení doplňkových služeb, jako je ukládání do mezipaměti.</p> <p>Záhlaví je zakončeno dvěma páry znaků CR a LF, což usnadňuje určení konce příjmu požadavku, protože požadavek sám takovou kombinaci znaků obsahovat nemůže.</p> <p>Odpověď zaslanou serverem klientovi může být vygenerována pouze jako výsledek zpracování požadavku klienta. Obsahuje popis výsledků požadavku, a pokud byla data požadována, obsahuje požadovaný zdroj.</p> <p>Ve své struktuře se odpověď skládá z následujících částí:</p> <p>Stavový řádek</p> <p>Blok záhlaví</p> <p>Stavový řádek se skládá ze tří polí oddělených znaky SP a končí posloupností znaků CR, LF. Prvky stavového řádku:</p> <p>Verze protokolu HTTP - vyvíjený program vždy používá řetězec "HTTP/1.1".</p> <p>Stavový kód (stavový kód) – třímístný číselný kód, který identifikuje výsledek požadavku. Ačkoli standard definuje poměrně velkou sadu stavových kódů, v programu se používají následující kódy:</p> <ul><li>200 - úspěšné provedení;</li> <li>400 - neplatný požadavek;</li> <li>401 - neoprávněný přístup;</li> <li>404 - zdroj nenalezen;</li> <li>405 - nepoužitelná metoda;</li> <li>505 je nepodporovaná verze HTTP.</li> </ul><p>Důvodová fráze – krátká fráze, která vysvětluje stavový kód požadavku. Norma navrhuje standardní sadu frází, ale tato sada byla v programu poněkud upravena.</p> <p>Blok záhlaví po stavovém řádku se může skládat z jednoho nebo více záhlaví:</p> <p>Záhlaví požadavku</p> <p>Název objektu</p> <p>Obecné záhlaví</p> <p>Nadpisy byly podrobně probrány v 2.2.3.3.</p> <p>Záhlaví končí dvěma dvojicemi znaků CR a LF, za nimiž následuje libovolná sada znaků - objekt. Když je program spuštěn, takovými objekty mohou být pouze hypertextové dokumenty ve formátu HTML, dynamicky generované zásuvnými moduly.</p> <p>Vaši pozornost vyzýváme k popisu hlavních aspektů protokolu HTTP - síťového protokolu, který od počátku 90. let až dodnes umožňuje vašemu prohlížeči stahovat webové stránky. Tento článek je napsán pro ty, kteří s prací s počítačovými sítěmi a vývojem síťových aplikací teprve začínají a pro které je stále těžké si sami přečíst oficiální specifikace.</p><p><b>http</b>- široce používaný protokol přenosu dat, původně určený pro přenos hypertextových dokumentů (tedy dokumentů, které mohou obsahovat odkazy umožňující organizovat přechod na jiné dokumenty).</p><p>Zkratka HTTP znamená <i>Hyper Text Transfer Protocol</i>, "Hypertext Transfer Protocol". Podle specifikace OSI je HTTP protokol aplikační (horní, 7.) vrstvy. Aktuální verze protokolu, HTTP 1.1, je popsána ve specifikaci RFC 2616.</p><p>Protokol HTTP předpokládá použití struktury přenosu dat klient-server. Klientská aplikace vytvoří požadavek a odešle jej na server, načež serverový software tento požadavek zpracuje, vygeneruje odpověď a odešle ji zpět klientovi. Poté může klientská aplikace pokračovat v zasílání dalších požadavků, které budou zpracovány stejným způsobem.</p><p>Úkolem, který se tradičně řeší pomocí protokolu HTTP, je výměna dat mezi uživatelskou aplikací, která přistupuje k webovým zdrojům (obvykle webový prohlížeč) a webovým serverem. V současnosti je práce World Wide Webu zajištěna právě díky protokolu HTTP. <br><br>HTTP se také často používá jako komunikační protokol pro další protokoly aplikační vrstvy, jako je SOAP, XML-RPC a WebDAV. V takovém případě se říká, že protokol HTTP se používá jako „transport“.</p><p>API mnoha softwarových produktů také předpokládá použití HTTP pro přenos dat - samotná data mohou být v jakémkoli formátu, například XML nebo JSON.</p><p>Přenos dat protokolem HTTP se zpravidla provádí přes spojení TCP / IP. Serverový software obvykle používá port TCP 80 (a pokud port není výslovně uveden, klientský software obvykle používá port 80 ve výchozím nastavení pro otevírání připojení HTTP), ačkoli lze použít jakýkoli jiný port.</p><h4>Jak odeslat požadavek HTTP?</h4>Nejjednodušší způsob, jak se vypořádat s protokolem HTTP, je pokusit se o ruční přístup k nějakému webovému zdroji. Představte si, že jste prohlížeč a máte uživatele, který opravdu chce číst články Anatoly Alizara. <p>Předpokládejme, že do adresního řádku zadal následující:</p><p>http://alizar.site/</p><p>V souladu s tím se nyní jako webový prohlížeč musíte připojit k webovému serveru na adrese alizar.site.</p><p>K tomu můžete použít jakýkoli vhodný nástroj příkazového řádku. Například telnet:</p><p>Telnet alizar.site 80</p><p>Abychom to hned objasnili, pokud si to náhle rozmyslíte, stiskněte Ctrl + "] a poté zadejte - to vám umožní ukončit připojení HTTP. Kromě telnetu můžete zkusit nc (nebo ncat) - podle chuti.</p><p>Po připojení k serveru musíte odeslat požadavek HTTP. To je mimochodem velmi snadné - HTTP požadavky se mohou skládat pouze ze dvou řádků.</p><p>Abyste mohli vytvořit požadavek HTTP, musíte sestavit počáteční řádek a také nastavit alespoň jednu hlavičku - to je hlavička Host, která je povinná a musí být přítomna v každém požadavku. Faktem je, že převod názvu domény na IP adresu se provádí na straně klienta, a proto, když otevřete připojení TCP, vzdálený server nemá žádné informace o tom, která adresa byla použita pro připojení: může to být například adresa alizar..ru nebo m.. Ve skutečnosti je však síťové připojení ve všech případech otevřeno uzlem 212.24.43.44, a i když zpočátku, při otevírání připojení, nikoli touto IP adresou byla zadána, ale někteří nejsou nijak informováni - proto je nutné tuto adresu předat v hlavičce Host.</p><p>Počáteční (počáteční) řetězec dotazu pro HTTP 1.1 je složen takto:</p><p>Například (takový počáteční řádek může znamenat, že je požadována hlavní stránka webu):</p><p>A samozřejmě nezapomeňte, že jakákoli technologie se stane mnohem jednodušší a přehlednější, když ji skutečně začnete používat.</p><p>Hodně štěstí a příjemné učení! <br></p><p>Štítky:</p><ul><li>http</li> <li>alizar</li> <li>spdy</li> </ul> Přidat štítky<script>document.write("<img style='display:none;' src='//counter.yadro.ru/hit;artfast_after?t44.1;r"+ escape(document.referrer)+((typeof(screen)=="undefined")?"": ";s"+screen.width+"*"+screen.height+"*"+(screen.colorDepth? screen.colorDepth:screen.pixelDepth))+";u"+escape(document.URL)+";h"+escape(document.title.substring(0,150))+ ";"+Math.random()+ "border='0' width='1' height='1' loading=lazy loading=lazy>");</script> </article> <div class="tags"></div> <script type="text/javascript" src="//yandex.st/share/share.js" charset="utf-8"></script> <div class="yashare-auto-init" data-yashareL10n="ru" data-yashareQuickServices="vkontakte,facebook,twitter,odnoklassniki,moimir,gplus" data-yashareTheme="counter" ></div> <div id="venus-269"></div> </div> <div class="seealso"> <span class="title">Přečtěte si více:</span> <ul> <li> <div> <a href='https://periscopes.ru/cs/gde-nikol-nikol-kreizi-femili---kachestvennyi-detskii-kanal.html' title='"николь крейзи фэмили" - качественный детский канал'> <noindex><img width="640" height="426" src="/uploads/91c67f3e5f6e650e62bfa313f7225907.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt=""николь крейзи фэмили" - качественный детский канал" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy loading=lazy></noindex> </a> </div> <span class='date'><noindex>2023-04-08 23:43:37</noindex></span> <div><a href='https://periscopes.ru/cs/gde-nikol-nikol-kreizi-femili---kachestvennyi-detskii-kanal.html' title='"николь крейзи фэмили" - качественный детский канал'>"nicole crazy family" - vysoce kvalitní dětský kanál</a></div> </li> <li> <div> <a href='https://periscopes.ru/cs/fallout-4-kak-sobrat-vse-modifikacii-robotov.html' title='Fallout 4 jak posbírat všechny modifikace robotů'> <noindex><img width="640" height="426" src="/uploads/389cc23df85d05004cf6888d2148bf35.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Fallout 4 jak posbírat všechny modifikace robotů" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy loading=lazy></noindex> </a> </div> <span class='date'><noindex>2023-04-08 23:43:37</noindex></span> <div><a href='https://periscopes.ru/cs/fallout-4-kak-sobrat-vse-modifikacii-robotov.html' title='Fallout 4 jak posbírat všechny modifikace robotů'>Fallout 4 jak posbírat všechny modifikace robotů</a></div> </li> <li> <div> <a href='https://periscopes.ru/cs/fallout-4-verstak-dlya-robotov-gde-vzyat.html' title='Robotický pracovní stůl Fallout 4 kde získat'> <noindex><img width="640" height="426" src="/uploads/f2eb0cd08da874a65e8f81964fd12b3e.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Robotický pracovní stůl Fallout 4 kde získat" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy loading=lazy></noindex> </a> </div> <span class='date'><noindex>2023-04-08 23:43:37</noindex></span> <div><a href='https://periscopes.ru/cs/fallout-4-verstak-dlya-robotov-gde-vzyat.html' title='Robotický pracovní stůl Fallout 4 kde získat'>Robotický pracovní stůl Fallout 4 kde získat</a></div> </li> <li> <div> <a href='https://periscopes.ru/cs/kak-sdelat-normalnyi-format-lista-v-vorde-vkladka-razmetka.html' title='Karta rozložení stránky ve wordu'> <noindex><img width="640" height="426" src="/uploads/9257730d2be02b4631a49fa96183bfde.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Karta rozložení stránky ve wordu" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy loading=lazy></noindex> </a> </div> <span class='date'><noindex>2023-03-27 19:26:56</noindex></span> <div><a href='https://periscopes.ru/cs/kak-sdelat-normalnyi-format-lista-v-vorde-vkladka-razmetka.html' title='Karta rozložení stránky ve wordu'>Karta rozložení stránky ve wordu</a></div> </li> <li> <div> <a href='https://periscopes.ru/cs/pereustanovka-vindovs-s-fleshki-ustanovka-vindovs-s-fleshki-cherez-bios-kak.html' title='Instalace windows z flash disku přes bios'> <noindex><img width="640" height="426" src="/uploads/911dcd446089eaf80f3cbc417547b007.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Instalace windows z flash disku přes bios" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy loading=lazy></noindex> </a> </div> <span class='date'><noindex>2023-03-27 19:26:56</noindex></span> <div><a href='https://periscopes.ru/cs/pereustanovka-vindovs-s-fleshki-ustanovka-vindovs-s-fleshki-cherez-bios-kak.html' title='Instalace windows z flash disku přes bios'>Instalace windows z flash disku přes bios</a></div> </li> <li> <div> <a href='https://periscopes.ru/cs/kak-zaregistrirovatsya-na-moi-mir-moi-mir-registraciya-besplatno-kak.html' title='Můj svět - registrace je zdarma'> <noindex><img width="640" height="426" src="/uploads/381a3e2e8e220cc52ba435cfdd4d60db.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Můj svět - registrace je zdarma" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy loading=lazy></noindex> </a> </div> <span class='date'><noindex>2023-03-27 19:26:56</noindex></span> <div><a href='https://periscopes.ru/cs/kak-zaregistrirovatsya-na-moi-mir-moi-mir-registraciya-besplatno-kak.html' title='Můj svět - registrace je zdarma'>Můj svět - registrace je zdarma</a></div> </li> </ul> </div> </div> </div> </div> <footer> <nav id="links"> </nav> <div id="footer"> <div class="icon-logos_footer" style="position:absolute; top:16px; left:18px; width: 119px; height: 19px;"> </div> <span>© 2023. Mobilní technologie a telekomunikační operátoři</span> <div> </div> </footer> </div> </div> </div> <script type='text/javascript' src='https://periscopes.ru/wp-content/plugins/wp-polls/polls-js.js?ver=2.73.7'></script> <script type='text/javascript' src='/wp-includes/js/comment-reply.min.js?ver=4.8.2'></script> <script type='text/javascript'> var q2w3_sidebar_options = new Array(); q2w3_sidebar_options[0] = { "sidebar" : "sidebar-article", "margin_top" : 10, "margin_bottom" : 0, "stop_id" : "", "screen_max_width" : 0, "screen_max_height" : 0, "width_inherit" : false, "refresh_interval" : 1500, "window_load_hook" : false, "disable_mo_api" : false, "widgets" : ['text-20'] } ; </script> <script type='text/javascript' src='https://periscopes.ru/wp-content/plugins/q2w3-fixed-widget/js/q2w3-fixed-widget.min.js?ver=5.0.4'></script> <script type='text/javascript' src='/wp-includes/js/wp-embed.min.js?ver=4.8.2'></script> <script type='text/javascript' src='https://periscopes.ru/wp-content/plugins/akismet/_inc/form.js?ver=4.0'></script> <script type="text/javascript"> $(document).ready(function(){ var bg = $(".slider > ul > li > a > img").attr ("src"); $(".slider").css("background", "url("+bg+")"); $(".slider > ul > li:first-child").addClass ("active"); } ); $(function () { $("#devider").masonry({ itemSelector: ".vpost" } ); $(".sub-menu").each(function () { $(this).parent().eq(0).hover(function () { $(this).addClass("li-hover"); } , function () { $(this).removeClass("li-hover"); } ); } ); $(".tabs-all-cat > li").each(function () { $(this).hover(function () { $(this).addClass("li-hover"); $(".tabs-all-cat > li > ul").show(); } , function () { $(this).removeClass("li-hover"); $(".tabs-all-cat > li > ul").hide(); } ); } ); $(".slider-a").click(function () { $(".slider > ul > li").removeClass ("active"); $(this).parent().addClass ("active"); var bg = $(".active > a > img").attr ("src"); $(".slider").css("background", "url("+bg+")"); } ); } ); </script> </body> </html><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script>