Online nástroje
Stavové kódy http Význam stavového kódu
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 Upgrade oznámí klientovi, že k dokončení požadavku byl použit jiný protokol. Po odeslání posledního prázdného řádku odpovědi server přejde na protokoly definované v hlavičce 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 může být výhodnější než na starší verzi nebo přechod na synchronní protokol pracující v reálném čase pro doručování prostředků, které takové vlastnosti využívají.
102 Stavové kódy, rozšířené protokolem WebDAV (RFC 2518), označují, že zpracování bude pokračovat.
200 Požadavek byl úspěšný a spolu s odpovědí budou vráceny hlavičky nebo tělo dat požadované požadavkem.
201 Požadavek byl splněn a v reakci na požadavek byl vytvořen nový prostředek, jehož URI byl vrácen spolu s hlavičkou Location. Pokud nelze požadovaný prostředek vytvořit včas, měl by být vrácen následující údaj'202 Accepted'。
202 Server požadavek přijal, ale ještě jej nezpracoval. Stejně jako může být odmítnut, může, ale nemusí být požadavek nakonec proveden. V případě asynchronních operací není nic vhodnějšího než zaslání tohoto stavového kódu. Účelem vrácení odpovědi 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 udržovat spojení se serverem, dokud není dávková operace dokončena. Odpověď, která přijímá požadavek na zpracování a vrací stavový kód 202, by měla ve vrácené entitě obsahovat určitou informaci udávající aktuální stav procesu a také ukazatel na monitor stavu zpracování nebo předpověď stavu, aby uživatel mohl odhadnout, zda operace byla či nebyla 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ích informací. 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 tyto hlavičky existují, měly by odpovídat požadovaným proměnným. Pokud je klientem prohlížeč, měl by prohlížeč uživatele zachovat stránku, na které byl požadavek odeslán, beze změn v zobrazení dokumentu, i když nové nebo aktualizované metainformace by podle specifikace měly být použity 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 záhlavím zprávy.
205 Server požadavek úspěšně vyřídí a nic nevrací. 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 nesmí tato odpověď obsahovat žádné 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 souboru do více 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 hlavičky: Content-Range pro označení rozsahu obsahu vráceného v této odpovědi nebo v případě stahování více částí s Content-Type multipart/byteranges pole Content-Range v každém segmentu více částí pro označení rozsahu obsahu v tomto segmentu. Pokud odpověď obsahuje pole Content-Length, musí jeho hodnota odpovídat skutečnému počtu bajtů v rozsahu vráceného obsahu. 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ěď by neměla obsahovat jiné hlavičky entit, pokud požadavek používá silnou validaci mezipaměti If-Range, a neměla by obsahovat jiné hlavičky entit, pokud požadavek používá slabou validaci mezipaměti If-Range; tím se zamezí nesouladu mezi obsahem entity v mezipaměti a aktualizovanými informacemi v hlavičce entity. 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 v odpovědi 200. Pokud se hlavičky ETag nebo Last-Modified přesně neshodují, měla by mezipaměť na straně klienta 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ódy rozšířené pomocí WebDAV(RFC 2518) Stavový kód rozšířený pomocí WebDAV 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 odpovědí, z nichž každá má svou vlastní specifickou adresu a informace o vyjednávání podle prohlížeče. Je na uživateli nebo prohlížeči, aby si vybral 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 měl být tento automatický výběr proveden. Pokud již server sám má preferovanou možnost návratu, měl by být URI návratu uveden v Location; prohlížeče mohou tuto hodnotu Location použít jako adresu pro automatické přesměrování. Kromě toho je odpověď 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č nesmí automaticky přesměrovat, pokud to uživatel nepotvrdí, protože podmínky požadavku se mohou v důsledku toho 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, další požadavek na přesměrování bude 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. Odpověď je možné 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 měnit metodu požadavku během přesměrování, mnoho stávajících prohlížečů považuje odpověď 302 za odpověď 303 a používá 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í náhradním odkazem na původní prostředek. Rovněž není povoleno 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 fungovat stavový kód 302, protože většina prohlížečů zpracovává odpověď 302 přesně tak, jak výše uvedená specifikace vyžaduje, aby klient zpracovával odpověď 303.
304 Tento stavový kód by měl server vrátit, pokud klient odešle podmíněný požadavek GET a požadavek je povolen a obsah dokumentu se nezměnil (buď od poslední návštěvy, nebo podle podmínek požadavku). 304 odpovědi mají zakázáno 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í informace v hlavičce: Datum, pokud server nemá hodiny. Pokud server nemá hodiny, řídí se těmito pravidly, pak proxy server a klient mohou sami přidat pole Datum do hlavičky příchozí odpovědi (jak je uvedeno v RFC 2068) a mechanismus ukládání do mezipaměti bude fungovat správně. ETag a/nebo Content-Location, pokud stejný požadavek měl vrátit odpověď 200. 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. Pokud požadavek na odpověď používá silnou validaci mezipaměti, pak by odpověď neměla obsahovat další 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 odpověď obsahovala další 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í aktuálně 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 určeného proxy serveru a 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í může mít vážné bezpečnostní důsledky.
306 V nejnovější verzi specifikace se stavový kód 306 již nepoužívá.
307 Požadované zdroje nyní dočasně odpovídají na požadavky z různých URI. Protože toto přesměrování je dočasné, klienti by měli 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 nutné 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, sémantická chyba, aktuálnímu požadavku server nerozumí. Pokud není změněn, klient by neměl požadavek opakovat. 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 znovu odeslat požadavek s příslušnými informacemi v hlavičce 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č již provedl alespoň jeden pokus o ověření, pak by měl prohlížeč zobrazit uživateli informace o entitě obsažené v odpovědi, protože tyto informace o entitě mohou obsahovat relevantní 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 požadavek by neměl být znovu odeslán. Pokud se nejedná o požadavek HEAD a server chce být schopen sdělit, proč nelze požadavek provést, pak by měl být důvod odmítnutí popsán v entitě. Server samozřejmě může také vrátit odpověď 404, pokud nechce, aby klient dostal žádné informace.
404 Požadavek se nezdařil, požadovaný prostředek nebyl na serveru nalezen. Uživateli není k dispozici informace, 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 ho 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á, když server nechce prozradit, proč byl požadavek odmítnut, nebo když 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ů je ve výchozím nastavení nepodporuje nebo 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, která obsahuje nejvhodnější charakteristiky entity a seznam adres, z nichž si uživatel nebo prohlížeč může vybrat. Formát entity je určen typem média definovaným v hlavičce Content-Type. Prohlížeč může provést nejlepší výběr na základě formátu a svých vlastních možností. 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 u proxy serveru. Proxy server MUSÍ vrátit zprávu Proxy-Authenticate pro dotaz na identitu. Klient může vrátit hlavičku Proxy-Authorisation pro ověření pravosti. Viz RFC 2617.
408 Časový limit požadavku. Klient nedokončil požadavek 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 nemohl být dokončen 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 často dochází při zpracování požadavků PUT. Například v prostředí s kontrolou verzí by měl požadavek PUT odeslaný za účelem úpravy určitého prostředku s informacemi o verzi, které jsou v konfliktu s předchozím požadavkem (třetí strany), vrátit chybu 409 informující 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 znovu odeslat novou, sloučenou verzi.
410 Požadovaný prostředek již není na serveru k dispozici a není známa žádná adresa pro předání. Taková situace by měla být považována za trvalou. 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 stav trvalý, měl by být použit stavový kód 404. Pokud není uvedeno jinak, je tato odpověď kešovatelná. Účelem odpovědi 410 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í klientovi, že prostředek patřící jednotlivci již není na aktuálním místě serveru dostupný. Důležitá je samozřejmě také otázka, zda je třeba takto označit všechny trvale nedostupné prostředky a jak dlouho je takto uchovávat.'410 Gone'， A jak dlouho by měla být udržována, záleží pouze na vlastníkovi serveru.
411 Server odmítá přijímat požadavky bez definované hlavičky Content-Length. Klient může požadavek znovu odeslat po přidání platné hlavičky Content-Length udávající délku těla zprávy požadavku.
412 Server při ověřování požadavku nesplnil jednu nebo více podmínek uvedených v poli záhlaví požadavku. Tento stavový kód umožňuje klientovi nastavit předběžné podmínky v metainformacích 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á více fyzických dat, 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í požadavku. Pokud je situace dočasná, měl by server vrátit hlavičku Retry-After, aby informoval klienta, kolik času má na opakování.
414 URI požadavku je delší, než je server schopen interpretovat, proto server odmítne požadavek obsloužit. Tato situace je vzácná a obvykle k ní dochází, když 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 pro každé 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é existují v některých serverech. Takové servery používají ke čtení nebo manipulaci s požadovaným URI vyrovnávací paměť s pevnou délkou, což může vést k přetečení vyrovnávací paměti, pokud parametr GET překročí určitou hodnotu, což může vést 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 a požadavek je odmítnut.
416 Pokud požadavek obsahuje hlavičku požadavku Range a veškeré rozsahy dat uvedené v Range se neshodují 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á bajtové rozsahy, pak to znamená, že první 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á určuje délku aktuálního prostředku spolu se stavovým kódem 416. U této odpovědi je také zakázáno používat jako Content-Type (typ obsahu) multipart/byteranges.
417 Očekávaný obsah specifikovaný v hlavičce požadavku Expect nemůže být serverem splněn nebo je 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 aktuálního klienta 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 být do počtu připojení zapojeno více koncových uživatelů.
422 Počet spojení z IP adresy aktuálního klienta na server přesahuje maximum povolené serverem. Typicky se zde IP adresou rozumí adresa klienta, jak je vidět ze serveru (např. adresa brány nebo proxy serveru uživatele). V tomto případě může být do počtu připojení zapojeno více koncových uživatelů.
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) 423 Uzamčeno
424 Aktuální požadavek selhal kvůli chybě 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 nepředvídanou 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 funkci požadovanou aktuálním požadavkem. Když server nerozpozná požadovanou metodu a nemůže podpořit její požadavek na žádný 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 momentálně není 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 prostě chtějí klientovi odepřít připojení.
504 Server fungující jako brána nebo proxy server, který se pokouší provést požadavek, nedostane 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 jaké 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 v procesu Transparent Content Negotiation, a proto není vhodným cílem v procesu vyjednávání.
507 Server není schopen uložit obsah potřebný ke splnění 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 se hojně používá.
510 Nebyly splněny zásady požadované k získání zdroje. (RFC 2774)
Přístup k záznamům: