Kód zakazující sledování hlaviček http. Co je hlavička http? Popis hlaviček http

URL:
User-Agent:

Zobrazit html kód stránky
Kódování: Automatická detekce UTF-8 ISO-8859-1 Windows-1251 KOI8-R

Příkaz konzoly pro tisk záhlaví:
curl -I http://stránka

Seznam kódů odpovědí serveru

Stavový kód HTTP(Angličtina) Stavový kód HTTP) - stavový kód je součástí prvního řádku odpovědi serveru. Je to celé číslo složené ze 3 arabských číslic. První číslice označuje třídu podmínky. Za kódem odpovědi obvykle následuje vysvětlující fráze oddělená mezerou. angličtina, která dané osobě vysvětluje důvod této konkrétní odpovědi. Příklad:

403 Přístup povolen pouze registrovaným uživatelům

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 všechny jsou popsány v odpovídajících dokumentech RFC. Nové kódy by měly být zavedeny pouze po dohodě s IETF. Klient nemusí znát všechny stavové kódy, ale musí reagovat podle třídy kódu.

V současné době existuje pět tříd stavových kódů:

• 1xx: Informační(Ruština) Informační) - žádost je přijata a pochopena a zpracování pokračuje.
• 2xx: Úspěch(Ruština) Úspěšně) - žádost byla úspěšně přijata, pochopena a zpracována.
• 3xx: Přesměrování(Ruština) Přesměrování) - k dokončení žádosti je třeba provést další kroky.
• 4xx: Chyba klienta(Ruština) Chyba klienta) - požadavek má špatnou syntaxi nebo jej nelze provést.
• 5xx: Chyba serveru(Ruština) Chyba serveru) - server není schopen splnit platný požadavek.

Níže jsou uvedeny kódy odpovědí z registru stavových kódů IANA.

1xx: Informační

Tato třída obsahuje kódy, které informují o procesu přenosu. V HTTP/1.0 by zprávy s takovými 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 nemusí na server nic posí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 podobné zprávy musí být odesláno dále ze serveru klientovi.

100 Pokračujte
(Ruština) Pokračovat)
Server je spokojen s počáteční informací o požadavku. Klient může pokračovat v předávání hlaviček.

101 Přepínací protokoly
(Ruština) Přepínání protokolů)
Server nabízí přepnutí na protokol vhodnější pro zadaný zdroj. Server musí uvést seznam navrhovaných protokolů v poli Záhlaví aktualizace. Pokud o to má klient zájem, tak pošle nový požadavek označující jiný protokol.

102 Zpracování
(Ruština) Probíhá zpracování)
Žádost byla přijata, ale její zpracování bude nějakou dobu trvat. dlouhá doba. Používá se serverem, aby zabránil klientovi přerušit připojení kvůli vypršení časového limitu. Při obdržení takové odpovědi musí klient resetovat časovač a čekat další příkaz v normálním režimu.

2xx: Úspěch

Zprávy této třídy informují o případech úspěšného přijetí a zpracování požadavku klienta. V závislosti na stavu může server také přenášet záhlaví a tělo zprávy.

200 v pořádku
(Ruština) Dobře)
Žádost byla úspěšná. Pokud si klient vyžádal nějaká data, jsou nalezena v hlavičce a/nebo těle zprávy.

201 Vytvořeno
(Ruština) Vytvořeno)
V důsledku úspěšného provedení požadavku byl vytvořen nový zdroj. Server musí uvést své umístění v záhlaví Location. Doporučuje se, aby server také uvedl charakteristiky vytvořeného zdroje v záhlaví (například v poli Content-Type). Pokud si server není jistý, že prostředek bude skutečně existovat, když klient obdrží tuto zprávu, je lepší použít odpověď 202.

202 Přijato
(Ruština) Přijato)
Žádost byla přijata ke zpracování, ale zpracování nebylo dokončeno. Klient nemusí čekat na konečný přenos zprávy, protože velmi dlouhý proces.

203 Neautoritativní informace
(Ruština) Neoprávněné informace)
Podobné jako odpověď 200, ale v tomto případě nebyly přenášené informace převzaty z primárního zdroje ( záložní kopie, jiný server atd.), a proto nemusí být relevantní.

204 Žádný obsah
(Ruština) Žádný obsah)
Server úspěšně zpracoval požadavek, ale odpověď obsahovala pouze hlavičky bez těla zprávy. Klient nemusí aktualizovat obsah dokumentu, ale může na něj aplikovat přijatá metadata.

205 Obnovit obsah
(Ruština) Obnovit obsah)
Server ukládá klientovi povinnost požádat uživatele o zadané údaje. Server nepřenáší tělo zprávy a není nutné dokument aktualizovat.

206 Částečný obsah
(Ruština) Částečný obsah)
Server úspěšně dokončil požadavek klienta, ale přenesl pouze část dokumentu. Server může odeslat takovou odpověď, pokud hlavička požadavku klienta obsahuje pole Content-Range. Zvláštní pozornost Při práci s takovými odpověďmi byste měli věnovat pozornost ukládání do mezipaměti.

207 Vícestav
(Ruština) Vícestavové)
Server přenáší výsledky několika nezávislých operací najednou. Jsou umístěny v samotném těle zprávy jako dokument XML s jedním vícestavovým objektem. Do tohoto objektu se nedoporučuje umisťovat stavy z řady 1xx z důvodu nesmyslnosti a redundance.

Využito 226 IM
(Ruština) IM použitý)
Hlavička A-IM od klienta byla úspěšně přijata a server vrací obsah s ohledem na zadané parametry.

3xx: Přesměrování

Stavové kódy třídy 3xx sdělují klientovi, že aby byla operace úspěšná, musí být další požadavek podán na jiný URI. Ve většině případů nová adresa uvedenou v poli Umístění v záhlaví. V tomto případě musí klient zpravidla provést automatický přechod(jarg: přesměrování).

Všimněte si, že když přistoupíte k dalšímu prostředku, můžete získat odpověď ze stejné třídy kódu. Může dokonce existovat dlouhý řetězec přesměrování, který, pokud by byl proveden automaticky, by způsobil nadměrné zatížení zařízení. Proto vývojáři HTTP protokol Důrazně doporučujeme, abyste si po druhé takové odpovědi v řadě vyžádali od uživatele potvrzení o přesměrování (dříve se doporučovalo po 5.). Klient je odpovědný za monitorování, protože aktuální server může klienta přesměrovat na zdroj na jiném serveru. Klient musí také zabránit tomu, aby se dostal do kruhových přesměrování.

300 více možností
(Ruština) Více možností)
Vzhledem k URI existuje několik možností, jak poskytnout zdroj podle typu MIME, jazyka nebo jiných charakteristik. Server se zprávou odešle seznam alternativ, což klientovi nebo uživateli umožní vybrat si.

301 Trvale přesunuto
(Ruština) Trvale přesunuto)
Požadovaný dokument byl nakonec přesunut na nový identifikátor URI uvedený v poli Umístění v záhlaví. Pro požadavky jiné než metoda HEAD musí server odeslat hypertextové vysvětlení v těle zprávy. Při použití všech metod kromě GET a POST musíte nejprve upozornit uživatele, že se odkaz změnil. Nezapomeňte, že někteří agenti po přesunu na jinou adresu omylem změní metodu POST na GET.

302 Nalezeno
(Ruština) Nalezeno)
Požadovaný dokument byl dočasně přesunut na jiný identifikátor URI uvedený v poli Umístění v záhlaví. U všech metod kromě HEAD musí server odeslat hypertextové vysvětlení v těle. Při použití všech metod jiných než GET a POST musíte nejprve upozornit uživatele, že se identifikátor URI změnil. Při přístupu k dalšímu prostředku by se metoda POST měla změnit na GET, jak to někteří agenti dělají.

