Seznam stavových kódů HTTP
Stavový kód HTTP je součástí prvního řádku odpovědi serveru na požadavky HTTP . Je to třímístné desetinné číslo. První číslice označuje třídu stavu . Po kódu odpovědi obvykle následuje mezerou oddělená vysvětlující fráze v angličtině, která dané osobě vysvětluje důvod takové odpovědi. Příklady:
- 201 Vytvořeno .
- 401 Neoprávněné .
- 507 Nedostatek úložiště .
Klient se z kódu odpovědi dozví o výsledcích svého požadavku a určí, jaké kroky podnikne dále. Sada stavových kódů je standardem a je popsána v příslušných dokumentech RFC . Zavedení nových kodexů by mělo být provedeno pouze po konzultaci s IETF . Existují však dva známé používané kódy, které nejsou uvedeny v RFC: 449 Retry With. Zmíněna je také vysvětlující fráze „Reply With“ [1] ve specifikaci pro WebDAV v Microsoft Developer Network představené společností Microsoft a 509 Bandwidth Limit Exceededpředstavené 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 Information Services 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 recenzí
Následuje přehledný seznam všech kódů odpovědí popsaných v tomto článku:
Popis kódů
Informační
Tato třída obsahuje kódy, které informují o procesu přenosu. Při práci s protokolem verze 1.0 by zprávy s takovými kódy měly být ignorovány. Ve verzi 1.1 musí být klient připraven přijmout tuto třídu zpráv jako normální odpověď, ale server nemusí nic odesílat. Samotné zprávy ze serveru obsahují pouze počáteční řádek odpovědi a v případě potřeby několik polí záhlaví specifických pro odpověď. Proxy servery by takové zprávy měly odesílat dále ze serveru klientovi.
- 100 Pokračovat - 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 Switching Protocols - Server splní požadavek klienta a přepne protokoly podle indikace uvedené v poli záhlaví Upgrade. Server odešle hlavičku odpovědi Upgradeoznačující protokol, na který přešel. Zavedeno v HTTP/1.1.
- 102 Zpracování – Požadavek byl přijat, ale jeho zpracování bude trvat dlouho. Používá se serverem, aby zabránil klientovi ukončit připojení kvůli vypršení časového limitu. Klient po obdržení takové odpovědi musí resetovat časovač a čekat na další příkaz v normálním režimu. Zobrazeno ve WebDAV .
- 103 Early Hints – Používá se k předčasnému vrácení části hlaviček, když nelze rychle vytvořit hlavičky plné odpovědi.
Ú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 odesílat také záhlaví a tělo zprávy.
- 200 OK - úspěšný požadavek. Pokud si klient vyžádal nějaká data, jsou v hlavičce a/nebo těle zprávy. Zavedeno v HTTP/1.0.
- 201 Vytvořeno - Nový zdroj byl vytvořen jako výsledek úspěšného požadavku. Server MŮŽE specifikovat adresy (může jich být více) vytvořeného zdroje v těle odpovědi, přičemž preferovaná adresa je uvedena v Location. Serveru se doporučuje uvést v těle odpovědi vlastnosti vytvářeného zdroje a jeho adresu, formát těla odpovědi je určen hlavičkou Content-Type. Při zpracování požadavku musí být před odesláním odpovědi klientovi vytvořen nový zdroj, jinak odpověď s kódem 202. Zavedeno v HTTP/1.0.
- 202 Přijato - Požadavek byl přijat ke zpracování, ale nebyl dokončen. Klient nemusí čekat na konečný přenos zprávy, protože může být spuštěn velmi dlouhý proces. Zavedeno v HTTP/1.0.
- 203 Neautoritativní informace – podobné jako 200, 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 v odpovědi byly odeslány 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 Resetovat obsah - Server zavazuje klienta k resetování dat zadaných uživatelem. Server nepřenáší tělo zprávy a dokument není třeba 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 záhlaví Content-Rangeserver 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. ( více… )
- 207 Multi-Status - 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 příponou multistatus. Do tohoto objektu se nedoporučuje umisťovat stavy ze série z důvodu 1xxnesmyslnosti a redundance. Zobrazeno ve WebDAV .
- 208 Již nahlášeno - Vazebné členy DAV již byly uvedeny v předchozí části (multistatus) odpovědi a nejsou znovu zahrnuty.
- 226 IM Used - hlavička A-IMbyla úspěšně přijata od klienta a server vrací obsah s ohledem na zadané parametry. Zavedeno v RFC 3229 k rozšíření protokolu HTTP o podporu delta kódování .
Přesměrování
Kódy v této třídě sdělují klientovi, že pro úspěšnou operaci musí být proveden další požadavek, obvykle na jiném URI . Z této třídy pět kódů 301, 302, 303a odkazuje 305přímo 307na přesměrování. Adresa, na kterou má klient zažádat, je uvedena serverem v souboru Location. To umožňuje použití fragmentů v cílovém URI.
Podle nejnovějších standardů může klient pouze přesměrovat, aniž by se uživatele zeptal, zda je druhý zdroj požadován pomocí metody GETnebo HEAD[7] . Předchozí specifikace říkaly, ž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í [16] . U všech přesměrování, pokud metoda požadavku nebyla HEAD, pak by měla být v těle odpovědi zahrnuta krátká hypertextová zpráva s cílovou adresou, aby se uživatel v případě chyby mohl sám navigovat.
Vývojáři HTTP poznamenávají, že mnoho klientů při přesměrování pomocí kódů chybně 301aplikuje 302metodu GETna druhý zdroj, přestože první požadavek byl s jinou metodou (nejčastěji PUT) [17] . Aby se předešlo nedorozuměním, HTTP/1.1 zavedlo kódy 303a 307doporučuje se používat místo 302. Metodu musíte změnit pouze v případě, že server odpověděl 303. V ostatních případech je další požadavek podán původní metodou.
Chování klientů pro různá přesměrování je popsáno v tabulce:
- 300 Multiple Choices - Na zadaném URI existuje několik možností pro poskytnutí zdroje podle typu MIME , podle jazyka nebo podle jiných charakteristik. Server odešle se zprávou seznam alternativ, což umožňuje, aby výběr provedl automaticky klient nebo uživatel. Zavedeno v HTTP/1.0.
- 301 Trvale přesunuto – Požadovaný dokument byl trvale přesunut na nové URI zadané v poli Locationzáhlaví. Někteří klienti se při zpracování tohoto kódu chovají nesprávně. Zavedeno v HTTP/1.0.
- 302 nalezeno, 302 dočasně přesunuto – Požadovaný dokument je dočasně dostupný na jiném URI specifikovaném v záhlaví v Location. Tento kód lze použít například při vyjednávání obsahu řízeného serverem . Nějaký[ co? ] se klienti při zpracování tohoto kódu chovají nesprávně. Zavedeno v HTTP/1.0.
- 303 Viz Jiné - Dokument na požadovaném URI musí být vyžádán na adrese v poli Locationzáhlaví 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 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 nalezen dokument se zadaným jménem, server odpoví kódem , který v záhlaví 303uvede jeho trvalou adresu. LocationPak je zaručeno, že si to prohlížeč vyžádá metodou GET, jak získat obsah. 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 vrátí tento kód, pokud klient požadoval dokument pomocí GEThlavičky If-Modified-Sincenebo If-None-Matcha dokument se od zadaného času nezměnil. V tomto případě zpráva serveru nesmí obsahovat tělo. Zavedeno v HTTP/1.0.
- 305 Use Proxy – Požadavek na požadovaný zdroj musí být proveden prostřednictvím proxy serveru, jehož URI je uvedeno v poli Locationzáhlaví. Tento kód odezvy mohou používat pouze původní servery HTTP (nikoli proxy). Zavedeno v HTTP/1.1.
- 306 (Reserved) – Kód odezvy, který se používá v dřívějších verzích specifikace, je aktuálně rezervován. Zmíněno v RFC 2616 (aktualizace HTTP/1.1). Podle prvních návrhů kód znamenal Switch Proxy, který klientovi říkal, aby změnil používaný proxy na ten, který server specifikoval v hlavičce odpovědi [18] .
- 307 Dočasné přesměrování – Požadovaný zdroj je krátce dostupný na jiném URI specifikovaném v poli Locationzáhlaví. Metodu požadavku (GET/POST) nelze změnit. Například požadavek POST musí být odeslán na nový identifikátor URI pomocí stejné metody POST. Tento kód byl zaveden spolu s 303 namísto 302, aby se předešlo nejednoznačnosti. Zavedeno v RFC 2616 (aktualizace HTTP/1.1).
- 308 Trvalé přesměrování – Požadovaný zdroj byl trvale přemístěn na nové URI zadané v poli Locationzáhlaví. Metodu požadavku (GET/POST) nelze změnit. Například požadavek POST musí být odeslán na nový identifikátor URI pomocí stejné metody POST. Tento kód byl zaveden místo 301, aby se předešlo nejednoznačnosti. Zavedeno v RFC 7238 ( RFC 7538 ).
Chyba klienta
Třída kódů 4xxje určena k označení chyb na straně klienta. Při použití všech metod kromě HEAD, server musí vrátit hypertextové vysvětlení pro uživatele v těle zprávy.
- 400 Bad Request - Server narazil na chybu syntaxe v požadavku klienta. Zavedeno v HTTP/1.0.
- 401 Pro přístup k požadovanému zdroji je vyžadována neautorizovaná autentizace . Hlavička odpovědi musí obsahovat pole WWW-Authenticatese seznamem podmínek autentizace. Jinými slovy, aby měl klient přístup k požadovanému zdroji, musí se prezentovat odesláním požadavku, přičemž Authorizationv hlavičce zprávy musí obsahovat pole s údaji potřebnými pro autentizaci. Pokud požadavek již obsahuje autorizační data, odpověď 401 znamená, že autorizace s ním je zamítnuta.
- 402 Vyžaduje se platba – zamýšleno k použití v budoucnu[ kdy? ] . V současnosti[ kdy? ] 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 nevyhlásí v případě prodlení s platbou za jeho služby. Rezervováno od HTTP/1.1.
- 403 Zakázáno [19] - Server požadavek pochopil, ale odmítá ho splnit z důvodu omezení přístupu klienta k zadanému zdroji. Jinými slovy, klient není oprávněn provádět operace na požadovaném zdroji. Pokud přístup ke zdroji vyžaduje ověření HTTP, server vrátí odpověď 401, nebo 407při použití proxy. Jinak byly limity nastaveny správcem serveru nebo vývojářem webové aplikace a mohou se lišit v závislosti na možnostech používaného softwaru . V každém případě by měl být server informován o důvodech odmítnutí zpracovat požadavek. Nejpravděpodobnějšími důvody pro omezení může být pokus o přístup k systémovým prostředkům webového serveru (například soubory .htaccessnebo .htpasswd) nebo souborům, ke kterým byl odepřen přístup pomocí konfiguračních souborů, požadavek na jinou autentizaci než HTTP, např. přistupovat do redakčního systému nebo sekce pro registrované uživatele, nebo server není spokojen s IP adresou klienta , např. při zablokování. Zavedeno v HTTP/1.0.
- 404 Not Found [20] je 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é adrese URL. Pokud server ví, že na této adrese byl dokument, pak je žádoucí použít kód 410 . Odpověď 404lze použít místo 403toho, pokud chcete 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 Allowoddělené čárkou. Server by měl vrátit tuto chybu, pokud je mu metoda známá, ale nevztahuje se konkrétně na zdroj uvedený v požadavku, ale pokud zadaná metoda není použitelná na celém serveru, musí klient vrátit kód 501( Není implementováno). Zavedeno v HTTP/1.1.
- 406 Nepřijatelné – Požadovaný URI nemůže splňovat charakteristiky předané v záhlaví. Pokud metoda nebyla HEAD, měl by server vrátit seznam platných charakteristik pro daný zdroj. Zavedeno v HTTP/1.1.
- 407 Je vyžadováno ověření proxy – odpověď je podobná kódu 401, s tím rozdílem, že ověření se provádí pro proxy server. Mechanismus je podobný autentizaci na původním serveru. Zavedeno v HTTP/1.1.
- 408 Časový limit požadavku – Časový limit serveru při čekání na přenos od klienta vypršel. Klient může požadavek obdobný předchozímu kdykoliv zopakovat. Taková situace může nastat například při nahrávání velkého souboru na server pomocí POSTnebo PUT. V určitém okamžiku přenosu přestal datový zdroj reagovat například z důvodu poškozeného CD nebo ztráty komunikace s jiným počítačem v lokální síti. Dokud klient nic nepřenáší a čeká na odpověď, spojení se serverem je udržováno. Po nějaké době může server uzavřít připojení na své straně, aby umožnil ostatním klientům podat požadavek. Tato odpověď není vrácena, když klient násilně zastavil přenos na příkaz uživatele nebo bylo 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 nemohl být dokončen kvůli konfliktu prostředků. K tomu může dojít například tehdy, když se dva klienti pokusí upravit prostředek pomocí PUT. Zavedeno v HTTP/1.1.
- 410 Gone – server odešle takovou odpověď, pokud byl zdroj na zadané adrese URL, ale byl odstraněn a nyní je nedostupný. V tomto případě server také nezná umístění alternativního dokumentu (například kopie). Zavedeno v HTTP/1.1.
- 411 Vyžaduje délku – pro zadaný zdroj musí klient uvést Content-Lengthv hlavičce požadavku. Bez zadání tohoto pole byste neměli opakovat požadavek na server pro tento URI. Taková odpověď je přirozená pro dotazy jako POSTa PUT. Pokud se například soubory stahují na zadaný identifikátor URI a jejich objem na serveru je omezen. Pak by bylo rozumnější hned na začátku zkontrolovat hlavičku Content-Lengtha rovnou odmítnout stahování, než vyprovokovat nesmyslnou zátěž přerušením spojení, když klient opravdu posílá příliš velkou zprávu. Zavedeno v HTTP/1.1.
- 412 Předběžná podmínka selhala – Vráceno, pokud nebylo dokončeno žádné z polí podmíněné hlavičky (If-Match atd., viz RFC 7232 ) požadavku. Zavedeno v HTTP/1.1.
- 413 Payload Too Large – Vráceno, pokud server odmítne zpracovat požadavek, protože tělo požadavku je příliš velké. Server MŮŽE uzavřít spojení a zastavit další přenos požadavku. Pokud je problém dočasný, doporučuje se zahrnout do odpovědi serveru hlavičku s Retry-Afteruvedením doby, po které lze podobný požadavek opakovat. Zavedeno v HTTP/1.1. Dříve nazývané „Příliš velká entita požadavku“.
- 414 URI je příliš dlouhý – Server nemůže zpracovat požadavek, protože zadaný URI je příliš dlouhý. Taková chyba může být vyvolána například tím, že se klient pokusí předat dlouhé parametry metodou GETmísto POST. Zavedeno v HTTP/1.1. Dříve nazývané „Request-URI Too Long“.
- 415 Nepodporovaný typ média – server z nějakého důvodu odmítá touto metodou pracovat se zadaným datovým typem. Zavedeno v HTTP/1.1.
- 416 Rozsah nesplnitelný – Rangev poli záhlaví požadavku byl zadán rozsah mimo zdroj a pole chybí If-Range. Pokud klient odeslal rozsah bajtů, server MŮŽE vrátit skutečnou velikost v poli Content-Rangezáhlaví. Tato odpověď by se neměla používat při předávání typumultipart/byteranges . Zavedeno v RFC 2616 (aktualizace HTTP/1.1). Dříve nazývaný "Požadovaný rozsah není uspokojitelný".
- 417 Očekávání se nezdařilo – Z nějakého důvodu server nemůže splnit hodnotu Expectpole hlavičky požadavku. Zavedeno v RFC 2616 (aktualizace HTTP/1.1).
- 418 Jsem čajník – 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 . Neočekává se, že tento kód bude podporován skutečnými servery [21] .
- 419 Časový limit ověření (ne v RFC 2616 ) – Tento kód není v RFC 2616 , používá se jako alternativa ke kódům 401, které jsou ověřeny, ale mají odepřený přístup k určitým zdrojům serveru. Obvykle je kód uveden, pokud je token CSRF zastaralý nebo se ukázalo, že je nesprávný.
- 421 Misdirected Request – požadavek byl přesměrován na server, který nemůže odpovědět.
- 422 Unprocessable Entity - server úspěšně přijal požadavek, může pracovat se zadaným typem dat (např. tělo požadavku obsahuje XML dokument, který má správnou syntaxi), ale je tam nějaká logická chyba, kvůli které je nemožné provést operaci se zdrojem. Představeno ve WebDAV .
- 423 Uzamčeno – cílovému prostředku z požadavku je zablokováno použití zadané metody. Představeno ve WebDAV .
- 424 Failed Dependency - Implementace aktuálního požadavku může záviset na úspěchu jiné operace. Pokud se neprovede a z tohoto důvodu není možné provést aktuální požadavek, server tento kód vrátí. Představeno ve WebDAV .
- 425 Too Early - Server není připraven přijmout rizika zpracování "časných informací". Zavedeno v RFC 8470 k ochraně před útoky opakovaného přehrávání při použití 0-RTT v TLS 1.3.
- 426 Je vyžadován upgrade – Server dává klientovi pokyn k upgradu protokolu. Hlavička odpovědi musí obsahovat správně vytvořená pole Upgradea Connection. Zavedeno v RFC 2817 pro umožnění přechodu na TLS přes HTTP.
- 428 Precondition Required - Server říká klientovi, aby použil hlavičky podmínek jako If-Match. Představeno v návrhu RFC 6585 .
- 429 Too Many Requests – Klient se pokusil odeslat příliš mnoho požadavků v krátkém čase, což může naznačovat například pokus o DDoS útok. Může být doprovázeno hlavičkou Retry-After udávající, jak dlouho lze požadavek opakovat. Představeno v návrhu RFC 6585 .
- 431 Příliš velká pole záhlaví požadavku – byla překročena povolená délka záhlaví. Server nemusí odpovídat tímto kódem, místo toho může jednoduše resetovat připojení. Představeno v návrhu RFC 6585 .
- 434 Požadovaný hostitel nedostupný – Požadovaná adresa není dostupná .
- 449 Opakovat s – Vráceno serverem, pokud od klienta nebylo přijato dostatek informací ke zpracování požadavku. V tomto případě je pole umístěno v hlavičce odpovědi Ms-Echo-Request. Představeno společností Microsoft pro WebDAV . V současnosti[ kdy? ] používá minimálně Microsoft Money .
- 451 nedostupné z právních důvodů - přístup ke zdroji je z právních důvodů uzavřen, například na žádost orgánů veřejné moci nebo na žádost držitele autorských práv v případě porušení autorských práv. Představeno v návrhu IETF společností Google [12] , přičemž chybový kód je odkazem na román Raye Bradburyho Fahrenheit 451 . Do standardu byl přidán 21. prosince 2015 [22] .
- 499 Client Closed Request je nestandardní kód navržený a používaný nginx pro případy, kdy klient uzavřel spojení, zatímco nginx zpracovával požadavek.
Chyba serveru
Kódy 5xxjsou vyhrazeny pro případy neošetřených výjimek při provádění operací na straně serveru. Pro všechny situace jiné než použití metody HEADMUSÍ server zahrnout vysvětlení do těla zprávy, kterou klient zobrazí uživateli.
- 500 Interní chyba serveru [23] Jakákoli interní chyba serveru, která není pokryta zbytkem chyb třídy. Zavedeno v HTTP/1.0.
- 501 Not Implemented – 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ěď 405. Zavedeno v HTTP/1.0.
- 502 Špatná brána – Server, který funguje jako brána nebo proxy server, obdržel neplatnou odpověď od nadřazeného serveru. Zavedeno v HTTP/1.0.
- 503 Služba nedostupná - server dočasně nemůže z technických důvodů zpracovávat požadavky (údržba, přetížení atd.). V poli Retry-Afterzáhlaví může server specifikovat čas, po kterém je doporučeno, aby klient požadavek opakoval. I když se zdá samozřejmé okamžitě ukončit připojení během přetížení, může být efektivnější nastavit pole na velkou hodnotu Retry-After, aby se snížila frekvence redundantních požadavků. Zavedeno v HTTP/1.0.
- 504 Časový limit brány – Server fungující jako brána nebo proxy 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 Variant also Negotiates - V důsledku chybné konfigurace ukazuje vybraná varianta sama na sebe, kvůli čemuž je proces propojování přerušen. Experimentální. Zavedeno v RFC 2295 k rozšíření protokolu HTTP o technologii Transparent Content Negotiation .
- 507 Nedostatek úložiště – není dostatek místa pro dokončení aktuálního požadavku. Problém může být dočasný. Zavedeno ve WebDAV .
- 508 Loop Detected - Operace zrušena, protože server narazil na nekonečnou smyčku při zpracování požadavku bez omezení hloubky. Zavedeno ve WebDAV .
- 508 Resource Limit Reached je varianta chyby 508 v CloudLinuxu , ke které dochází při dosažení limitů hostování [24] .
- 509 Překročen limit šířky pásma – používá se, když webová stránka překročí limit spotřeby provozu, který je jí přidělen. V takovém případě by měl vlastník webu kontaktovat svého poskytovatele hostingu. V současné době není tento kód popsán v žádném RFC a je používán pouze modulem „bw/limited“, který je součástí hostitelského ovládacího panelu cPanel , kde byl představen.
- 510 Not Extended – Server nemá rozšíření, které chce klient použít. Server může volitelně odesílat informace o rozšířeních, která má k dispozici. Zavedeno v RFC 2774 k rozšíření protokolu HTTP o podporu rozšíření.
- 511 Network Authentication Required - tuto odpověď nezasílá server, kterému byl požadavek určen, ale zprostředkující server - například server poskytovatele - pokud se klient musí nejprve přihlásit do sítě, například zadat heslo pro placený přístupový bod k internetu. Předpokládá se, že tělo odpovědi vrátí webový autorizační formulář nebo přesměrování na něj. Představeno v návrhu RFC 6585 .
- 520 Neznámá chyba, nastane, když server CDN nebyl schopen zpracovat chybu webového serveru; vlastní kód CloudFlare .
- 521 Web Server Is Down, nastane, když jsou připojení CDN webovým serverem odmítnuta; vlastní kód CloudFlare .
- 522 Vypršel časový limit připojení, nastane, když se CDN nepodařilo připojit k webovému serveru; vlastní kód CloudFlare .
- 523 Origin Is Unreachable, nastane, když je webový server nedostupný; vlastní kód CloudFlare .
- 524 Došlo k vypršení časového limitu, nastane, když vyprší časový limit připojení mezi serverem CDN a webovým serverem. vlastní kód CloudFlare .
- 525 SSL Handshake Failed, nastane, když selže SSL handshake mezi CDN serverem a webovým serverem; vlastní kód CloudFlare .
- 526 Neplatný certifikát SSL, nastane, když nelze ověřit šifrovací certifikát webového serveru; vlastní kód CloudFlare .
Viz také
Poznámky
- ↑ 1 2 2.2.6 449 "Opakovat se stavovým kódem" // Protokol WebDAV (Web Distributed Authoring and Versioning): Klientská rozšíření. Archivováno 5. října 2009 na Wayback Machine na MSDN
- ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 353 Stav 31 32 353 36. června _ _ 7, 2018 na Wayback Machine » v RFC 2068
- ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 613 RFC . Datum přístupu: 29. července 2009. Archivováno z originálu 7. března 2011. (neurčitý)
- ↑ 1 2 3 IETF Draft WebDAV Advanced Collections Protocol - S.4.2.5 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012. (neurčitý)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.10 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012. (neurčitý)
- ↑ rfc5842 . Získáno 12. září 2017. Archivováno z originálu 10. října 2017. (neurčitý)
- ↑ 1 2 3 4 5 6 7 8 9 10 RFC 2616 „10.3 Přesměrování 3xx“ (str. 61) . Datum přístupu: 29. července 2009. Archivováno z originálu 7. března 2011. (neurčitý)
- ↑ rfc7538 . Získáno 12. září 2017. Archivováno z originálu 16. dubna 2015. (neurčitý)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.4.3.1.1 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012. (neurčitý)
- ↑ rfc7540 . Získáno 12. září 2017. Archivováno z originálu 23. června 2015. (neurčitý)
- ↑ 1 2 3 4 RFC 6585
- ↑ 1 2 IETF navrhuje nový stavový kód HTTP pro hlášení právních překážek . Získáno 6. března 2013. Archivováno z originálu dne 22. května 2013. (neurčitý)
- ↑ RFC 2295 Transparent Content Negotiation v HTTP - S.8.1 . Datum přístupu: 18. května 2012. Archivováno z originálu 8. června 2012. (neurčitý)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.7.1 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012. (neurčitý)
- ↑ 1 2 3 4 5 6 7 Error Pages – CloudFlare Support . Získáno 18. dubna 2016. Archivováno z originálu 4. března 2016. (neurčitý)
- ↑ RFC 2068 "10.3 Redirection 3xx" (str. 56) Archivováno 7. června 2018 na Wayback Machine .
- ↑ RFC 2616 , sekce „10.3.3 302 Found“, strana 63 Archivováno 7. března 2011 na Wayback Machine .
- ↑ Kódy odpovědí Josh Cohen HTTP/1.1 305 a 306 Archivovány 8. září 2014 na Wayback Machine // Netscape Communications Corp., 25. prosince 1996
- ↑ Co znamená 403 Forbidden? Archivováno 21. února 2014 na Wayback Machine .
- ↑ Příčiny chyby 404 Nenalezeno Archivováno 21. února 2014 na Wayback Machine .
- ↑ RFC 2324 – Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) .
- ↑ draft-ietf-httpbis-legally-restricted-status-04 . datatracker.ietf.org. Získáno 22. prosince 2015. Archivováno z originálu dne 23. prosince 2015. (neurčitý)
- ↑ Popis 500 interní chyby serveru Archivováno 21. února 2014 na Wayback Machine .
- ↑ Bylo dosaženo limitu zdrojů . www.cloudlinux.com _ Získáno 21. června 2022. Archivováno z originálu 15. května 2021. (neurčitý)
Odkazy
Základní dokumenty HTTP (sestupně podle data vydání)
- Registr stavového kódu Hypertext Transfer Protocol (HTTP) . IANA (17. října 2007). - Registr stavových kódů HTTP. Datum přístupu: 30. července 2009. Archivováno z originálu 17. února 2012.
- RFC 2616 koncept standardu " Hypertext Transfer Protocol - HTTP/1.1 " ( anglicky ) IETF , červen 1999; Fielding Roy ( UC Irvine), Gettys Jim ( Compaq / W3C ), Mogul J. ( Compaq ), Frystyk Henrik( MIT / W3C ), Masinter L. ( Xerox ), Leach P. ( Microsoft ), Berners-Lee Tim ( W3C / MIT ) - aktualizace protokolu HTTP verze 1.1.
- RFC 2068 Navrhovaný standard " Hypertext Transfer Protocol - HTTP/1.1 " (anglicky) (z angličtiny - "Hypertext Transfer Protocol - HTTP/1.1"); IETF , leden 1997; Fielding Roy ( UC Irvine), Gettys Jim ( DEC ), Mogul J. ( DEC ), Frystyk Henrik( MIT /LCS), Berners-Lee Tim ( MIT /LCS) je raná specifikace pro HTTP verze 1.1.
- Informační RFC 1945 " Hypertext Transfer Protocol - HTTP / 1.0 " IETF , květen 1996; Berners-Lee Tim ( MIT /LCS), Fielding Roy ( UC Irvine), Frystyk Henrik( MIT /LCS) je úplně první specifikace pro protokol HTTP. Zahrnuje také popis HTTP/0.9.
Dokumenty o rozšířeních a aktualizacích protokolu HTTP (sestupně podle data publikace)
- RFC 4918 navrhovaný standard " HTTP Extensions for Web Distributed Authoring and Versioning ( WebDAV ) " IETF , červen 2007; Dusseault Ed. L. ( CommerceNet) je pozdní specifikace pro protokol WebDAV, která nahrazuje RFC 2518 .
- RFC 3229 Navrhovaný standard " Delta kódování v HTTP " (anglicky) (z angličtiny - "Delta kódování v HTTP"); IETF , leden 2002; Mogul J. ( Compaq WRL), Krishnamurthy B. ( AT&T ), Douglis F. ( AT&T ), Feldmann A. ( Univ. of Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA) .
- RFC 2817 navrhovaný standard " Upgrade na TLS v rámci HTTP / 1.1 " IETF , květen 2000; Khare Rohit(4K Associates/ UC Irvine), Lawrence S. (Agranat Systems, Inc.) - aktualizace na RFC 2616 , která popisuje, jak funguje HTTP a TLS .
- RFC 2774 Experimental " An HTTP Extension Framework " (anglicky) (z angličtiny - "HTTP Extension Framework"); IETF , únor 2000; Nielsen H. ( Microsoft ), Leach P. ( Microsoft ), Lawrence S. (Agranat Systems) .
- Internetový koncept " WebDAV Advanced Collections Protocol " (z angličtiny - "WebDAV Advanced Collections Protocol "); IETF , 18. června 1999; Slein J. ( Xerox ), Whitehead Jr. EJ ( UC Irvine), Davis J. (CourseNet), Clemm G. ( Rational ), Fay C. ( FileNet), Crawford J. ( IBM ), Chihaya T. (DataChannel) - správa kolekcí ve WebDAV; platnost vypršela 18. prosince 1999.
- RFC 2518 navrhovaný standard „ Rozšíření HTTP pro distribuované vytváření – WEBDAV “ IETF , únor 1999; Goland Y. ( Microsoft ), Whitehead E. ( UC Irvine), Faizi A. ( Netscape ), Carter S. ( Novell ), Jensen D. ( Novell ) - první specifikace pro protokol WebDAV ( nahrazena RFC 4918 ).
- Experimentální vyjednávání transparentního obsahu RFC 2295 v HTTP IETF , březen 1998; Holtman K. (TUE), Mutz A. ( Hewlett-Packard ) .
Doplňkové materiály
Web a webové stránky |
---|
globálně |
|
---|
Lokálně |
|
---|
Typy stránek a služeb |
|
---|
Tvorba a údržba |
|
---|
Typy rozložení, stránek, webů |
|
---|
Technický |
|
---|
Marketing |
|
---|
Společnost a kultura |
|
---|