| Stavový kód http | Stavový kód Význam |
|---|
| 100 | Klient by měl pokračovat v odesílání požadavků. Tato dočasná odpověď slouží k informování klienta, že část jeho požadavku byla serverem přijata a nebyla odmítnuta. Klient by měl pokračovat v odesílání zbývající části požadavku nebo tuto odpověď ignorovat, pokud je požadavek kompletní. Po dokončení požadavku musí server klientovi zaslat konečnou odpověď. |
| 101 | Server porozuměl požadavku klienta a prostřednictvím hlavičky zprávy Upgrade jej upozorní, aby k dokončení požadavku použil jiný protokol. Po odeslání posledního prázdného řádku této odpovědi server přepne na ty protokoly, které jsou definovány v záhlaví zprávy Upgrade. To by mělo být provedeno pouze v případě, že je výhodnější přejít na nový protokol. Například přechod na novou verzi protokolu HTTP je výhodnější než na starší verzi nebo přechod na protokol pracující v reálném čase a synchronní protokol pro doručování prostředků, které tyto vlastnosti využívají. |
| 102 | Stavové kódy, rozšířené protokolem WebDAV (RFC 2518), vyjadřují, že zpracování bude pokračovat. |
| 200 | Požadavek byl úspěšný a s touto odpovědí bude vrácena hlavička odpovědi nebo tělo dat požadované požadavkem. |
| 201 | Požadavek byl splněn a byl vytvořen nový prostředek podle požadavku a jeho URI byl vrácen s hlavičkou Location. Pokud nelze požadovaný prostředek vytvořit včas, měla by být vrácena zpráva "202 Accepted". |
| 202 | Server požadavek přijal, ale ještě jej nezpracoval. Stejně jako může být odmítnut, nakonec může, ale nemusí být požadavek proveden. V kontextu asynchronních operací není nic vhodnějšího než zaslání tohoto stavového kódu. Účelem vrácení odpovědi se stavovým kódem 202 je umožnit serveru přijímat požadavky z jiných procesů (například dávkové operace, která se provádí pouze jednou denně), aniž by klient musel zůstat připojen k serveru, dokud není dávková operace zcela dokončena. Odpověď, která přijímá požadavek na zpracování a vrací stavový kód 202, MUSÍ ve vrácené entitě obsahovat některé informace označující aktuální stav procesu a také ukazatel na monitor stavu zpracování nebo předpověď stavu, aby uživatel mohl odhadnout, zda byla operace dokončena. |
| 203 | Server úspěšně zpracoval požadavek, ale vrácené metainformace v záhlaví entity nejsou definitivní sadou platnou na původním serveru, ale kopií od místní nebo třetí strany. Aktuální informace mohou být podmnožinou nebo nadmnožinou původní verze. Například metadata obsahující zdroje mohou způsobit, že původní server zná metainformace super. Použití tohoto stavového kódu není povinné a je vhodné pouze v případě, že by odpověď bez něj vrátila 200 OK. |
| 204 | Server úspěšně zpracoval požadavek, ale nepotřebuje vrátit žádný fyzický obsah a chce vrátit aktualizované metainformace. Odpověď může vrátit nové nebo aktualizované metainformace ve formě hlaviček entit. Pokud takové hlavičky existují, měly by odpovídat požadovaným proměnným. Je-li klientem prohlížeč, pak by měl prohlížeč uživatele zachovat stránku, na které byl požadavek odeslán, bez jakýchkoli změn zobrazení dokumentu, i když podle specifikace by se nové nebo aktualizované metainformace měly použít na dokument v aktivním zobrazení prohlížeče uživatele. Protože odpověď 204 nesmí obsahovat žádné tělo zprávy, končí vždy prvním prázdným řádkem za hlavičkou zprávy. |
| 205 | Server úspěšně zpracoval požadavek a nic nevrátil. Na rozdíl od odpovědi 204 však odpověď, která vrací tento stavový kód, žádá žadatele o obnovení zobrazení dokumentu. Tato odpověď se používá především k resetování formuláře ihned po přijetí uživatelského vstupu, aby uživatel mohl snadno zahájit další vstup. Stejně jako odpověď 204 je i tato odpověď zakázána obsahovat jakékoliv tělo zprávy a končí prvním prázdným řádkem za záhlavím zprávy. |
| 206 | Server úspěšně zpracoval část požadavku GET. Nástroje pro stahování HTTP, jako je FlashGet nebo Thunderbolt, používají tento typ odpovědi k provádění přerušovaného stahování nebo k rozdělení velkého dokumentu na více segmentů stahování najednou. Požadavek musí obsahovat hlavičku Range, která označuje rozsah obsahu, který si klient přeje získat, a může obsahovat If-Range jako podmínku požadavku. Odpověď musí obsahovat následující pole záhlaví: Content-Range pro označení rozsahu obsahu vráceného v této odpovědi; v případě stahování více segmentů s Content-Type multipart/byteranges by měl každý segment obsahující více částí obsahovat pole Content-Range označující rozsah obsahu v daném segmentu. Pokud odpověď obsahuje pole Content-Length, musí jeho hodnota odpovídat skutečnému počtu bajtů v rozsahu vráceného obsahu. datum ETag a/nebo Content-Location, pokud by stejný požadavek měl vrátit odpověď 200. Expires, Cache-Control a/nebo Vary, pokud se jejich hodnoty mohou lišit od jiných odpovědí se stejnými proměnnými. Expires, Cache-Control a/nebo Vary, pokud se jejich hodnoty mohou lišit od hodnot jiných předchozích odpovědí se stejnými proměnnými. Tato odpověď NEMUSÍ obsahovat jiné hlavičky entit, pokud požadavek používá silnou validaci mezipaměti If-Range, a NEMUSÍ obsahovat jiné hlavičky entit, pokud požadavek používá slabou validaci mezipaměti If-Range; tím se zabrání nekonzistenci mezi obsahem entit v mezipaměti a aktualizovanými informacemi v hlavičkách entit. V opačném případě by tato odpověď MĚLA obsahovat všechna pole záhlaví entit, která měla být vrácena ve všech odpovědích 200, které měly být vráceny. Pokud se hlavičky ETag nebo Last-Modified přesně neshodují, mezipaměť na straně klienta MUSÍ zakázat kombinování obsahu vráceného v odpovědi 206 s jakýmkoli dříve uloženým obsahem v mezipaměti. Jakákoli mezipaměť, která nepodporuje hlavičky Range a Content-Range, nesmí obsah vrácený odpovědí 206 ukládat do mezipaměti. |
| 207 | Stavový kód rozšířený protokolem WebDAV (RFC 2518) znamená, že tělo následné zprávy bude tvořit zpráva XML a může obsahovat řadu samostatných kódů odpovědi v závislosti na počtu předchozích dílčích požadavků. |
| 300 | Požadovaný prostředek má řadu alternativních návratových zpráv, z nichž každá má svou vlastní specifickou adresu a informace o vyjednávání podle prohlížeče. Uživatel nebo prohlížeč si může sám vybrat preferovanou adresu pro přesměrování. Pokud se nejedná o požadavek HEAD, měla by odpověď obsahovat entitu, která je seznamem charakteristik a adres prostředku, z nichž si uživatel nebo prohlížeč může vybrat nejvhodnější adresu pro přesměrování. Formát této entity je určen formátem definice Content-Type. Prohlížeč může automaticky provést nejvhodnější výběr na základě formátu odpovědi a vlastních možností prohlížeče. Specifikace RFC 2616 samozřejmě nespecifikuje, jak by se takový automatický výběr měl provádět. Pokud již server sám má preferovanou volbu návratu, pak by URI tohoto návratu měl být uveden v položce Location; prohlížeč může tuto hodnotu Location použít jako adresu pro automatické přesměrování. Kromě toho je tato odpověď také uložitelná do mezipaměti, pokud není uvedeno jinak. |
| 301 | Požadovaný prostředek byl trvale přesunut do nového umístění a jakékoli budoucí odkazy na něj by měly používat jeden z několika URI vrácených v této odpovědi. Pokud je to možné, klienti s možností editace odkazů by měli automaticky změnit požadovanou adresu na adresu vrácenou ze serveru. Pokud není uvedeno jinak, je tato odpověď rovněž uložitelná do mezipaměti. Nový trvalý URI by měl být vrácen v poli Location odpovědi. Pokud se nejedná o požadavek HEAD, měla by entita odpovědi obsahovat hypertextový odkaz na nový URI a krátký popis. Pokud se nejedná o požadavek GET nebo HEAD, prohlížeč tedy nesmí automaticky přesměrovat, pokud to uživatel nepotvrdí, protože podmínky požadavku se v důsledku toho mohou změnit. Poznámka: U některých prohlížečů používajících protokol HTTP/1.0 platí, že pokud odešlou požadavek POST a obdrží odpověď 301, bude další požadavek na přesměrování GET. |
| 302 | Požadovaný prostředek nyní dočasně odpovídá na požadavek z jiného URI. Protože je toto přesměrování dočasné, měl by klient i nadále posílat budoucí požadavky na původní adresu. Tuto odpověď lze uložit do mezipaměti pouze v případě, že je uvedena v položce Cache-Control nebo Expires. Nový dočasný URI by měl být vrácen v poli Location odpovědi. Pokud se nejedná o požadavek HEAD, měla by entita odpovědi obsahovat hypertextový odkaz na nový URI a krátký popis. Pokud se nejedná o požadavek GET nebo HEAD, pak je zakázáno, aby prohlížeč automaticky přesměroval, pokud to uživatel nepotvrdí, protože se v důsledku toho mohou změnit podmínky požadavku. Poznámka: Přestože specifikace RFC 1945 a RFC 2068 neumožňují klientovi změnit metodu požadavku při přesměrování, mnoho stávajících prohlížečů považuje odpověď 302 za odpověď 303 a použije GET pro přístup k URI uvedenému v umístění, přičemž ignoruje metodu původního požadavku. Stavové kódy 303 a 307 byly přidány, aby bylo jasné, jakou odpověď server od klienta očekává. |
| 303 | Odpověď na aktuální požadavek lze nalézt na jiném URI a klient by měl k tomuto prostředku přistupovat pomocí GET. Tato metoda existuje především proto, aby umožnila přesměrování výstupu požadavku POST aktivovaného skriptem na nový prostředek. Tento nový URI není alternativním odkazem na původní prostředek. Rovněž je zakázáno ukládat odpověď 303 do mezipaměti. Druhý požadavek (přesměrování) samozřejmě může být uložen do mezipaměti. Nový URI by měl být vrácen v poli Location odpovědi. Pokud se nejedná o požadavek HEAD, měla by entita odpovědi obsahovat hypertextový odkaz na nový URI a krátký popis. Poznámka: Mnoho prohlížečů před verzí HTTP/1.1 nerozumí správně stavu 303. Pokud je třeba uvažovat o interakci s těmito prohlížeči, měl by stačit stavový kód 302, protože většina prohlížečů zpracovává odpovědi 302 přesně tak, jak to výše uvedená specifikace vyžaduje od klienta při zpracování odpovědi 303. |
| 304 | Server MUSÍ vrátit tento stavový kód, pokud klient odešle podmíněný požadavek GET, který byl povolen, a obsah dokumentu (od poslední návštěvy nebo podle podmínek požadavku) se nezměnil. 304 Odpovědi nesmí obsahovat tělo zprávy, a proto vždy končí prvním prázdným řádkem za hlavičkou zprávy. Odpověď MUSÍ obsahovat následující hlavičky: Datum, pokud server nemá hodiny. Pokud se server bez hodin řídí těmito pravidly, může proxy server a klient přidat pole Datum do hlavičky příchozí odpovědi sám (jak je uvedeno v RFC 2068) a mechanismus ukládání do mezipaměti bude fungovat správně.ETag a/nebo Content-Location, pokud by stejný požadavek vrátil odpověď 200.Expires Expires, Cache-Control a/nebo Vary, pokud se hodnota může lišit od hodnoty odpovídající jiným předchozím odpovědím pro stejnou proměnnou. Pokud tento požadavek na odpověď používá silnou validaci mezipaměti, pak by tato odpověď neměla obsahovat jiné hlavičky entit; v opačném případě (např. podmíněný požadavek GET používá slabou validaci mezipaměti) je zakázáno, aby tato odpověď obsahovala jiné hlavičky entit; tím se zabrání nesouladu mezi obsahem entit uloženým v mezipaměti a aktualizovanými informacemi v hlavičkách entit. Pokud odpověď 304 označuje, že entita není v současné době uložena v mezipaměti, musí systém ukládání do mezipaměti tuto odpověď ignorovat a opakovat požadavek bez omezení. Pokud je přijata odpověď 304 požadující aktualizaci položky mezipaměti, systém mezipaměti MUSÍ aktualizovat celou položku tak, aby odrážela hodnoty všech polí aktualizovaných v odpovědi. |
| 305 | Požadovaný prostředek musí být zpřístupněn prostřednictvím určeného proxy serveru. pole Location (umístění) poskytne informaci o URI, kde se určený proxy server nachází. příjemce bude muset opakovaně odeslat samostatný požadavek, aby získal přístup k prostředku prostřednictvím tohoto proxy serveru. Odpověď 305 může vytvořit pouze původní server. Poznámka: Z RFC 2068 není jasné, že odpověď 305 je určena k přesměrování jednoho požadavku a může ji vytvořit pouze původní server. Ignorování těchto omezení by mohlo vést k vážným bezpečnostním důsledkům. |
| 306 | V nejnovější verzi specifikace se stavový kód 306 již nepoužívá. |
| 307 | Požadovaný prostředek nyní dočasně odpovídá na požadavek z jiného URI. Vzhledem k tomu, že takové přesměrování je dočasné, měli by klienti i nadále posílat budoucí požadavky na původní adresu. Tuto odpověď je možné uložit do mezipaměti pouze v případě, že je uvedeno Cache-Control nebo Expires. Nový dočasný URI by měl být vrácen v poli Location odpovědi. Pokud se nejedná o požadavek HEAD, měla by entita odpovědi obsahovat hypertextový odkaz na nový URI a krátký popis. Protože některé prohlížeče nerozpoznávají odpověď 307, je třeba přidat výše uvedené informace, aby uživatel mohl pochopit a vyžádat si přístup k novému URI. Pokud se nejedná o požadavek GET nebo HEAD, pak prohlížeč zakáže automatické přesměrování, pokud to uživatel nepotvrdí, protože podmínky požadavku se mohou změnit. |
| 400 | 1. Došlo k sémantické chybě a server aktuálnímu požadavku nerozumí. Pokud nedojde k úpravě, klient by neměl tento požadavek opakovaně odesílat. 2, parametry požadavku jsou chybné. |
| 401 | Aktuální požadavek vyžaduje ověření uživatele. Odpověď musí obsahovat hlavičku WWW-Authenticate pro požadovaný prostředek, která požaduje informace o uživateli. Klient může opakovaně odeslat požadavek, který obsahuje příslušné informace hlavičky Authorisation. Pokud aktuální požadavek již obsahuje pověření Authorisation, pak odpověď 401 znamená, že server ověřuje, že tato pověření byla odmítnuta. Pokud odpověď 401 obsahuje stejný ověřovací dotaz jako předchozí odpověď a prohlížeč se již alespoň jednou pokusil o ověření, pak MUSÍ uživateli předložit informace o entitě obsažené v odpovědi, protože tyto informace o entitě mohou obsahovat příslušné diagnostické informace. Viz RFC 2617. |
| 402 | Tento stavový kód je vyhrazen pro případné budoucí požadavky. |
| 403 | Server požadavku porozuměl, ale odmítá jej provést. Na rozdíl od odpovědi 401 ověření neposkytuje žádnou pomoc a tento požadavek by neměl být znovu odeslán. Pokud se nejedná o požadavek HEAD a server chce být schopen jasně hovořit o tom, proč nelze požadavek provést, pak by měl být důvod odmítnutí popsán v rámci entity. Server samozřejmě může také vrátit odpověď 404, pokud nechce klientovi poskytnout žádné informace. |
| 404 | Požadavek se nezdařil, požadovaný prostředek nebyl na serveru nalezen. Uživateli není k dispozici žádná informace, která by mu sdělila, zda se jedná o dočasnou nebo trvalou situaci. Pokud si je server této situace vědom, měl by použít stavový kód 410, aby uživatele informoval, že starý prostředek je trvale nedostupný kvůli nějakému vnitřnímu konfiguračnímu mechanismu a že není k dispozici žádné přesměrování. 404 se široce používá, pokud server nechce prozradit, proč byl požadavek odmítnut, nebo pokud není k dispozici jiná vhodná odpověď. |
| 405 | Metodu požadavku uvedenou v řádku požadavku nelze použít k vyžádání příslušného prostředku. Odpověď musí vrátit hlavičku Allow, která uvádí seznam metod požadavku, které jsou pro daný prostředek přijatelné. Vzhledem k tomu, že metody PUT a DELETE zapisují do prostředku na serveru, většina webových serverů tyto metody požadavku nepodporuje nebo je ve výchozím nastavení nepovoluje a v případě takových požadavků vrátí chybu 405. |
| 406 | Charakteristiky obsahu požadovaného prostředku nesplňují podmínky v hlavičce požadavku a entitu odpovědi nelze vygenerovat. Pokud se nejedná o požadavek HEAD, měla by odpověď vrátit entitu obsahující seznam charakteristik a adres entit, ze kterých si uživatel nebo prohlížeč může vybrat nejvhodnější entitu. Formát entity je určen typem média definovaným v hlavičce Content-Type. Prohlížeče mohou na základě formátu a svých vlastních možností provést vlastní nejlepší volbu. Specifikace však nedefinuje žádná kritéria pro takový automatický výběr. |
| 407 | Podobně jako u odpovědi 401 s tím rozdílem, že klient se MUSÍ ověřit na proxy serveru. Proxy server MUSÍ vrátit zprávu Proxy-Authenticate pro dotaz na identitu. Klient MŮŽE vrátit hlavičku Proxy-Authorization pro ověření pravosti. Viz RFC 2617. |
| 408 | Časový limit požadavku. Klient nedokončil odeslání požadavku v době, po kterou byl server připraven čekat. Klient může požadavek kdykoli odeslat znovu, aniž by provedl jakékoli změny. |
| 409 | Požadavek nebylo možné dokončit z důvodu konfliktu s aktuálním stavem požadovaného prostředku. Tento kód je povoleno použít pouze v případě, že je uživatel považován za schopného konflikt vyřešit a znovu odeslat nový požadavek. Odpověď by měla obsahovat dostatek informací, aby uživatel mohl zjistit zdroj konfliktu. Ke konfliktům obvykle dochází při zpracování požadavků PUT. Například v prostředí kontroly verzí, pokud informace o verzi připojené k požadavku PUT odeslanému za účelem úpravy určitého prostředku jsou v konfliktu s předchozím požadavkem (třetí strany), měl by server vrátit chybu 409 a informovat uživatele, že požadavek nemohl být dokončen. V tomto případě bude entita odpovědi pravděpodobně obsahovat porovnání rozdílů mezi oběma konfliktními verzemi, aby uživatel mohl po sloučení znovu odeslat novou verzi. |
| 410 | Požadovaný prostředek již není na serveru k dispozici a není známa žádná adresa pro jeho předání. Takový stav by měl být považován za trvalý. Pokud je to možné, klienti s možností editace odkazů by měli se svolením uživatele odstranit všechny odkazy na tuto adresu. Pokud server neví nebo nemůže určit, zda je tento stav trvalý, měl by být použit stavový kód 404. Pokud není uvedeno jinak, je tato odpověď kešovatelná. 410 Účelem odpovědi je především pomoci správci webu při údržbě webu tím, že informuje uživatele, že zdroj již není k dispozici a že si vlastník serveru přeje, aby byla odstraněna i všechna vzdálená připojení k tomuto zdroji. Tento typ události je běžný u časově omezených služeb s přidanou hodnotou. Podobně se odpověď 410 používá k oznámení klientům, že prostředek, který původně patřil jednotlivci na aktuální stránce serveru, již není k dispozici. Je samozřejmě zcela na vlastníkovi serveru, zda je třeba všechny trvale nedostupné prostředky označit jako "410 Gone" a jak dlouho je třeba toto označení udržovat. |
| 411 | Server odmítá přijímat požadavky bez definované hlavičky Content-Length. Po přidání platné hlavičky Content-Length udávající délku těla zprávy požadavku může klient požadavek znovu odeslat. |
| 412 | Server nesplnil jednu nebo více předběžných podmínek při ověřování, že byly uvedeny v poli hlavičky požadavku. Tento stavový kód umožňuje klientovi nastavit předběžné podmínky v metasprávě požadavku (údaje v poli záhlaví požadavku) při získávání prostředku, a tím zabránit použití metody požadavku na jiné prostředky, než je požadovaný obsah. |
| 413 | Server odmítne zpracovat aktuální požadavek, protože odesílá data entit o velikosti větší, než je server ochoten nebo schopen zpracovat. V takovém případě může server uzavřít spojení, aby zabránil klientovi pokračovat v odesílání tohoto požadavku. Pokud je tento stav dočasný, měl by server vrátit hlavičku odpovědi Retry-After, aby informoval klienta, po jaké době může opakovat pokus. |
| 414 | Délka URI požadavku přesahuje délku, kterou server dokáže interpretovat, proto server odmítne požadavek obsloužit. K tomuto případu dochází zřídka a často se stává, že se z odeslání formuláře, který měl použít metodu POST, stane metoda GET, což má za následek dlouhý řetězec dotazu. "Černé díry" v URI přesměrování, například použití starého URI jako součásti nového URI při každém přesměrování, což po několika přesměrováních vede k dlouhému URI. Klienti se pokoušejí napadnout servery zneužitím bezpečnostních chyb, které na některých serverech existují. Takové servery používají ke čtení nebo manipulaci s URI požadavku vyrovnávací paměť pevné délky, a pokud parametry po příkazu GET překročí určitou hodnotu, může dojít k přetečení vyrovnávací paměti, což vede ke spuštění libovolného kódu [1]. Servery bez takových zranitelností by měly vracet stavový kód 414. |
| 415 | Pro aktuálně požadovanou metodu a požadovaný prostředek není entita odeslaná v požadavku ve formátu podporovaném serverem, proto je požadavek odmítnut. |
| 416 | Pokud požadavek obsahuje hlavičku požadavku Range a všechny rozsahy dat uvedené v Range se nepřekrývají s rozsahy dostupnými pro aktuální prostředek a hlavička požadavku If-Range není v požadavku definována, měl by server vrátit stavový kód 416. Pokud Range používá rozsahy bajtů, pak je tomu tak v případě, že první pozice bajtů všech datových rozsahů uvedených v požadavku přesahuje délku aktuálního prostředku. Server by měl také zahrnout hlavičku entity Content-Range, která specifikuje délku aktuálního prostředku spolu se stavovým kódem 416. U této odpovědi je rovněž zakázáno používat jako Content-Type typ multipart/byteranges. |
| 417 | Očekávaný obsah uvedený v hlavičce požadavku Expect nemůže být serverem splněn nebo je tento server proxy serverem, který má jasné důkazy, že obsah Expect nemůže být splněn v dalším uzlu na aktuální trase. |
| 421 | Počet spojení na server z IP adresy, na které se nachází aktuální klient, překračuje maximum povolené serverem. IP adresou se zde obvykle rozumí adresa klienta, jak je vidět ze serveru (např. adresa brány uživatele nebo proxy serveru). V tomto případě může počet připojení zahrnovat více než jednoho koncového uživatele. |
| 422 | Počet připojení k serveru z IP adresy aktuálního klienta překračuje maximum povolené serverem. Typicky se zde IP adresa vztahuje k adrese klienta, jak je vidět ze serveru (např. adresa brány nebo proxy serveru uživatele). V tomto případě může počet připojení zahrnovat více než jednoho koncového uživatele. |
| 422 | Požadavek byl správně naformátován, ale nebylo možné na něj odpovědět, protože obsahoval sémantické chyby. (RFC 4918 WebDAV) 423 Uzamčeno Aktuální prostředek je uzamčen. (RFC 4918 WebDAV) |
| 424 | Aktuální požadavek selhal kvůli chybě, která se vyskytla v předchozím požadavku, například PROPPATCH (RFC 4918 WebDAV). |
| 425 | Definováno v návrhu WebDav Advanced Collections, ale neobjevuje se v protokolu WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Klienti by měli přejít na TLS/1.0. (RFC 2817) |
| 449 | Rozšířeno společností Microsoft tak, aby vyjadřovalo, že požadavky by měly být opakovány po provedení příslušné akce. |
| 500 | Server narazil na neočekávanou podmínku, která mu zabránila dokončit zpracování požadavku. Typicky se tento problém vyskytuje při chybě v programovém kódu serveru. |
| 501 | Server nepodporuje určitou funkci, která je požadována pro aktuální požadavek. Když server není schopen rozpoznat požadovanou metodu a není schopen podpořit její požadavek na nějaký prostředek. |
| 502 | Server pracující jako brána nebo proxy server obdrží při pokusu o provedení požadavku neplatnou odpověď od serveru vyššího řádu. |
| 503 | Server není aktuálně schopen zpracovat požadavek z důvodu dočasné údržby nebo přetížení serveru. Tento stav je dočasný a po určité době bude obnoven. Pokud lze očekávat zpoždění, může odpověď obsahovat hlavičku Retry-After, která toto zpoždění označuje. Pokud tato informace Retry-After není uvedena, měl by s ní klient zacházet stejně jako s odpovědí 500. Poznámka: Existence stavového kódu 503 neznamená, že jej server musí použít, pokud je přetížen. Některé servery chtějí klientovi jednoduše odepřít připojení. |
| 504 | Server pracující jako brána nebo proxy server, který se pokouší provést požadavek, neobdrží včas odpověď od serveru vyššího řádu (server identifikovaný pomocí URI, například HTTP, FTP, LDAP) nebo sekundárního serveru (například DNS). Poznámka: Některé proxy servery vracejí chybu 400 nebo 500, když vyhledávání DNS skončí. |
| 505 | Server nepodporuje nebo odmítá podporovat verzi protokolu HTTP použitou v požadavku. To znamená, že server není schopen nebo ochoten používat stejnou verzi jako klient. Odpověď by měla obsahovat entitu, která popisuje, proč daná verze není podporována, a které protokoly server podporuje. |
| 506 | Rozšířeno protokolem Transparent Content Negotiation Protocol (RFC 2295), aby představovalo vnitřní chybnou konfiguraci na straně serveru: požadovaný prostředek Negotiation Variant je nakonfigurován tak, aby se používal při transparentním vyjednávání obsahu, a proto není vhodným ohniskem v procesu vyjednávání. |
| 507 | Server není schopen uložit obsah potřebný k dokončení požadavku. Tento stav je považován za dočasný.WebDAV (RFC 4918) |
| 509 | Server dosáhl svého limitu šířky pásma. Nejedná se o oficiální stavový kód, ale přesto je hojně používán. |
| 510 | Zásada požadovaná pro získání zdroje nebyla splněna. (RFC 2774) |