303 Viz Ostatní
(Ruština) Zobrazit další)
Dokument na požadovaném URI musí být vyžádán na adresu v poli Umístění hlavičky pomocí metody GET, i když byl vyžádán první Metoda POST. Pokud není použita metoda HEAD, pak by server MĚL do těla zprávy zahrnout krátký hypertextový popis.

304 Nezměněno
(Ruština) Nezměněno)
Server tento kód vrátí, pokud klient požadoval dokument pomocí metody GET, použil pole Datum v záhlaví a dokument se od zadaného okamžiku nezměnil. V tomto případě by zpráva serveru neměla obsahovat tělo.

305 Použijte proxy
(Ruština) Použít proxy)
Požadavek na požadovaný zdroj musí být proveden prostřednictvím proxy serveru, jehož URI je uvedeno v poli Umístění v záhlaví. Tento kód odezvy mohou používat pouze nativní servery HTTP (nikoli proxy).

306 (rezervováno)
(Ruština) Rezervováno)
Používané dříve. Momentálně rezervováno.

307 Dočasné přesměrování
(Ruština) Dočasné přesměrování)
Požadovaný zdroj krátká doba přístupné pouze pomocí jiného URI (uvedeného v poli Umístění v záhlaví). Pokud nebyla odeslána metoda HEAD, pak by server MĚL do těla zprávy zahrnout krátký hypertextový popis. Při použití všech metod kromě GET a POST musíte nejprve upozornit uživatele na dočasnou změnu odkazu.

4xx: 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.

400 Špatný požadavek
(Ruština) Špatný požadavek)
Požadavek nebyl serverem pochopen kvůli chybě syntaxe. Klient by měl znovu získat přístup k prostředku s upraveným požadavkem.

401 Neoprávněně
(Ruština) Neoprávněný)
Požadavek vyžaduje identifikaci uživatele. Klient si musí od uživatele vyžádat uživatelské jméno a heslo a předat je položkám hlavičky WWW-Authenticate v dalším požadavku. Pokud zadáte nesprávná data, server vrátí znovu stejný stav.

402 Je vyžadována platba
(Ruština) Vyžadována platba (rezervováno))
Určeno k použití v budoucnu. V současné době se nepoužívá.

403 Zakázáno
(Ruština) Zakázáno)
Server požadavek pochopil, ale odmítá ho splnit kvůli určitým omezením přístupu. Zde nepomůže autentizace HTTP. S největší pravděpodobností se server potřebuje autentizovat jiným způsobem, provést požadavek s určitými parametry nebo splnit nějaké podmínky.

404 Nenalezeno
(Ruština) Nenalezeno)
Server rozuměl požadavku, ale nenašel odpovídající zdroj na zadaném URI. Pokud server ví, že na této adrese byl dokument, bylo by vhodné místo toho použít kód 410. Tento kód lze použít místo 403, pokud se před ním chcete pečlivě skrýt zvědavýma očima určité zdroje.

Metoda 405 není povolena
(Ruština) Metoda není podporována)
Metodu zadanou klientem nelze použít na prostředek. Server musí také odeslat pole Allow v hlavičce odpovědi se seznamem dostupných metod.

406 Nepřijatelné
(Ruština) Nepřijatelné)
Požadovaný identifikátor URI nemůže splňovat vlastnosti předané v záhlaví. Pokud metoda nebyla HEAD, musí server vrátit seznam přijatelných charakteristik pro tento zdroj.

407 Je vyžadováno ověření proxy
(Ruština) Vyžaduje se oprávnění proxy)
Odpověď je podobná kódu 401, s tím rozdílem, že autentizace je na proxy server. Mechanismus je podobný identifikaci na běžném serveru.

408 Vypršel časový limit požadavku
(Ruština) Vypršel časový limit)
Časový limit serveru při čekání na přenos od klienta vypršel. Klient může podobný předchozí požadavek kdykoliv zopakovat.

409 Konflikt
(Ruština) Konflikt)
Požadavek nebylo možné dokončit kvůli konfliktnímu přístupu ke zdroji. To je možné například tehdy, když se dva klienti pokusí změnit zdroj pomocí metody PUT.

410 pryč
(Ruština) Smazáno)
Server odešle tuto odpověď, když byl zdroj na zadaném URI, ale byl odstraněn a nyní je nedostupný. V tomto případě server nezná umístění alternativní dokument(např. kopie). Pokud má server podezření, že dokument lze v blízké budoucnosti obnovit, pak lepší pro klienta poslat kód 404.

411 Požadovaná délka
(Ruština) Požadovaná délka)
Pro zadaný prostředek musí klient zadat Content-Length v hlavičce požadavku. Bez zadání tohoto pole byste neměli opakovat požadavek na server pomocí tohoto URI.

412 Předběžná podmínka se nezdařila
(Ruština) Podmínka "nepravda")
Vráceno, pokud nebylo splněno žádné z polí hlavičky podmíněného požadavku.

413 Entita požadavku je příliš velká
(Ruština) Požadovaná data jsou příliš velká)
Vráceno, pokud server z nějakého důvodu nemůže přenést požadované množství informací. Pokud je problém dočasný, může server v odpovědi uvést čas v poli Opakovat po, po kterém lze podobný požadavek opakovat.

414 Požadavek-URI je příliš dlouhý
(Ruština) Požadovaný identifikátor URI je příliš dlouhý)
Server nemůže požadavek zpracovat, protože zadaný identifikátor URI je příliš dlouhý. Tato chyba může být spuštěna například tehdy, když se klient pokouší předat dlouhé parametry přes metoda GET, ne POST.

415 Nepodporovaný typ média
(Ruština) Nepodporovaný typ data)
Z nějakého důvodu server odmítá pracovat se zadaným datovým typem, když tato metoda.

416 Požadovaný rozsah není splnitelný
(Ruština) Požadovaný rozsah není dosažitelný)
Pole Rozsah v záhlaví požadavku specifikovalo rozsah mimo zdroj a chybělo pole If-Range. Pokud klient předal rozsah bajtů, server se může vrátit skutečná velikost v poli Content-Range v záhlaví. Tato odpověď by se neměla používat při přenosu typu multipart/byteranges.

417 Očekávání se nezdařilo
(Ruština) Co se očekává, je špatně)
Z nějakého důvodu server nemůže splnit hodnotu pole Expect v hlavičce požadavku.

422 Nezpracovatelná entita
(Ruština) Nezpracovaná instance)
Server úspěšně přijal požadavek, umí pracovat se zadaným typem dat, XML dokument v těle požadavku má správnou syntaxi, ale je tam nějaká logická chyba, kvůli které nelze provést operaci na zdroj.

423 Zamčeno
(Ruština) Blokováno)
Cílovému prostředku z požadavku je zablokováno použití zadané metody na něj.

424 Neúspěšná závislost
(Ruština) Nenaplněná závislost)
Provedení aktuálního požadavku může záviset na úspěchu jiné operace. Pokud není dokončen a z tohoto důvodu nemůže být aktuální požadavek dokončen, server vrátí kód 424.

426 Je vyžadován upgrade
(Ruština) Je vyžadována aktualizace)
Server oznamuje klientovi, že je třeba aktualizovat protokol. Záhlaví odpovědi musí obsahovat správně vytvořená pole Upgrade a Connection.

5xx: Chyba serveru

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

500 Interní server Chyba
(Ruština) Interní chyba serveru)
Žádný vnitřní chyba server, který není zahrnut v rozsahu jiných chyb třídy 5xx.

501 Neimplementováno
(Ruština) Neproveditelné)
Server nepodporuje schopnosti požadované ke zpracování požadavku. Typická odpověď pro případy, kdy server nerozumí metodě uvedené v požadavku.

502 Špatná brána
(Ruština) Špatná brána)
Server fungující jako brána nebo proxy obdržel zprávu oznamující, že selhala mezioperační operace.

