| HTTP Stavový kód |
Význam kódu |
| 100 |
Klient by měl pokračovat v odesílání požadavku. Tato dočasná odpověď slouží k informování klienta, že část jeho požadavku byla na server přijata, a zatím nebyla odmítnuta. Klient by měl pokračovat v odesílání zbývající části požadavku, nebo pokud je požadavek již dokončen, tuto odpověď ignorovat. Server musí po dokončení požadavku zaslat klientovi konečnou odpověď. |
| 101 |
Server již porozuměl požadavku klienta a bude prostřednictvím hlavičky Upgrade informovat klienta o použití jiného protokolu k dokončení této žádosti. Po odeslání posledního prázdného řádku této odpovědi server přepne na protokoly definované v hlavičce Upgrade. Takové opatření by mělo být přijato pouze tehdy, je-li přechod na nový protokol výhodnější. Například přechod na novou verzi HTTP může přinést výhody oproti staré verzi, nebo přechod na protokol v reálném čase pro přenos zdrojů, které tuto funkčnost využívají. |
| 102 |
Stavový kód rozšířený protokolem WebDAV (RFC 2518), který představuje pokračování zpracování. |
| 200 |
Požadavek byl úspěšný a požadované hlavičky nebo tělo dat budou vráceny s touto odpovědí. |
| 201 |
Požadavek byl splněn a byl vytvořen nový zdroj podle potřeb požadavku, jehož URI bylo vráceno s informacemi hlavičky Location. Pokud požadovaný zdroj nemůže být okamžitě vytvořen, měl by být vrácen '202 Accepted'. |
| 202 |
Server přijal požadavek, ale ještě jej nezpracoval. Jak může být odmítnut, nakonec tento požadavek může, ale nemusí být proveden. V případech asynchronních operací není nic pohodlnějšího, než vrátit tento stavový kód. Cílem odpovědi vracející kód 202 je umožnit serveru přijmout požadavky pro jiné procesy (například nějakou dávkovou operaci, která se provádí pouze jednou denně), aniž by musel udržovat klienta připojeného k serveru, dokud není celá dávková operace dokončena. Odpověď vracející kód 202 by měla obsahovat informace o aktuálním stavu zpracování v těle odpovědi a odkazy na monitor stavu procesu nebo prognózy, aby uživatel mohl odhadnout, zda byla operace dokončena. |
| 203 |
Server úspěšně zpracoval požadavek, ale vracené hlavičky entity nejsou platnou sadou dat na původním serveru, ale jsou kopiemi z místních nebo třetích stran. Aktuální informace mohou být podmnožinou nebo nadmnožinou původní verze. Například metadata zahrnující zdroje mohou znamenat, že původní server zná metadata jako super. Použití tohoto stavového kódu není nutné a je vhodné pouze tehdy, pokud by odpověď jinak vrátila kód 200 OK bez tohoto stavového kódu. |
| 204 |
Server úspěšně zpracoval požadavek, ale není potřeba vracet žádný obsah entity a doufá, že aktualizované hlavičky se vrátí. Odpověď může vracet nové nebo aktualizované hlavičky prostřednictvím hlavičky entity. Pokud tyto hlavičky existují, měly by odpovídat požadovaným proměnným. Pokud je klient webový prohlížeč, uživatelský prohlížeč by měl zachovat stránku, která odeslala tento požadavek, aniž došlo ke změnám zobrazení dokonce podle standardu, nové nebo aktualizované hlavičky by měly být aplikovány na dokument v aktivním zobrazení prohlížeče uživatele. Protože odpověď 204 je zakázána pro jakékoli tělo zprávy, vždy končí s prvním prázdným řádkem po hlavičkách zprávy. |
| 205 |
Server úspěšně zpracoval požadavek a nevrátil žádný obsah. Nicméně, na rozdíl od odpovědi 204, odpověď vracející tento stavový kód vyžaduje od žadatele resetování zobrazení dokumentu. Tato odpověď se využívá hlavně pro okamžité resetování formuláře po přijetí uživatelského vstupu, aby uživatel mohl snadno začít nový vstup. Stejně jako odpověď 204, tato odpověď je také zakázána pro jakékoli tělo zprávy a končí prvním prázdným řádkem po hlavičkách zprávy. |
| 206 |
Server úspěšně zpracoval část požadavku GET. Nástroje pro stahování HTTP, jako jsou FlashGet nebo Thunder, používají tyto odpovědi k provedení přenosu s přerušením nebo rozdělení velkého dokumentu na několik segmentů stahování souběžně. Tento požadavek musí obsahovat hlavičku Range, aby naznačil, který rozsah obsahu klient chce obdržet, a může obsahovat If-Range jako podmínku požadavku. Odpověď musí obsahovat následující hlavičku Content-Range k indikaci rozsahu vráceného obsahu; pokud je Content-Type multipart/byteranges pro více segmentové stahování, měla by každá multipart sekce obsahovat hlavičku Content-Range, která udává rozsah obsahu této sekce. Pokud odpověď obsahuje Content-Length, jeho hodnota musí odpovídat skutečné velikosti bajtů vráceného obsahu. Date ETag a/nebo Content-Location, pokud stejný požadavek by měl vrátit odpověď 200. Expires, Cache-Control a/nebo Vary, pokud mohou mít hodnoty odlišné od dříve uvedených hodnot. Pokud tato odpověď používá ověření silného cache If-Range, pak tato odpověď by neměla obsahovat žádné další hlavičky entity; pokud tato odpověď byla použitá slabým cache ověřením If-Range, pak tato odpověď zakazuje další hlavičky; tato opatření se vyhnout nesouladu mezi obsahem entity v cache a aktualizovanými hlavičkami entity. Jinak tato odpověď by měla zahrnovat všechny hlavičky entity, které by měly být vráceny v odpovědi 200. Pokud hlavičky ETag nebo Last-Modified nemohou být přesně shodny, klientský cache by mělo zabránit sloučení obsahu z odpovědi 206 s jakýmkoliv předtím cached obsahem. Jakýkoliv cache, který nepodporuje hlavičky Range nebo Content-Range, je zakázán.
|
| 207 |
Rozšířený stavový kód WebDAV (RFC 2518), který představuje, že další tělo zprávy bude XML zpráva a mohou obsahovat různé odpovědní kódy v závislosti na počtu předchozích podpožadavků. |
| 300 |
Požadovaný zdroj má řadu návrhů, z nichž každý má svou vlastní adresu a obchodní informace vyžádané prohlížečem. Uživatel nebo prohlížeč může vybrat preferovanou adresu pro přesměrování. Kromě konkrétní žádosti, na kterou se tento stav aplikuje, tato odpověď by měla mít obsahující seznam atributů a adres zdroje, aby uživatel nebo prohlížeč mohli vybrat nejvhodnější adresu. Formát tohoto obsahu je určen typem obsahu. Prohlížeč může učinit automaticky nejsprávnější výběr v závislosti na formátu a vlastnostech prohlížeče. Samozřejmě, standardy RFC 2616 nekonkrétně říkají, jak se provádí takový automatický výběr. Pokud má server preferovaný návrh, měl by tento návrh vyznačit URI v hlavičce Location; prohlížeč by mohl automaticky použít tuto hodnotu jako přesměrovací adresu. Kromě toho, pokud není uvedeno jinak, tato odpověď je také cacheovatelná. |
| 301 |
Požadovaný zdroj byl trvale převeden na nové umístění a budoucí reference na tento zdroj by měly používat jedno z několika URI vrácených touto odpovědí. Pokud je to možné, klienti, kteří mají schopnost upravit odkazy, by měli automaticky změnit požadovanou adresu na adresu vrácenou serverem. Kromě toho, pokud není uvedeno jinak, tato odpověď je také cacheovatelná. Nové trvalé URI by mělo být vráceno v hlavičce Location. Pokud to není žádost HEAD, měl by obsah odpovědi obsahovat hypertextový odkaz na nové URI s krátkým vysvětlením. Pokud to není žádost GET nebo HEAD, prohlížeč by měl zakázat automatické přesměrování, pokud není potvrzeno uživateli, protože podmínky požadavku mohou být změněny. Všimněte si, že pro některé prohlížeče používající protokol HTTP/1.0, pokud je jejich POST požadavek proveden s odpovědí 301, následující přesměrování bude mít formát GET. |
| 302 |
Požadovaný zdroj nyní odpovídá dočasně z jiného URI. Jelikož je toto přesměrování dočasné, klient by měl i nadále posílat budoucí požadavky na původní adresu. Jen tehdy, když je uvedeno v Cache-Control nebo Expires, je tato odpověď cacheovatelná. Nové dočasné URI by mělo být vráceno v hlavičce Location. Kromě toho, pokud to není žádost HEAD, měl by obsah odpovědi obsahovat hypertextový odkaz na nové URI s krátkým vysvětlením. Pokud to není žádost GET nebo HEAD, prohlížeč zakáže automatické přesměrování, pokud není potvrzeno uživateli, neboť podmínky požadavku mohou být tímto způsobem změněny. I přesto, aby RFC 1945 a RFC 2068 svázali klienta, aby během přesměrování neměnil metody požadavku, mnoho existujících prohlížečů interpretuje odpověď 302 jako 303 a umožní přístup k URI specifikovanému v hlavičce Location s metodou GET, ignoruje tak původní metodu požadavku. Stavové kódy 303 a 307 byly přidány, aby objasnily, jakou reakci očekává server od klienta. |
| 303 |
Odpověď odpovídající aktuálnímu požadavku může být nalezena na jiném URI a klient by měl přistoupit k tomuto zdroji způsobem GET. Tato metoda byla zavedena, aby umožnila výstup redirectu z skriptem aktivovaných požadavků POST směrem na nový zdroj. Toto nové URI není alternativním odkazem na původní zdroj. Zatímco odpověď 303 se zakazuje od cacheování, druhý požadavek (redirect) může být cacheovatelný. Nové URI by mělo být vráceno v hlavičce Location a kromě toho, pokud to není žádost HEAD, by obsah odpovědi měl obsahovat hypertextový odkaz na nové URI s krátkým vysvětlením. Všimněte si, že starší prohlížeče verze HTTP/1.1 nemusí správně rozumět stavu 303. Pokud vyžaduje interakce s těmito prohlížeči, měl by být použit stav 302, protože většina prohlížečů zpracovává odpověď 302 přesně tím, co normy vyžadují pro klienty k provedení 303 odpovědi. |
| 304 |
Pokud klient poslal podmíněný požadavek GET a tento požadavek byl povolen a obsah dokumentu (od poslední návštěvy nebo na základě podmínky požadavku) se nezměnil, server by měl vrátit tento stavový kód. Odpověď 304 zakazuje zahrnout tělo zprávy a vždy končí prvním prázdným řádkem po hlavičkách zprávy. Tato odpověď musí obsahovat následující hlavičky: Date, pokud server nemá hodiny. Jestliže server bez časomíry dodržuje tyto normy, pak proxy servery i klienti si mohou přidat Date do přijímaných hlaviček odpovědi (jak je uvedeno v RFC 2068), aby cache mechanismy pracovaly normálně. ETag a/nebo Content-Location, pokud stejně měly vrátit 200 odpověď. Expires, Cache-Control a/nebo Vary, pokud jejich hodnoty mohou dělat rozdíly od dříve dohodnutých hodnot. Pokud je tento požadavek marketingován jako slabé ověřování cache, tato odpověď by neměla zahrnovat jiné hlavičky entity; jinak (například podmíněný požadavek GET používající slabé ověřování cache), tato odpověď zakazuje hlavičky entity; tímto způsobem se vyhnete nesouladu mezi obsahem entity v cache a aktualizovanými hlavičkami entity. Pokud odpověď 304 ukazuje, že určité entity nejsou v cache, musí cache systém ignorovat tuto odpověď a opakovat požadavek bez omezujících podmínek. Pokud obdržíte 304 odpověď k aktualizaci současného položky v cache, musí systém cache aktualizovat celé položky tak, aby odrážela všechny aktualizované hodnoty zmíněné v odpovědi. |
| 305 |
Požadovaný zdroj musí být přístupný prostřednictvím specifikovaného proxy serveru. V hlavičce Location bude informace o URI daného proxy serveru, přijímač musí opakovaně poslat samostatný požadavek, aby mohl prostřednictvím tohoto proxy serveru přistupovat k požadovanému zdroji. Pouze původní server může zavést 305 odpověď. Všimněte si, že RFC 2068 výslovně neupravuje využití 305 odpovědi pro přesměrování samostatného požadavku a má být pouze vytvářeno původním serverem. Ignorování těchto požadavků může mít vážné bezpečnostní důsledky. |
| 306 |
Aktuální systém norem již stavový kód 306 nevyužívá. |
| 307 |
Požadovaný zdroj nyní odpovídá dočasně z jiného URI. Jelikož toto přesměrování je dočasné, klient by měl pokračovat v odesílání dalších požadavků na původní adresu. Tato odpověď je cacheovatelná pouze v případě, že to bylo uvedeno v Cache-Control nebo Expires. Nové dočasné URI by mělo být vráceno v hlavičce Location. Při tomto typu požadavku, kdy to není žádost HEAD, musí obsah odpovědi obsahovat hypertextový odkaz na nové URI doplněný krátkým vysvětlením. U jakýchkoliv prohlížečů, které nedokáží identifikovat 307 odpověď, je zapotřebí poskytnout předepsané informace tak, aby uživatel pochopil a mohl poslat požadavek na nový URI. Pokd to není GET nebo HEAD požadavek, pak prohlížeč zakáže automatické přesměrování, pokud uživatel nepotvrdí, protože jeho podmínky požadavku mohou být tímto způsobem změněny. |
| 400 |
1. Semantické chyby, aktuální požadavek nemůže být serverem pochopen. Klient by neměl tento požadavek opakovat, pokud se nezmění. 2. Chyba v parametrech požadavku. |
| 401 |
Aktuální požadavek vyžaduje ověření uživatele. Tato odpověď musí obsahovat hlavičku WWW-Authenticate vztahující se k požadovanému zdroji, aby se dotázala na uživatelské informace. Klient může znovu odeslat požadavek s vhodnou autentizací v hlavičce Authorization. Pokud požadavek již obsahuje autentizační certifikáty, může 401 odpověď reprezentovat, že server už odmítl tyto certifikáty. Pokud 401 odpověď obsahuje stejnou otázku o ověření jako předchozí odpověď a prohlížeč již alespoň jednou udělal pokus o ověření, měl by prohlížeč ukázat obsah entity obsažený v odpovědi, protože tento obsah může obsahovat související diagnostické informace. Odkaz: RFC 2617. |
| 402 |
Tento stavový kód je vyhrazen pro potřeby budoucího využití. |
| 403 |
Server rozuměl požadavku, avšak odmítl jeho vykonání. Na rozdíl od 401 odpovědi, ověření nemůže poskytnout žádnou pomoc a tento požadavek by neměl být opakovaně proveden. Pokud to není žádost HEAD a server chce, aby bylo jasné, proč požadavek nemůže být vykonán, měl by být důvod odmítnutí popsán v entitě odpovědi. Server může také vrátit 404 odpověď, pokud si nepřeje, aby klient získával nějaké informace. |
| 404 |
Požadavek selhal a požadovaný zdroj nebyl nalezen na serveru. Neexistují žádné informace, které by uživateli říkaly, zda je tento stav dočasný nebo trvalý. Pokud server situaci zná, měl by se s ní vypořádat pomocí stavu 410, aby oznámil, že starý zdroj je kvůli nějakému vnitřnímu problému trvale nedostupný a žádná alternativa k němu neexistuje. Stav 404 je široce aplikován, když server nechce odhalit důvody, proč byl požadavek odmítnut nebo neexistují žádné další vhodné odpovědi aplikovány. |
| 405 |
Metoda požadavku uvedená v žádosti nelze použít k požadovanému zdroji. Odpověď musí vrátit hlavičku Allow, která udává seznam akceptovatelných metod požadavku pro aktuální zdroj. Vzhledem k tomu, že metody PUT a DELETE provádí zápis operace na zdroje na serveru, většina webových serverů je buď nepodporuje nebo je ve výchozím stavu zakáže, a vrátí 405 chybu na takové požadavky. |
| 406 |
Obsah požadavku nelze shodnout s podmínkami ve hlavičkách požadavku, a tím pádem nelze vygenerovat odpověď. Pokud to není žádost HEAD, tato odpověď by měla vrátit obsah obsahující seznam vhodných atributů a adres pro volbu uživatele nebo prohlížeče. Formát obsahu by měl být určen jednotlivými typy hlavních magazínů definovaných v hlavičce Content-Type. Prohlížeč by měl automaticky vybrat nejlepší výběr na základě formátu a svých vlastností. Nicméně normy nelze definovat jak řídit takové automatizované výběry. |
| 407 |
Podobně jako odpověď 401, klient ovšem musí provést ověření u proxy serveru. Proxy server musí servírovat požadavek Proxy-Authenticate pro otázku na ověření. Klient může vrátit požadavek s hlavičkou Proxy-Authorization pro ověření. Odkaz: RFC 2617. |
| 408 |
Časový limit požadavku. Klient nedokončil odeslání požadavku v časovém rámce, který server očekával. Klient může vždy znovu odeslat tento požadavek bez provedení jakýchkoliv změn. |
| 409 |
Požadavek nelze splnit kvůli konfliktu s aktuálním stavem požadovaného zdroje. Tento kód může být použit pouze v situaci, kde je uživatel má schopnost vyřešit konflikt a znovu odesílá nový požadavek. Tato odpověď by měla poskytnout dostatečné informace, aby uživatel identifikoval příčinu konfliktu. Konflikty se obvykle vyskytují během zpracování požadavku PUT. Například, pokud se v prostředí, kde se používá kontrola verzí, spojení požadavku PUT s určitým zdrojem neshodne s dřívějšími (třetími stranami) požadavky na konfliktu, server by pak měl vrátit 409 chybu a vyrozumět uživatele o neúspěchu žádosti. Odpověď entity by v tomto případě mohla obsahovat porovnání mezi dvěma konfliktními verzemi, aby uživatel odesílal nový, slučující se verzi. |
| 410 |
Požadovaný zdroj je nyní trvale nedostupný na serveru a nejsou k dispozici žádné známé nahrazující adresy (forwarding addresses). Tento stav by měl být považován za trvalý. Pokud je to možné, klienti s editorem odkazů by měli po obdržení svolení uživatele smazat všechny odkazy na tento odkaz. Pokud server neví nebo nemůže rozhodnout, zda je tento stav přetrvávající, měl by použít stav 404. Kromě toho, pokud není uvedeno jinak, je tato odpověď cacheovatelná. Cílem rychlého 410 oznámení je pomoci správcům webu udržovat webové stránky a informovat uživatele, že zdroj je již nedostupný a majitel serveru by chtěl, aby všechny vzdálené odkazy na tento zdroj byli odstraněny. Tyto události jsou velmi často průběžné pro služby s omezeními a hodnotami. Také stavový kód 410 se používá k informování klienta, že některé zdroje dříve náležející určité osobě již nejsou dostupné na aktuálním serveru. Samozřejmě je na vlastníkovi serveru, zda má označovat trvalé nedostupné zdroje jako '410 Gone', nebo jak dlouho má tento stav platit. |
| 411 |
Server odmítá přijmout požadavek bez definované hlavičky Content-Length. Klient může znovu odeslat tento požadavek po přidání platné hlavičky Content-Length, která naznačuje délku těla požadavku. |
| 412 |
Server nedokázal splnit jednu nebo více předpokladů uvedených v hlavičkách požadavku. Tento stavový kód umožňuje klientovi nastavit v hlavičkách požadavku předpoklady, aby se vyhnul aplikaci dané metody požadavku na nezajištěné zdroje. |
|
| 413 |
Server odmítá zpracovat aktuální požadavek, protože velikost entity zaslané v požadavku překročila limity, které server je ochoten nebo schopen zpracovat. V takovém případě může server zavřít spojení, aby se vyhnul dalšímu zaslání požadavku ze strany klienta. Pokud je tato situace dočasná, server by měl vrátit hlavičku Retry-After, aby informoval klienta, kdy se může pokusit znovu. |
| 414 |
Požadovaný URI překročil maximální délku, kterou server je schopen zpracovat, a proto server odmítá žádat o zpracování. To je obvykle způsobeno tím, že by se mělo použít POST pro zaslání formuláře, ale stalo se to GET, kdy se argumenty dotazu (Query String) příliš prodloužily. "Černá díra" přesměrování URI, kvůli které by se staré URI přidala jako část nového URI vedoucí k příliš dlouhému URI po několika přesměrováních. Klient se pokouší napadnout server pomocí některých známých zranitelností. Tyto servery využívají fixed-length must-have buffer probes z URI požadavků a když určité parametry po GET překročí daný počet, může to vést k překročení bufferu a spouštění libovolného kódu. Servery bez těchto zranitelností by měly vrátit stavový kód 414. |
| 415 |
Vztahující se k aktuálnímu požadavku, metoda a požadovaný zdroj neodpovídají formátu entity zaslané v požadavku, a proto byla žádost odmítnuta. |
| 416 |
Pokud požadavek obsahoval hlavičku Range a jakékoli datové oblasti uvedené v Range nesouhlasily s dostupnými oblastmi zdroje, a v požadavku nebyla uvedena hlavička If-Range, pak by server měl vrátit stavový kód 416. Pokud používá Range, který se vztahuje k bajtům, pak to znamená, že všechny počáteční pozice bajtů specifikované v požadavku znamenají překročení délky aktuálního zdroje. Server by také měl zahrnovat hlavičku Content-Range v odpovědi, aby určil současnou délku zdroje. Tento stav by neměl používat multipart/byteranges jako svůj Content-Type. |
| 417 |
Očekávané obsahy uvedené v hlavičce Expect nemohou být splněny serverem, nebo je server proxy server s jasnými důkazy, že na následujícím uzlu tato očekávání nemohou být splněna. |
| 421 |
Počet připojení ze stávající IP adresy klienta na server překročil maximální povolenou míru. Typicky je tato IP adresa z pohledu serveru adresou klienta (například adresou brány nebo proxy serveru uživatele). V takovém případě může být počet připojení počítán více než jedním koncovým uživatelským přístupem. |
| 422 |
Požadavek je dobře formátován, avšak z důvodu obsahových chyb nemůže být zpracován. (RFC 4918 WebDAV) 423 Locked: aktuální zdroj je zablokován. (RFC 4918 WebDAV) |
| 424 |
Požadavek selhal kvůli chybě v předchozím požadavku, například PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definované v návrhu WebDav Advanced Collections, ale nezmíněné v RFC 3658 o protokolu WebDAV pro sekvence. |
| 426 |
Klient by měl přejít na TLS/1.0. (RFC 2817) |
| 449 |
Rozšířeno Microsoftem, znamená, že požadavek by měl být zopakován po provedení příslušných operací. |
| 500 |
Server se setkal s nepředvídanou situací, což způsobilo, že nebyl schopen splnit požadavek. Obecně se tento problém objevuje, když došlo k chybě ve skriptu serveru. |
| 501 |
Server nepodporuje funkci vyžadovanou aktuálním požadavkem. Když server nedokáže rozpoznat metodu požadavku a nemůže splnit tyto požadavky pro žádný zdroj. |
| 502 |
Server, který funguje jako brána nebo proxy, obdržel neplatnou odpověď při pokusu o vykonání požadavku od tohoto serveru. |
| 503 |
Server aktuálně nemůže zpracovat požadavek kvůli dočasné údržbě nebo přetížení serveru. Tento stav je dočasný a po určité době by měl být obnoven. Pokud lze přibližně předvídat, jak dlouho zpoždění bude jednání, může odpověď obsahovat hlavičku Retry-After, která ukazuje, jak brzy lze pokusit o další požadavek. Pokud není uvedena žádná informace Retry-After, měl by klient kontrolovat odpověď 500 jako bezpodmínečnou. |
| 504 |
Server, který funguje jako brána nebo proxy, nebyl schopen rychle obdržet odpověď z upstream serveru (server definovaného v URI, například HTTP, FTP, LDAP) nebo pomocného serveru (např. DNS). Všimněte si, že některé proxy servery mohou vrátit 400 nebo 500 chybu, když server DNS překročí časový limit. |
| 505 |
Server nepodporuje nebo odmítá podporovat HTTP verzi použitou v požadavku. To naznačuje, že server nemůže nebo nechce používat stejnou verzi, jako klient. Odpověď by měla obsahovat text, který vysvětluje, proč není verze podporována a které protokoly server podporuje. |
| 506 |
Rozšířený stavový kód dle Transparent Content Negotiation Protocol (RFC 2295), představuje, že server má interní konfigurační chybu: zdroje požadované pro vyjednávání byly nastaveny na jejich použití v transparentním vyjednávání, čímž byly nepřiměřeně zobrazeny jako priorita zvyklostí. |
| 507 |
Server nemůže uložit obsah potřebný k dokončení požadavku. Tento stav se považuje za dočasný. WebDAV (RFC 4918) |
| 509 |
Server dosáhl limitu šířky pásma. Toto není oficiální stavový kód, ale stále je široce používán. |
| 510 |
Politika požadovaná pro získání zdroje nebyla splněna. (RFC 2774) |