Služba 503 není k dispozici
(Ruština) Služba není k dispozici)
Server dočasně nemůže zpracovávat požadavky přes technické důvody(údržba, přetížení atd.). V poli záhlaví Retry-After může server zadat čas, po kterém je klientovi doporučeno opakovat požadavek. I když je zřejmou možností okamžité přerušení připojení během přetížení, může být efektivnější nastavit pole Opakovat-po na vysokou hodnotu, aby se snížila frekvence nadbytečných požadavků.

504 Časový limit brány
(Ruština) Brána nereaguje)
Server fungující jako brána nebo proxy nečekal na odpověď od nadřazeného serveru, aby dokončil aktuální požadavek.

505 Verze HTTP není podporována
(Ruština) Verze HTTP není podporována)
Server nepodporuje nebo odmítá podporovat verzi protokolu HTTP uvedenou v požadavku.

506 varianta také vyjednává (experimentální)
(Ruština) Možnost také odsouhlasena (experimentální))
V důsledku chybné konfigurace ukazuje vybraná možnost sama na sebe, což způsobí přerušení procesu párování.

507 Nedostatek úložiště
(Ruština) Došel prostor)
K dokončení aktuálního požadavku není dostatek místa. Problém může být dočasný.

510 Neprodlouženo
(Ruština) Není rozšířeno)
Server nemá rozšíření, které klient plánuje použít. Server může dodatečně přenášet informace o rozšířeních, která má k dispozici.

Takže po zvládnutí materiálu prezentovaného na tomto webu a nezávislých pokusů učení HTML a CSS byste měli být schopni vytvářet webové stránky základní a téměř základní složitosti. Ale věřím, že je důležité nejen umět plnit zadané úkoly, ale také rozumět tomu, jak vaše rozhodnutí fungují na všech úrovních organizace. Nástroj, který vám může pomoci se tomu přiblížit, je prohlížení HTTP hlaviček odeslaných vaším prohlížečem na webový server a naopak.

Ve výše uvedeném článku kromě teoretické informace Byly také poskytnuty výpisy HTTP hlaviček používaných prohlížečem při vytváření požadavku domovskou stránku webové stránky ya.ru a obsažené v odpovědi webového serveru na odpovídající požadavek. Mnohem zajímavější (a užitečnější) je ale vidět, jak váš server reaguje na požadavky z prohlížeče vašich stránek. Později, při vytváření chytrých HTML stránek, se to stane klíčem k pochopení principů aktivní interakce mezi uživatelem a webem.

Jako nástroj pro prohlížení HTTP hlaviček doporučuji použít plugin pro Prohlížeč FireFox LiveHTTPHeaders. Můžete to nainstalovat takto: Nástroje - Doplňky - Vyhledejte doplňky, vyhledejte slovo "headers", nainstalujte LiveHTTPHeaders. Po restartu prohlížeče se objeví nová funkce: Nástroje - Zobrazení HTTP hlaviček.

Doporučuji vyzkoušet plugin na stránce vytvořené v předchozí lekci. Otevřete okno „Zobrazit záhlaví HTTP“, kliknutím na „vymazat“ odstraňte zobrazená záhlaví (po zobrazení výzvy domovskou stránku prohlížeč atd.). Dále provedeme požadavek na stránku, například http://test-domain2/. V okně záhlaví se objevila záhlaví z požadavků prohlížeče az odpovědí webového serveru:

Záznam se skládá ze tří bloků: nejprve přichází URL požadované stránky, poté přes prázdný řádek HTTP hlavičky nalezené v HTTP požadavku pro tuto stránku a nakonec HTTP hlavičky nalezené v HTTP odpovědi webového serveru. . Záznamy jsou odděleny řádky.

Aby prohlížeč vygeneroval webovou stránku, odešle na webový server několik požadavků: samotný kód stránky, soubory stylu CSS, obrázky atd. Všechny tyto požadavky se promítnou do formuláře. První je požadavek HTML stránky:

GET / HTTP/1.1 Host: test-domain2 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2) Gecko/20100115 Firefox/3.6 Přijmout: text/html,application/xhtml+ xml ,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251 , utf-8;q=0,7,*;q=0,7 Keep-Alive: 115 Connection: keep-alive Pragma: no-cache Cache-Control: no-cache

na které server odpověděl:

HTTP/1.1 200 OK Datum: Pá, 04. června 2010 08:52:09 GMT Server: Poslední úprava Apache: Středa, 26. května 2010 11:34:58 GMT Etag: "3000000002878-20ca-48777dacept" Acceptes: Content-Length: 8394 Keep-Alive: timeout=5, max=100 Připojení: Keep-Alive Content-Type: text/html; znaková sada=UTF-8

V hlavičce HTTP odpovědi můžete vidět název webového serveru, velikost stránky v bajtech a její kódování. Připomínám, že plugin zobrazuje HTTP hlavičky, které jsou součástí HTTP paketu. Jeho druhá část, tělo balíčku, není zobrazena. Zde je ale vše jednoduché: běžné požadavky na stránky/soubory nemají v paketu tělo (o neobvyklých se dozvíme později) a tělo v odpovědi představuje obsah požadované stránky/souboru, který obdrží prohlížeče.

Seznam stavových kódů HTTP

Stavový kód HTTP je součástí prvního řádku odpovědi serveru. Je to celé číslo složené ze tří arabských číslic. První číslice označuje třídu podmínky. Po kódu odpovědi obvykle následuje vysvětlující fráze v angličtině oddělená mezerou, která dané osobě vysvětluje důvod této konkrétní odpovědi.

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 odpovídajících RFC. Nové kódy by měly být zavedeny pouze po dohodě s IETF. Jsou však známy dva kódy, které se používají a které nejsou uvedeny v RFC: (zavedené společností Microsoft) a (zavedené v cPanel).

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ů.

webový server Internet společnosti Microsoft Informační služba ve svých souborech protokolu kromě standardních stavových kódů používá podkódy a zapisuje je s tečkou za hlavním. Zároveň se tento subkód neumisťuje do odpovědí ze serveru - potřebuje ho administrátor serveru, aby mohl přesněji určit zdroje problémů. Seznam dílčích kódů IIS naleznete v dokumentu "IIS Status Codes" ve znalostní bázi Microsoft Knowledge Base.

1xx: Informační

Tato třída obsahuje kódy, které informují o procesu přenosu. V HTTP/1.0 by zprávy s takovými 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 nemusí na server nic posí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 musí takové zprávy odesílat dále ze serveru klientovi.

100 Pokračujte- Server je spokojen s počáteční informací o požadavku, klient může pokračovat v odesílání hlaviček. Zavedeno v HTTP/1.1.

101 Přepínací protokoly- Server vás vyzve k výběru jiného protokolu, který je vhodnější tento zdroj. Protokoly nabízené serverem jsou uvedeny v řádku Update header, pokud serverem navržený protokol vyhovuje klientovi, odešle nový požadavek s uvedením nového protokolu. Vyskytuje se ve verzi protokolu HTTP/1.1.

102 Zpracování- Žádost byla přijata, ale její zpracování bude trvat dlouho. Používá se serverem, aby zabránil klientovi přerušit připojení kvůli vypršení časového limitu. Po obdržení takové odpovědi musí klient resetovat časovač a čekat na další příkaz jako obvykle. Zavedeno ve WebDAV.

105 Název není vyřešen- Při překládání názvu domény došlo k chybě kvůli nesprávné nebo chybějící IP adrese serveru DNS.

2xx: Úspěch

Zprávy této třídy informují o případech úspěšného přijetí a zpracování požadavku klienta. V závislosti na stavu může server také přenášet záhlaví a tělo zprávy.

200 v pořádku- Úspěšná žádost. Pokud si klient vyžádal nějaká data, jsou nalezena v hlavičce a/nebo těle zprávy. Zavedeno v HTTP/1.0.

201 Vytvořeno- V důsledku úspěšného provedení požadavku byl vytvořen nový zdroj. Server musí uvést své umístění v záhlaví Location. Doporučuje se, aby server také uvedl charakteristiky vytvořeného zdroje v záhlaví (například v poli Content-Type). Pokud si server není jistý, že v době, kdy klient obdrží tuto zprávu, bude zdroj skutečně existovat, je lepší použít odpověď s kódem . Zavedeno v HTTP/1.0.

202 Přijato- Žádost byla přijata ke zpracování, ale nebyla dokončena. Klient nemusí čekat na konečný přenos zprávy, protože může začít velmi dlouhý proces. Zavedeno v HTTP/1.0.

203 Neautoritativní informace- Podobné jako u odpovědi, ale v tomto případě nebyly přenášené informace převzaty z primárního zdroje (záloha, jiný server atd.), a proto nemusí být aktuální. Zavedeno v HTTP/1.1.

204 Žádný obsah- Server úspěšně zpracoval požadavek, ale odpověď obsahovala pouze hlavičky bez těla zprávy. Klient nemusí aktualizovat obsah dokumentu, ale může na něj aplikovat přijatá metadata. Zavedeno v HTTP/1.0.

205 Obnovit obsah- Server zavazuje klienta k resetování uživatelem zadaných údajů. Server nepřenáší tělo zprávy a není nutné dokument aktualizovat. Zavedeno v HTTP/1.1.

206 Částečný obsah- Server úspěšně dokončil částečný požadavek GET a vrátil pouze část zprávy. V hlavičce Content-Range server specifikuje bajtové rozsahy obsahu. Při práci s takovými odpověďmi je třeba věnovat zvláštní pozornost ukládání do mezipaměti. Zavedeno v HTTP/1.1.

207 Vícestav- Server přenáší výsledky několika nezávislých operací najednou. Jsou umístěny v samotném těle zprávy jako XML dokument s vícestavovým objektem. Do tohoto objektu se nedoporučuje umisťovat stavy z řady 1xx z důvodu nesmyslnosti a redundance. Zavedeno ve WebDAV.

Využito 226 IM- Hlavička A-IM od klienta byla úspěšně přijata a server vrací obsah s ohledem na zadané parametry. Zavedeno v RFC 3229 k rozšíření protokolu HTTP o podporu delta kódování.

3xx: Přesměrování

Kódy třídy 3xx sdělují klientovi, že aby operace uspěla, musí být proveden jiný požadavek (obvykle na jiný URI). Existuje pět kódů z této třídy a vztahují se přímo k přesměrování (jarg: redirect). Adresa, na kterou by měl klient odeslat požadavek, je uvedena serverem v hlavičce Location. Je však možné použít fragmenty v cílovém URI.

Podle nejnovějších standardů může klient přesměrovat automaticky (bez požadavku uživatele) pouze v případě, že je druhý zdroj požadován metodou GET nebo HEAD. Předchozí specifikace uváděly, že aby se uživatel vyhnul zpáteční cestě, měl by být dotázán po 5. po sobě jdoucím přesměrování. U všech přesměrování, pokud metoda nebyla HEAD, pak by měla být v těle odpovědi zahrnuta krátká hypertextová zpráva s cílovou adresou, aby pokud se něco stalo, mohl uživatel provést přechod sám.

Vývojáři HTTP poznamenávají, že mnoho klientů při přesměrování pomocí kódů omylem aplikuje metodu GET na druhý zdroj, a to navzdory skutečnosti, že požadavek na první byl s jinou metodou. Aby se předešlo nedorozuměním, byly ve verzi HTTP/1.1 zavedeny kódy a namísto . Metodu musíte změnit pouze v případě, že server odpověděl. V ostatních případech proveďte další požadavek pomocí původní metody.

300 více možností- Pro zadané URI existuje několik možností pro poskytnutí zdroje podle typu MIME, podle jazyka nebo podle jiných charakteristik. Server se zprávou odešle seznam alternativ, což klientovi nebo uživateli umožní automaticky provést volbu. Zavedeno v HTTP/1.0.

301 Trvale přesunuto- Požadovaný dokument byl nakonec přesunut na nové URI zadané v poli Umístění v záhlaví. Někteří klienti se při zpracování tohoto kódu chovají nesprávně. Zavedeno v HTTP/1.0.

302 Dočasně přesunuto / nalezeno- Požadovaný dokument je dočasně dostupný na jiném URI zadaném v záhlaví v poli Umístění. Tento kód lze použít například při vyjednávání obsahu řízeného serverem. Někteří klienti se při zpracování tohoto kódu chovají nesprávně. Zavedeno v HTTP/1.0.

303 Viz Ostatní- Dokument na požadovaném URI musí být vyžádán na adresu v poli Umístění v hlavičce pomocí metody GET, i když první byl požadován jinou metodou. Tento kód byl zaveden spolu s kódem 307, aby se předešlo nejednoznačnosti, aby si server mohl být jistý, že další zdroj bude požadován pomocí metody GET. Například webová stránka má pole pro zadávání textu pro rychlou navigaci a vyhledávání. Po zadání údajů provede prohlížeč požadavek metodou POST včetně zadaného textu v těle zprávy. Pokud je detekován dokument se zadaným názvem, server odpoví kódem a označí jej v hlavičce Umístění Trvalá adresa. Pak si jej prohlížeč zaručeně vyžádá pomocí metody GET k získání obsahu. V opačném případě server jednoduše vrátí stránku s výsledky vyhledávání klientovi. Zavedeno v HTTP/1.1.

304 Nezměněno- Server tento kód vrátí, pokud klient požadoval dokument pomocí metody GET, použil hlavičku If-Modified-Since nebo If-None-Match a dokument se od zadaného okamžiku nezměnil. V tomto případě by zpráva serveru neměla obsahovat tělo. Zavedeno v HTTP/1.0.

305 Použijte proxy- Požadavek na požadovaný zdroj musí být proveden prostřednictvím proxy serveru, jehož URI je uvedeno v poli Umístění v záhlaví. Tento kód odezvy mohou používat pouze původní servery HTTP (nikoli proxy). Zavedeno v HTTP/1.1.

306 (Vyhrazeno, kód použitý pouze v dřívějších specifikacích)- Dříve použitý kód odpovědi je aktuálně rezervován. Zmíněno v RFC 2616 (aktualizace HTTP/1.1).

307 Dočasné přesměrování- Požadovaný zdroj je krátce dostupný na jiném URI specifikovaném v poli Umístění v záhlaví. Tento kód byl zaveden spolu s 302 namísto 302, aby se předešlo nejednoznačnosti. Zavedeno v RFC 2616 (aktualizace HTTP/1.1).

4xx: 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.

400 špatný požadavek- Server zjistil chybu syntaxe v požadavku klienta. Zavedeno v HTTP/1.0.

401 Neoprávněně- Pro přístup k požadovanému zdroji je vyžadováno ověření. Hlavička odpovědi musí obsahovat pole WWW-Authenticate se seznamem podmínek ověření. Klient může požadavek zopakovat tak, že do hlavičky zprávy zahrne pole Autorizace s údaji potřebnými pro autentizaci.

402 Je vyžadována platba- Určeno k použití v budoucnu. V současné době se nepoužívá. Tento kód je určen pro placené uživatelské služby, nikoli pro hostingové společnosti. To znamená, že tuto chybu poskytovatel hostingu nevydá v případě prodlení s platbou za jeho služby. Rezervováno od HTTP/1.1.

403 Zakázáno- Server požadavek pochopil, ale odmítá ho splnit z důvodu omezení přístupu klienta k určenému zdroji. Pokud je pro přístup ke zdroji vyžadována autentizace pomocí HTTP, server vrátí odpověď nebo pokud je použit proxy. Jinak byla omezení nastavena správcem serveru nebo vývojářem webové aplikace a mohou být jakákoliv v závislosti na možnostech použitého softwaru. V každém případě by měl být klient informován o důvodech odmítnutí vyřízení žádosti. Většina pravděpodobné důvody omezení mohou vyplývat z pokusu o přístup k systémovým zdrojům webového serveru (například k souborům .htaccess nebo .htpasswd) nebo souborům, ke kterým byl přístup odepřen pomocí konfigurační soubory, požadavek na jiné než HTTP ověření, například pro přístup do redakčního systému nebo sekce pro registrované uživatele, nebo server není spokojen s IP adresou klienta, například při blokování. Zavedeno v HTTP/1.0.

404 Nenalezeno- Nejčastější chyba při používání internetu, hlavním důvodem je chyba v psaní adresy webové stránky. Server rozuměl požadavku, ale nenašel odpovídající zdroj na zadaném URI. Pokud server ví, že na této adrese byl dokument, je vhodné, aby použil kód. Odpověď lze použít místo toho, pokud potřebujete pečlivě skrýt určité zdroje před zvědavýma očima. Zavedeno v HTTP/1.0.

Metoda 405 není povolena- Metodu zadanou klientem nelze použít na aktuální zdroj. V odpovědi musí server uvést dostupné metody v hlavičce Allow, oddělené čárkou. Server musí vrátit tuto chybu, pokud je mu metoda známá, ale není použitelná konkrétně pro zdroj uvedený v požadavku, pokud zadaná metoda není použitelná na celém serveru, pak klient musí vrátit kód (Neimplementováno ). Zavedeno v HTTP/1.1.

406 Nepřijatelné- Požadovaný identifikátor URI nemůže splňovat vlastnosti předané v záhlaví. Pokud metoda nebyla HEAD, musí server vrátit seznam přijatelných charakteristik pro tento zdroj. Zavedeno v HTTP/1.1.

407 Je vyžadováno ověření proxy- Odpověď je podobná kódu kromě toho, že autentizace se provádí pro proxy server. Mechanismus je podobný identifikaci na původním serveru. Zavedeno v HTTP/1.1.

408 Vypršel časový limit požadavku- Serveru vypršel časový limit čekání na přenos z klienta. Klient může podobný předchozí požadavek kdykoliv zopakovat. Tato situace může nastat například při nahrávání velkého souboru na server pomocí metody POST nebo PUT. V určitém okamžiku přenosu datový zdroj přestal reagovat například z důvodu poškození CD nebo ztráty komunikace s jiným počítačem v lokální síti. Zatímco klient nic nepřenáší, čeká na odpověď od něj, spojení se serverem je udržováno. Po nějaké době může server ukončit připojení na svém konci, aby umožnil ostatním klientům vznést požadavek. Tato odpověď není vrácena, když klient násilně zastaví přenos na příkaz uživatele nebo je spojení přerušeno z nějakého jiného důvodu, protože odpověď již nelze odeslat. Zavedeno v HTTP/1.1.

409 Konflikt- Požadavek nebylo možné dokončit kvůli konfliktnímu přístupu ke zdroji. To je možné například tehdy, když se dva klienti pokusí změnit prostředek pomocí metody PUT, která je zavedena v HTTP/1.1.

410 pryč (smazáno)- Server odešle tuto odpověď, pokud byl zdroj na zadané adrese URL, ale byl odstraněn a nyní je nedostupný. V tomto případě server nezná umístění alternativního dokumentu, například kopie). Pokud má server podezření, že dokument může být v blízké budoucnosti obnoven, je lepší předat kód klientovi. Zavedeno v HTTP/1.1.

411 Požadovaná délka- Pro zadaný zdroj musí klient zadat Content-Length v hlavičce požadavku. Bez zadání tohoto pole byste neměli opakovat požadavek na server pomocí tohoto URI. Tato odpověď je pro dotazy přirozená Typ POST a PUT. Například pokud jsou soubory stahovány pomocí zadaného identifikátoru URI a server má limit na jejich velikost. Pak by bylo rozumnější hned na začátku zkontrolovat hlavičku Content-Length a stahování okamžitě odmítnout, než vyprovokovat nesmyslnou zátěž přerušením spojení, když klient skutečně odešle příliš velkou zprávu. Zavedeno v HTTP/1.1.

412 Předběžná podmínka se nezdařila- Vráceno, pokud nebylo splněno žádné z polí hlavičky podmíněného požadavku. Zavedeno v HTTP/1.1.

413 Entita požadavku je příliš velká- Vráceno, pokud server odmítne zpracovat požadavek z důvodu příliš velkého těla požadavku. Server může uzavřít spojení, aby zastavil další přenos požadavku. Pokud je problém dočasný, doporučuje se zahrnout do odpovědi serveru hlavičku Retry-After označující dobu, po které lze podobný požadavek opakovat. Zavedeno v HTTP/1.1.

414 Požadavek-URI je příliš velký- Server nemůže zpracovat požadavek, protože zadaná adresa URL je příliš dlouhá. Tato chyba může být spuštěna například tehdy, když se klient pokusí předat dlouhé parametry pomocí metody GET spíše než metody POST. Zavedeno v HTTP/1.1.

415 Nepodporovaný typ média- Z nějakého důvodu server odmítá pracovat se zadaným datovým typem pomocí této metody. Zavedeno v HTTP/1.1.

416 Požadovaný rozsah není splnitelný- v poli Range hlavičky požadavku byl zadán rozsah mimo zdroj a chybělo pole If-Range. Pokud klient předal rozsah bajtů, může server vrátit skutečnou velikost v poli Content-Range v záhlaví. Tato odpověď by se neměla používat při přenosu typu multipart/byteranges. Zavedeno v RFC 2616 (aktualizace HTTP/1.1).

417 Očekávání se nezdařilo- Z nějakého důvodu server nemůže splnit hodnotu pole Expect v hlavičce požadavku. Zavedeno v RFC 2616 (aktualizace HTTP/1.1).

418 Jsem čajová konvice (jsem čajová konvice)- Tento kód byl představen v roce 1998 jako jeden z tradičních aprílových žertíků IETF v RFC 2324, Hyper Text Coffee Pot Control Protocol. To se neočekává tento kód budou podporovány skutečnými servery.

422 Nezpracovatelná entita- Server úspěšně přijal požadavek, může pracovat se zadaným typem dat, XML dokument v těle požadavku má správnou syntaxi, ale je tam nějaká logická chyba, kvůli které nelze provést operaci zdroj. Zadáno do WebDAV.

423 Zamčeno- Cílovému prostředku z požadavku je zablokováno použití zadané metody na něj. Zadáno do WebDAV.

424 Neúspěšná závislost- Realizace aktuálního požadavku může záviset na úspěchu jiné operace. Pokud není dokončen a z tohoto důvodu nemůže být aktuální požadavek dokončen, server tento kód vrátí. Zadáno do WebDAV.

425 Neobjednaná kolekce- používá se v rozšíření WebDAV Advanced Collections Protocol. Odesláno, pokud klient zadal číslo prvku v neuspořádaném seznamu nebo požadoval více prvků v pořadí odlišném od pořadí serveru.

426 Je vyžadován upgrade- Server signalizuje klientovi nutnost aktualizovat protokol. Záhlaví odpovědi musí obsahovat správně vytvořená pole Upgrade a Connection. Zavedeno v RFC 2817, aby umožnilo přechod na TLS přes HTTP.

428 Předběžná podmínka je vyžadována- Server signalizuje klientovi nutnost použít v požadavku hlavičky podmínek, jako je If-Match. Uvedeno v návrhu RFC 6585.

429 Příliš mnoho požadavků- Klient se pokusil odeslat příliš mnoho požadavků v krátkém čase, což by mohlo naznačovat například pokus o DoS útok. Může být doprovázeno hlavičkou Retry-After udávající, po jaké době lze požadavek opakovat. Uvedeno v návrhu RFC 6585.

431 Pole záhlaví požadavku jsou příliš velká- Byla překročena přípustná délka sběračů. Server nemusí odpovídat pomocí tohoto kódu, může jednoduše resetovat připojení. Uvedeno v návrhu RFC 6585.

434 Požadovaný hostitel není k dispozici. (Požadovaná adresa není k dispozici)- Požadovaná adresa není k dispozici.

449 Opakovat s- Vráceno serverem, pokud nebyly od klienta přijaty dostatečné informace pro zpracování požadavku. V tomto případě je pole Ms-Echo-Request umístěno v hlavičce odpovědi. Představeno společností Microsoft pro WebDAV. V současné době minimálně v provozu program Microsoft Peníze.

451 nedostupné z právních důvodů- Přístup ke zdroji je uzavřen z právních důvodů, například na žádost státních orgánů nebo na žádost držitele autorských práv v případě porušení autorských práv. Uvedeno v návrhu IETF společností Google, přičemž chybový kód je odkazem na román Raye Bradburyho Fahrenheit 451.

456 Neopravitelná chyba- Vráceno serverem, pokud zpracování požadavku způsobí neopravitelné chyby v databázových tabulkách. Představeno společností Microsoft pro WebDAV.

499 () - Používá Nginx, když klient uzavře připojení před obdržením odpovědi.

5xx: Chyba serveru

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

500 Interní chyba serveru- Jakákoli interní chyba serveru, která není zahrnuta v rozsahu jiných chyb třídy. Zavedeno v HTTP/1.0.

501 Neimplementováno- Server nepodporuje schopnosti požadované ke zpracování požadavku. Typická odpověď pro případy, kdy server nerozumí metodě uvedené v požadavku. Pokud je metoda známa serveru, ale není použitelná pro tento prostředek, musíte vrátit odpověď. Zavedeno v HTTP/1.0.

502 Špatná brána- Server, který funguje jako brána nebo proxy, obdržel neplatnou odpověď od nadřazeného serveru. Zavedeno v HTTP/1.0.

Služba 503 není k dispozici- Server není dočasně schopen z technických důvodů (údržba, přetížení atd.) zpracovávat požadavky. V poli záhlaví Retry-After může server zadat čas, po kterém je klientovi doporučeno opakovat požadavek. I když se může zdát samozřejmé okamžitě přerušit spojení během přetížení, může být efektivnější nastavit pole Opakovat-After na vysokou hodnotu, aby se snížila frekvence redundantních požadavků. Zavedeno v HTTP/1.0.

504 Časový limit brány (brána nereaguje)- Server fungující jako brána nebo proxy server nečekal na odpověď od nadřazeného serveru, aby dokončil aktuální požadavek. Zavedeno v HTTP/1.1.

505 Verze HTTP není podporována- Server nepodporuje nebo odmítá podporovat verzi protokolu HTTP uvedenou v požadavku. Zavedeno v HTTP/1.1.

506 Varianta také vyjednává- V důsledku chybné konfigurace ukazuje vybraná možnost sama na sebe, což způsobí přerušení procesu párování. Experimentální. Zavedeno v RFC 2295 jako doplněk protokolu HTTP o technologii Transparent Content Negotiation.

507 Nedostatek úložiště- Není dostatek místa k dokončení aktuálního požadavku. Problém může být dočasný. Zadáno do WebDAV.

Zjištěna smyčka 508 -

509 Šířka pásma Limit překročen(Vyčerpaná šířka pásma kanálu)- Používá se, když webová stránka překročí svůj přidělený limit spotřeby provozu. V v tomto případě Vlastník webu by měl kontaktovat svého poskytovatele hostingu. V současné době není tento kód popsán v žádném RFC a používá jej pouze modul „bw/limited“ obsažený v ovládacím panelu hosting cPanel, kde byl představen.

510 Neprodlouženo- Server nemá rozšíření, které chce klient používat. Server může dodatečně přenášet informace o rozšířeních, která má k dispozici. Zavedeno v RFC 2774 pro přidání podpory pro rozšíření protokolu HTTP.

511 Vyžaduje se síťové ověření- Tuto odpověď nezasílá server, kterému byl požadavek určen, ale zprostředkující server - například server poskytovatele - v případě, že se klient musí nejprve přihlásit do sítě, například zadat heslo pro placenou službu Přístupový bod k internetu. Předpokládá se, že tělo odpovědi vrátí webový autorizační formulář nebo na něj přesměruje. Uvedeno v návrhu RFC 6585.

HTTP hlavičky se používají k výměně informací o službách mezi klientem a serverem. Tyto informace zůstávají pro uživatele neviditelné, ale bez nich to nejde správná práce prohlížeč. Pro běžní uživatelé Informace o tomto a účelu http hlaviček se budou zdát poměrně složité, ale ve skutečnosti neobsahují obtížné formulace. S tím se uživatel webu setkává každý den.

titulky?

„Hypertext Transfer Protocol“ je přesně to, co se překládá Díky jeho existenci je možná komunikace klient-server. Jednoduše řečeno, uživatel prohlížeče odešle požadavek a zahájí připojení k serveru. Ten standardně čeká na požadavek od klienta, zpracuje ho a pošle zpět finální informaci či odpověď. Do vyhledávacího pole uživatel „vrazí“ adresu webu, která začíná http:// a obdrží výsledek ve formě stránky, která se otevře.

Po zadání adresy webu do příslušného řádku prohlížeč vyhledá požadovaný server pomocí DNS. Server rozpozná hlavičku http (jedno nebo více), kterou mu klient odešle, a poté vydá požadovanou hlavičku. Sada požadovaných se skládá z již existujících a nenalezených hlaviček.

Obecně jsou hlavičky http docela efektivní. Nejsou viditelné v kódování HTML, jsou odesílány před požadovanou informací. Mnoho hlaviček je automaticky odesíláno serverem. Chcete-li jej odeslat na jazyk PHP, měli byste použít funkci záhlaví.

Interakce mezi prohlížečem a webem

Interakce mezi prohlížečem a webem je poměrně jednoduchá. Takže hlavička http začíná řádek požadavku, který je poté odeslán na server. Přichází odpověď potřebuje klient informace. Mimochodem, na internetu je již sedmnáct let nejpoužívanější protokol http. Je to jednoduché, spolehlivé, rychlé a flexibilní. Hlavním úkolem http je vyžadovat informace z webového serveru. Klient je prohlížeč a server je ligthttp, apache, nginx. Pokud bylo spojení mezi nimi úspěšné, server obdrží potřebné informace jako odpověď na požadavek. http informace obsahuje text, zvukové soubory, video.

Protokol může být přenosem pro ostatní. Požadavek klienta se skládá ze tří částí:

• startovní řádek (typ zprávy);
• záhlaví (parametry zpráv);
• informační tělo (zpráva oddělená prázdným řádkem).

Počáteční řádek je povinným prvkem požadavku pole záhlaví http. Struktura uživatelského požadavku se skládá ze tří hlavních částí:

1. Metoda. Používá se k označení typu požadavku.
2. Cesta. Tento Řetězec URL, který následuje za doménou.
3. Použitý protokol. Skládá se z protokolu a verze http.

Moderní prohlížeče používají verzi 1.1. Následují hlavičky ve formátu "Název: hodnota".

HTTP mezipaměť

Podstatou je, že ukládání do mezipaměti zajišťuje ukládání HTML stránek a dalších souborů do mezipaměti (prostor v operační paměti, na pevném disku počítače). To je nezbytné pro urychlení opakovaného přístupu k nim a úsporu provozu.

Mezipaměť má klientský prohlížeč, zprostředkující bránu a proxy server. Před odesláním zprávy na URL prohlížeč zkontroluje, zda je objekt v mezipaměti. Pokud neexistuje žádný objekt, je požadavek předán dalšímu serveru, kde je zkontrolován http mezipaměť titulky zapnuté server nginx. Používají se brány a proxy různými uživateli, takže cache je sdílená.

HTTP caching může nejen výrazně zrychlit web, ale také poskytnout starou verzi stránky. To se používá k odesílání hlaviček odpovědi. Informace požadované prostřednictvím protokolu HTTPS však nelze uložit do mezipaměti.

Popis hlaviček http

Jedním z nejdůležitějších mechanismů mezipaměti je http expiruje hlavičky. Tato záhlaví označují datum vypršení platnosti informací uvedených v odpovědi. Označují čas a datum, kdy bude keš považována za neaktuální. Takové záhlaví vypadá například takto: Expires: Wen, 30 Nov 2016 13:45:00 GMT. Tato struktura používá se téměř všude, včetně ukládání stránek a obrázků do mezipaměti. Pokud uživatel vybere staré datum, informace nebudou uloženy do mezipaměti.

Záhlaví HTTP proxy patří do kategorie odkazu záhlaví. Ve výchozím nastavení se neukládají do mezipaměti. Aby mezipaměť fungovala správně, musí každá adresa URL odpovídat jedné variantě obsahu. Pokud je stránka dvojjazyčná, měla by mít každá verze svou vlastní adresu URL. Hlavička vary sděluje mezipaměti názvy hlaviček požadavků. Pokud například zobrazení požadavku závisí na prohlížeči, server musí také odeslat záhlaví. V mezipaměti jsou tedy uloženy různé možnosti dotazů a typy dokumentů. Hlavička TTP accept je nezbytná pro sestavení seznamů přijatelných formátů použitého zdroje, je s ní poměrně snadné pracovat, protože filtruje nepotřebné.

Existují celkem čtyři skupiny hlaviček, které přenášejí servisní informace. Toto jsou základní hlavičky – jsou obsaženy v jakékoli zprávě serveru a klienta, požadavku a odpovědi a entity. Ten popisuje obsah jakékoli zprávy od klienta a serveru.

Autorizační hlavička HTTP je považována za volitelnou. Když webová stránka požádá klienta o autorizaci, prohlížeč zobrazí speciální okno s poli pro zadání přihlašovacího jména a hesla. Poté, co uživatel zadá své údaje, prohlížeč odešle http požadavek. Obsahuje hlavičku „autorizace“.

Jak mohu vidět nadpisy?

Chcete-li zobrazit záhlaví http, musíte nainstalovat pluginy prohlížeče, například firefox:

• Firebug. Záhlaví si můžete prohlédnout v záložce net, kde vyberete vše. Tento plugin má funkce, které budou užitečné pro vývojáře webu.
• Živé http hlavičky. Jednoduchý plugin určený pro zobrazení hlaviček http. S jeho pomocí můžete ručně vygenerovat požadavek.
• Uživatelé Ghrome snadno uvidí záhlaví, pokud kliknou na tlačítko nastavení, vyberou vývojářské nástroje (síť).

Jakmile jsou pluginy nainstalovány, spusťte je ve svém prohlížeči.

Metody dotazování

Metody používané v HTTP jsou podobné pokynům, které se odesílají jako zpráva na server. Toto je speciální slovo v angličtině.

• metoda GET. Používá se k vyžádání informací ze zdroje. Zde začínají všechny akce.
• ZVEŘEJNIT. Slouží k odesílání dat. Například zpráva v sociální síť nebo komentář, prohlížeč jej umístí do těla požadavku POST a odešle jej na server.
• HLAVA. Metoda je podobná první, ale funguje snadná funkce. Vyžaduje pouze metadata, kromě zprávy z odpovědi. Tato metoda se používá, pokud chcete získat informace o souborech bez stahování. Používá se, pokud chtějí zkontrolovat funkčnost odkazů na serveru.
• DÁT. Načte data na adresu URL. Přenáší velké množství dat.
• MOŽNOSTI. Pracuje s konfiguracemi serveru.
• URI. Identifikuje zdroj a obsahuje adresu URL.

Struktura odpovědi HTTP

Server odpovídá na požadavky klientů dlouhé zprávy. Odpověď se skládá z několika řádků udávajících verzi protokolu a stavový kód serveru (200). Řekne vám, co se změnilo na serveru při zpracování příchozího požadavku:

1. Stav „dvě stě“ označuje úspěšné zpracování informace. Server poté odešle dokument klientovi. Zbývající řádky požadavku označují další informace o přenášených informacích.
2. Pokud soubor není nalezen nebo neexistuje, server odešle klientovi kód 404, který se také nazývá chyba.
3. Kód 206 označuje částečné stahování souboru, které lze po nějaké době obnovit.
4. Kód 401 označuje zamítnutí povolení. To znamená, že požadovaná stránka je chráněna heslem, které je nutné zadat pro potvrzení vstupu.
5. Kód 403 označuje zakázaný přístup. Zákazy prohlížení, stahování souborů nebo videí jsou běžnou reakcí na internetu.
6. Existují také další verze kódů: dočasný přesun požadovaného souboru, vnitřní chyba serveru, trvalý přesun. V tomto případě bude uživatel přesměrován. Pokud se objeví kód 500, znamená to, že došlo k problémům se serverem.

URL – co to je?

URL je srdcem webové komunikace mezi klientem a serverem. Požadavek se obvykle odesílá přes URL – Uniform Resource Locator. Struktura požadavku URL je velmi jednoduchá. Skládá se z několika prvků: protokol http (záhlaví), hoot (adresa webu), port, cesta ke zdroji a dotaz.

Protokol je k dispozici také pro zabezpečené připojení https a výměna informací. Adresa URL obsahuje informace o umístění konkrétního webu na internetu. Adresa obsahuje název domény, cestu ke stránce a její název.

Hlavní nevýhodou práce s URL je nepohodlná interakce s latinskou abecedou a také čísly a symboly. Optimalizace hraje v SEO důležitou roli.

Aktivní uživatelé počítačů a vývojáři se vyzývají, aby se seznámili s některými odbornými doporučeními odborníků v této oblasti:

• Uveďte data vypršení platnosti souborů a dokumentů s přihlédnutím k aktualizacím. Statistické informace uvedeno v velké hodnoty max-věk
• Jeden dokument by měl být přístupný pouze prostřednictvím jedné adresy URL.
• Pokud aktualizujete soubor, který bude stažen uživatelem, změňte jeho název a odkaz na něj. Tím je zajištěno, že se stáhne nový dokument, nikoli zastaralý.
• Nadpisy Last-Modified musí odpovídat skutečnému datu, kdy byl obsah naposledy upraven. Stránky a dokumenty byste neměli znovu ukládat, pokud je nezměníte.
• Požadavky POST používejte pouze v případě potřeby. Omezte práci SSL na minimum.
• Záhlaví by měla být před odesláním serverem zkontrolována pomocí pluginu REDbot.

Když otevřeme libovolnou webovou stránku webu, kterou potřebujeme, spolu s HTML kódem stránky server odešle stavový kód požadavku a hlavičky http. Pomocí stavového kódu mohou programy rychle zjistit, zda bylo vše úspěšné, nebo například taková stránka na serveru neexistuje. Záhlaví obsahují informace pro prohlížeč, které mu říkají, jak má stránku zpracovat a co s ní dělat.

Běžní uživatelé tyto informace potřebovat nebudou, ale pokud jste správce stránek nebo technický specialista, mohou se vám hodit. V tomto článku se podíváme na to, jak zkontrolovat kód odpovědi serveru a hlavičky http pomocí nástroje curl.

Pro normální provoz různé programy, pracující přes protokol HTTP, server vrací nejen text stránky, ale také třímístný kód, který umožňuje určit výsledek požadavku. Pomocí tohoto kódu můžete nejen popsat, k jaké chybě při zpracování došlo, ale také přesměrovat uživatele na jinou stránku nebo říci, že stránka nebyla změněna. Zde jsou nejběžnější kódy odpovědí serveru:

1xx - informační:

• 100 - server přijal první část požadavku, můžete přenos zpozdit;
• 101 - musíte změnit pracovní protokol na vhodnější;
• 102 - zpracování požadavku zabere hodně času, používá se k tomu, aby prohlížeč předem nepřerušil spojení;

2xx - operace úspěšná:

• 200 - požadavek byl úspěšně dokončen, odeslán pro většinu požadovaných stránek;
• 201 - po dokončení požadavku byl zdroj vytvořen;
• 202 - žádost byla přijata, ale ještě nebyla zpracována;
• 203 - požadavek byl úspěšně dokončen, ale informace pro odpověď byly převzaty z proxy;
• 204 - požadavek byl zpracován, ale není zde žádný obsah k zobrazení;
• 205 - požádat uživatele o zadání požadovaných údajů;
• 206 - žádost byla zpracována, ale byla přenesena pouze část obsahu;

3xx - přesměrování:

• 300 - pro tuto žádost existuje několik stránek, například v několika jazycích;
• 301 - stránka byla trvale přesunuta na novou adresu;
• 302 - dokument byl dočasně přesunut;
• 303 - dokument musí být nahrán na zadanou adresu pomocí protokolu GET;
• 304 - dokument se od poslední žádosti nezměnil;
• 305 - musíte použít proxy;
• 307 - zdroj byl dočasně přesunut na novou adresu.

4хх – chyba v požadavku:

• 400 - neplatný požadavek;
• 401 - musíte se ověřit;
• 403 - žádost byla přijata, ale nemáte přístup;
• 404 - stránka nebyla na serveru nalezena;
• 405 - použitá metoda nemůže být použita na serveru;
• 408 - vypršel časový limit přenosu požadavku;
• 410 - zdroj je zcela vymazán;
• 411 - musíte specifikovat délku požadavku;
• 413 - požadavek je příliš dlouhý;
• 414 - Identifikátor URI požadavku je příliš dlouhý.

5xx - chyba serveru:

• 500 - Interní chyba serveru;
• 501 - požadovaná funkce není podporováno;
• 502 - proxy se nemůže připojit k bráně;
• 503 - server nemůže z technických důvodů zpracovávat požadavky;
• 504 - proxy nečekal na odpověď ze serveru;
• 505 - Verze protokolu HTTP není podporována.

Co jsou hlavičky http?

S pomocí http hlavičky, klient a server si navzájem vyměňují informace a příkazy. Používají se k dohodě o metodě, protokolu, kódování, jazyku a mnoha dalších provozních parametrech. Podívejme se na hlavní hlavičky, které server odešle:

• Server- název a verze webového serveru;
• Datum- datum žádosti;
• Typ obsahu - MIME typ kódování přenášených dat, například text/html, je okamžitě nastaveno;
• Spojení- typ připojení, může být uzavřený - již uzavřený, nebo keep-alive - otevřený pro přenos dat;
• Vařit se- označuje, pod jakými hlavičkami webový server vrátí různé hodnoty pro stejný URI;
• Set-Cookie- uložit informace o cookies pro stránku;
• Platnost vyprší- stránku nebo zdroj můžete uložit do mezipaměti do určitého data;
• Cache-Control- nastavení doby ukládání stránky do mezipaměti prohlížečem a také oprávnění pro ukládání do mezipaměti;
• Etag- obsahuje kontrolní součet pro stránku použitelný pro kontrolu cache;
• Naposledy změněno- datum, kdy stránka minule byl změněn;

To vše byl úvod, abyste pochopili, co budeme dělat dál, protože zvážíme nejen to, jak zobrazit záhlaví a odezvu serveru, ale také to, jaké by měly být pro váš web.

Kontrola kódu odpovědi serveru pomocí cURL

Chcete-li zobrazit pouze kód odpovědi stránky, stačí spustit následující příkaz:

curl -s -o /dev/null -w "%(http_code)" https://site

Nebo, pokud chcete, aby odpověď vypadala přirozeněji:

curl -I https://site2>

Vráceno 200 stránek, vše v pořádku. Ale posílá server přesměrování na stránky, které potřebujeme? Pokud váš web běží na https, pak by všechny požadavky http měly být převedeny na https, a to i pro všechny stránky, na které jsou všechny požadavky www doména by měl být přesměrován na hlavní, nebo naopak. Žádosti o IP adresu webu by také měly být v ideálním případě zasílány do hlavní domény. Kontrola http odpovědi:

curl -I http://site2>/dev/null | hlava -n 1 | řez -d$" " -f2

curl -I https://www.site2>/dev/null | hlava -n 1 | řez -d$" " -f2

Vše funguje jak má. Ale je nepravděpodobné, že by bylo nutné sledovat kód odpovědi serveru, je mnohem zajímavější.

Kontrola HTTP hlaviček pomocí Curl

Pro kontrolu záhlaví můžeme také použít utilitu curl. Chcete-li zobrazit záhlaví stránek, spusťte jej s volbou -I:

curl -I https://site

Zde se zobrazí kód odpovědi serveru a také přijaté hlavičky http. Z nich můžeme vyvodit následující závěry:

• Stránka byla vygenerována v nginx 1.10.2;
• To je normální html stránku(text/html);
• Velikost stránky 102452 bajtů nebo 100 kb;
• Stránka byla naposledy upravena v 18:13:12 (last_modified) to je velmi důležitý parametr pro vyhledávače;
• Server bude poskytovat různé verze stránek, když se změní pole Accept-Encoding (Vary);
• Stránka může být uložena v libovolné mezipaměti (veřejné) po dobu jedné hodiny (vyprší);

Tímto způsobem lze zkontrolovat hlavičky http pro jakoukoli stránku nebo zdroj, aby se okamžitě zjistilo, zda se vše odesílá správně. Podívejme se například na záhlaví obrázku:

curl -I https://site/wp-content/uploads/2016/08/map-2.png

Vidíme, že obrázek bude uložen v cache mnohem déle (max-age) než html stránka.

Zbývá zkontrolovat, zda fungují hlavičky jako If-Modified-Since a If-None-Match. První umožňuje zkontrolovat relevanci keše podle data změny, druhá - podle kontrolního součtu pole ETag. Cache je velmi důležitá pro snížení zátěže vašeho serveru. Pokud se stránka nezměnila, server pouze oznámí, že se nezměnila, odesláním kódu odpovědi 304 namísto odeslání celého souboru.

Samozřejmě k tomu můžete použít online služby, ale fungují špatně a ne vždy ukazují správnou hodnotu. Proto opět používáme curl.

Kontrola If-Modified-Since

Nejprve požádáme naši stránku, aby zobrazila záhlaví http, a poté zkopírujeme pole Last-Modified:

curl -I https://site

Nyní o to žádáme znovu, ale tentokrát s záhlaví If-Modified-Since: a vaše datum:

Jako odpověď byste neměli obdržet samotnou stránku, ale pouze hlavičku HTTP/1.1 304 Not Modified. Pokud ano, pak kontrola kódu odezvy serveru prošla a vše funguje správně.

If-None-Match Check

Podobně funguje hlavička If-None-Match, pouze používá hodnotu kontrolní součet cache z pole ETag. Vyžádejme si naši stránku znovu a zkopírujeme částku:

curl -I https://site

Poté odešleme přijatou částku s hlavičkou:

curl -I --header "If-None-Match: "58615db8-19034"" https://site

A opět bychom měli dostat odpověď 304, stránka se nezměnila.

Kontrola komprese

Komprese umožňuje snížit velikost přenášených dat, ale zároveň vytváří dodatečné zatížení serveru. Chcete-li zkontrolovat, zda server podporuje komprese gzip musíte v požadavku odeslat hlavičku Accept-Encoding s parametrem gzip:

curl -I https://site --header "Accept-Encoding: gzip"

V odpovědi uvidíme pole Content-Encoding: gzip. To bude znamenat, že se používá komprese.

Závěry

V tomto článku jsme se podívali na to, jak se kontroluje odezva serveru a kontrolují se hlavičky http, což může být velmi užitečné pro audit technickou stránku vaše stránky a také k vyřešení určitých problémů. Doufám, že informace obsažené v tomto článku pro vás byly užitečné.

O autorovi

Zakladatel a správce webu, nadšený pro open source software a operační systémy Linuxový systém. V současné době používám Ubuntu jako svůj hlavní OS. Kromě Linuxu mě zajímá vše, co souvisí s informačními technologiemi a moderní vědou.