| Stavový kód Http | Stavový kód Význam |
|---|
| 100 | Klient by mal pokračovať v odosielaní požiadaviek. Táto dočasná odpoveď sa používa na informovanie klienta, že časť jeho požiadavky bola serverom prijatá a nebola zamietnutá. Klient by mal pokračovať v odosielaní zvyšnej časti požiadavky alebo ignorovať túto odpoveď, ak je požiadavka úplná. Server musí klientovi poslať konečnú odpoveď, keď je požiadavka úplná. |
| 101 | Server porozumel požiadavke klienta a prostredníctvom hlavičky správy Upgrade oznámi klientovi, aby na dokončenie požiadavky použil iný protokol. Po odoslaní posledného prázdneho riadku tejto odpovede server prepne na tie protokoly, ktoré sú definované v hlavičke správy Upgrade. Toto by sa malo vykonať len vtedy, ak je výhodnejšie prejsť na nový protokol. Napríklad prechod na novú verziu protokolu HTTP je výhodnejší ako prechod na staršiu verziu alebo prechod na protokol pracujúci v reálnom čase a synchrónny protokol na doručovanie zdrojov, ktoré využívajú takéto vlastnosti. |
| 102 | Stavové kódy rozšírené o WebDAV (RFC 2518) vyjadrujú, že spracovanie bude pokračovať. |
| 200 | Požiadavka bola úspešná a spolu s touto odpoveďou sa vráti hlavička alebo telo údajov požadované v požiadavke. |
| 201 | Požiadavka bola splnená a nový prostriedok bol vytvorený podľa požiadavky a jeho URI bol vrátený spolu s hlavičkou Location. Ak sa požadovaný zdroj nedá vytvoriť včas, mala by sa vrátiť správa "202 Accepted" (Prijaté). |
| 202 | Server prijal požiadavku, ale ešte ju nespracoval. Rovnako ako môže byť odmietnutá, nakoniec môže, ale nemusí byť požiadavka vykonaná. V kontexte asynchrónnych operácií nie je nič vhodnejšie ako odoslanie tohto stavového kódu. Účelom vrátenia odpovede so stavovým kódom 202 je umožniť serveru prijímať požiadavky z iných procesov (napríklad dávkové operácie, ktoré sa vykonávajú len raz za deň) bez toho, aby musel klient zostať pripojený k serveru, kým sa dávková operácia úplne nedokončí. Odpoveď, ktorá prijíma požiadavku na spracovanie a vracia stavový kód 202, MUSÍ vo vrátenej entite obsahovať určitú informáciu označujúcu aktuálny stav procesu, ako aj ukazovateľ na monitor stavu spracovania alebo predpoveď stavu, aby používateľ mohol odhadnúť, či sa operácia dokončila. |
| 203 | Server úspešne spracoval požiadavku, ale metainformácie v hlavičke vrátenej entity nie sú definitívnym súborom platným na pôvodnom serveri, ale kópiou od miestnej alebo tretej strany. Aktuálne informácie môžu byť podmnožinou alebo nadmnožinou pôvodnej verzie. Napríklad metadáta obsahujúce zdroje môžu spôsobiť, že pôvodný server pozná metainformácie super. Použitie tohto stavového kódu nie je povinné a je vhodné len vtedy, ak by sa odpoveď bez neho vrátila 200 OK. |
| 204 | Server úspešne spracoval požiadavku, ale nepotrebuje vrátiť žiadny fyzický obsah a chce vrátiť aktualizované metainformácie. Odpoveď môže vrátiť nové alebo aktualizované metainformácie vo forme hlavičiek entít. Ak takéto hlavičky existujú, mali by zodpovedať požadovaným premenným. Ak je klientom prehliadač, potom prehliadač používateľa MUSÍ zachovať stránku, na ktorej bola požiadavka odoslaná, bez akýchkoľvek zmien zobrazenia dokumentu, hoci podľa špecifikácie sa nové alebo aktualizované metainformácie MUSIA použiť na dokument v aktívnom zobrazení prehliadača používateľa. Keďže odpoveď 204 nesmie obsahovať žiadne telo správy, končí vždy prvým prázdnym riadkom za hlavičkou správy. |
| 205 | Server úspešne spracoval požiadavku a nevrátil nič. Na rozdiel od odpovede 204 však odpoveď, ktorá vracia tento stavový kód, žiada žiadateľa o obnovenie zobrazenia dokumentu. Táto odpoveď sa primárne používa na resetovanie formulára bezprostredne po prijatí vstupu používateľa, aby mohol používateľ ľahko spustiť ďalší vstup. Podobne ako odpoveď 204, aj táto odpoveď nesmie obsahovať žiadne telo správy a končí prvým prázdnym riadkom za hlavičkou správy. |
| 206 | Server úspešne spracoval časť požiadavky GET. Nástroje na sťahovanie HTTP, ako napríklad FlashGet alebo Thunderbolt, používajú tento typ odpovede na vykonávanie prerušovaného sťahovania alebo na rozdelenie veľkého dokumentu na viacero segmentov sťahovania súčasne. Požiadavka musí obsahovať hlavičku Range (Rozsah), ktorá označuje rozsah obsahu, ktorý chce klient prijať, a môže obsahovať If-Range (Rozsah) ako podmienku požiadavky. Odpoveď musí obsahovať tieto polia hlavičky: Content-Range na označenie rozsahu obsahu vráteného v tejto odpovedi; v prípade sťahovania viacerých segmentov s Content-Type multipart/byteranges by mal každý segment obsahujúci viac častí obsahovať pole Content-Range označujúce rozsah obsahu v danom segmente. Ak odpoveď obsahuje pole Content-Length, jeho hodnota musí zodpovedať skutočnému počtu bajtov v rozsahu vráteného obsahu. date ETag a/alebo Content-Location, ak tá istá požiadavka mala vrátiť odpoveď 200. Expires, Cache-Control a/alebo Vary, ak sa ich hodnoty môžu líšiť od iných odpovedí s rovnakými premennými. Expires, Cache-Control a/alebo Vary, ak sa ich hodnoty môžu líšiť od hodnôt iných predchádzajúcich odpovedí s rovnakými premennými. Táto odpoveď NEMUSÍ obsahovať iné hlavičky entít, ak požiadavka používa silné overenie vyrovnávacej pamäte If-Range, a NEMUSÍ obsahovať iné hlavičky entít, ak požiadavka používa slabé overenie vyrovnávacej pamäte If-Range; tým sa zabráni nekonzistentnosti medzi obsahom entity uloženým v vyrovnávacej pamäti a aktualizovanými informáciami hlavičky entity. V opačnom prípade táto odpoveď MUSÍ obsahovať všetky polia hlavičky entity, ktoré mali byť vrátené vo všetkých odpovediach 200, ktoré mali byť vrátené. Ak sa hlavičky ETag alebo Last-Modified presne nezhodujú, vyrovnávacia pamäť na strane klienta MUSÍ zakázať kombinovanie obsahu vráteného v odpovedi 206 s akýmkoľvek predtým uloženým obsahom v vyrovnávacej pamäti. Každá vyrovnávacia pamäť, ktorá nepodporuje hlavičky Range a Content-Range, nesmie ukladať do vyrovnávacej pamäte obsah vrátený odpoveďou 206. |
| 207 | Stavový kód, ako ho rozšíril WebDAV (RFC 2518), znamená, že telo následnej správy bude správa XML a môže obsahovať sériu samostatných kódov odpovede v závislosti od počtu predchádzajúcich čiastkových požiadaviek. |
| 300 | Požadovaný zdroj má sériu alternatívnych návratových správ, z ktorých každá má svoju vlastnú špecifickú adresu a informácie o vyjednávaní riadené prehliadačom. Používateľ alebo prehliadač si môže sám vybrať preferovanú adresu na presmerovanie. Ak nejde o požiadavku HEAD, odpoveď by mala obsahovať entitu, ktorá je zoznamom charakteristík a adries zdroja, z ktorých si používateľ alebo prehliadač môže vybrať najvhodnejšiu adresu presmerovania. Formát tejto entity je určený formátom definície Content-Type. Prehliadač môže automaticky vykonať najvhodnejší výber na základe formátu odpovede a vlastných možností prehliadača. Samozrejme, špecifikácia RFC 2616 nešpecifikuje, ako by sa mal takýto automatický výber vykonať. Ak už samotný server má preferovaný výber návratu, potom by sa URI tohto návratu mal špecifikovať v položke Location (Umiestnenie); prehliadač môže túto hodnotu Location (Umiestnenie) použiť ako adresu pre automatické presmerovanie. Okrem toho je táto odpoveď tiež uložiteľná do vyrovnávacej pamäte, ak nie je uvedené inak. |
| 301 | Požadovaný prostriedok bol natrvalo presunutý na nové umiestnenie a všetky budúce odkazy naň by mali používať jeden z niekoľkých URI vrátených v tejto odpovedi. Ak je to možné, klienti s možnosťou úpravy odkazov by mali automaticky zmeniť požadovanú adresu na adresu vrátenú zo servera. Ak nie je uvedené inak, táto odpoveď sa tiež ukladá do vyrovnávacej pamäte. Nový trvalý URI by sa mal vrátiť v poli Location (Umiestnenie) odpovede. Ak nejde o požiadavku HEAD, entita odpovede by mala obsahovať hypertextový odkaz na nový URI a krátky opis. Ak nejde o požiadavku GET alebo HEAD, prehliadač preto nesmie automaticky presmerovať, pokiaľ to nepotvrdí používateľ, pretože podmienky požiadavky sa v dôsledku toho môžu zmeniť. Poznámka: V prípade niektorých prehliadačov používajúcich protokol HTTP/1.0, keď odošlú požiadavku POST a dostanú odpoveď 301, ďalšia požiadavka na presmerovanie bude GET. |
| 302 | Požadovaný zdroj teraz dočasne odpovedá na požiadavku z iného URI. Keďže toto presmerovanie je dočasné, klient by mal aj v budúcnosti posielať požiadavky na pôvodnú adresu. Túto odpoveď je možné uložiť do vyrovnávacej pamäte, len ak je uvedená v položke Cache-Control alebo Expires. Nový dočasný URI by sa mal vrátiť v poli Location odpovede. Ak nejde o požiadavku HEAD, entita odpovede by mala obsahovať hypertextový odkaz na nový URI a krátky opis. Ak nejde o požiadavku GET alebo HEAD, prehliadač nesmie automaticky presmerovať, pokiaľ to nepotvrdí používateľ, pretože podmienky požiadavky sa v dôsledku toho môžu zmeniť. Poznámka: Hoci špecifikácie RFC 1945 a RFC 2068 neumožňujú klientovi zmeniť metódu požiadavky pri presmerovaní, mnohé existujúce prehliadače považujú odpoveď 302 za odpoveď 303 a používajú GET na prístup k URI špecifikovanému v Location, pričom ignorujú metódu pôvodnej požiadavky. Stavové kódy 303 a 307 boli pridané s cieľom objasniť, akú odpoveď server očakáva od klienta. |
| 303 | Odpoveď na aktuálnu požiadavku možno nájsť na inom URI a klient by mal k tomuto zdroju pristupovať pomocou GET. Táto metóda existuje predovšetkým preto, aby umožnila presmerovať výstup požiadavky POST aktivovanej skriptom na nový zdroj. Tento nový URI nie je alternatívnym odkazom na pôvodný zdroj. Takisto je zakázané ukladať do vyrovnávacej pamäte odpoveď 303. Samozrejme, druhá požiadavka (presmerovanie) sa môže ukladať do vyrovnávacej pamäte. Nový URI by sa mal vrátiť v poli Location (Umiestnenie) odpovede. Ak nejde o požiadavku HEAD, entita odpovede by mala obsahovať hypertextový odkaz na nový URI a krátky opis. Poznámka: Mnohé prehliadače pred verziami HTTP/1.1 nerozumejú správne stavu 303. Ak je potrebné zvážiť interakciu s týmito prehliadačmi, mal by stačiť stavový kód 302, pretože väčšina prehliadačov spracúva odpovede 302 presne tak, ako to vyžaduje uvedená špecifikácia od klienta pri spracovaní odpovede 303. |
| 304 | Server MUSÍ vrátiť tento stavový kód, ak klient odošle podmienenú požiadavku GET, ktorá bola povolená, a obsah dokumentu (od poslednej návštevy alebo podľa podmienok požiadavky) sa nezmenil. 304 Odpovede nesmú obsahovať telo správy, a preto vždy končia prvým prázdnym riadkom za hlavičkou správy. Odpoveď MUSÍ obsahovať nasledujúce hlavičky: Dátum, pokiaľ server nemá hodiny. Ak server bez hodín dodržiava tieto pravidlá, potom môže proxy server a klient pridať pole Date do hlavičky prichádzajúcej odpovede sám (ako je uvedené v RFC 2068) a mechanizmus ukladania do vyrovnávacej pamäte bude fungovať správne. ETag a/alebo Content-Location, ak by rovnaká požiadavka vrátila odpoveď 200. Expires Expires, Cache-Control a/alebo Vary, ak sa hodnota môže líšiť od hodnoty zodpovedajúcej iným predchádzajúcim odpovediam pre tú istú premennú. Ak táto požiadavka na odpoveď používa silnú validáciu vyrovnávacej pamäte, potom by táto odpoveď nemala obsahovať iné hlavičky entít; v opačnom prípade (napr. podmienená požiadavka GET používa slabú validáciu vyrovnávacej pamäte) táto odpoveď nesmie obsahovať iné hlavičky entít; tým sa zabráni nekonzistencii medzi obsahom entít uloženým v vyrovnávacej pamäti a aktualizovanými informáciami hlavičiek entít. Ak odpoveď 304 naznačuje, že entita nie je v súčasnosti uložená v medzipamäti, systém vyrovnávacej pamäte musí túto odpoveď ignorovať a zopakovať požiadavku bez obmedzenia. Ak sa prijme odpoveď 304 požadujúca aktualizáciu položky vyrovnávacej pamäte, systém vyrovnávacej pamäte MUSÍ aktualizovať celú položku tak, aby odrážala hodnoty všetkých polí aktualizovaných v odpovedi. |
| 305 | K požadovanému prostriedku sa musí pristupovať prostredníctvom určeného proxy servera. pole Location (umiestnenie) poskytne informácie o URI, kde sa nachádza určený proxy server. príjemca by musel opakovane poslať samostatnú žiadosť, aby získal prístup k prostriedku prostredníctvom tohto proxy servera. Odpoveď 305 môže vytvoriť len pôvodný server. Poznámka: Z RFC 2068 nie je jasné, že odpoveď 305 je určená na presmerovanie jednej požiadavky a môže ju vytvoriť len pôvodný server. Ignorovanie týchto obmedzení by mohlo viesť k vážnym bezpečnostným dôsledkom. |
| 306 | V najnovšej verzii špecifikácie sa stavový kód 306 už nepoužíva. |
| 307 | Požadovaný zdroj teraz dočasne odpovedá na požiadavku z iného URI. Keďže takéto presmerovania sú dočasné, klienti by mali naďalej posielať budúce požiadavky na pôvodnú adresu. Túto odpoveď je možné uložiť do vyrovnávacej pamäte, len ak je uvedená v položke Cache-Control alebo Expires. Nový dočasný URI by sa mal vrátiť v poli Location odpovede. Ak nejde o požiadavku HEAD, entita odpovede by mala obsahovať hypertextový odkaz na nový URI a krátky opis. Keďže niektoré prehliadače nerozpoznávajú odpoveď 307, je potrebné pridať vyššie uvedené informácie, aby používateľ pochopil a mohol požiadať o prístup k novému URI. Ak nejde o požiadavku GET alebo HEAD, potom prehliadač zakáže automatické presmerovanie, pokiaľ ho používateľ nepotvrdí, pretože podmienky požiadavky sa môžu zmeniť. |
| 400 | 1. Vyskytla sa sémantická chyba a aktuálna požiadavka nie je pre server zrozumiteľná. Pokiaľ nedôjde k úprave, klient by nemal opakovane odosielať túto požiadavku. 2, parametre požiadavky sú nesprávne. |
| 401 | Aktuálna požiadavka vyžaduje overenie používateľa. Odpoveď musí obsahovať hlavičku WWW-Authenticate pre požadovaný prostriedok, ktorá požaduje informácie o používateľovi. Klient môže opakovane odoslať požiadavku, ktorá obsahuje príslušné informácie hlavičky Authorisation. Ak aktuálna požiadavka už obsahuje poverovacie údaje Authorisation, potom odpoveď 401 znamená, že server overuje, že tieto poverovacie údaje boli odmietnuté. Ak odpoveď 401 obsahuje rovnakú autentifikačnú požiadavku ako predchádzajúca odpoveď a prehliadač sa už aspoň raz pokúsil o autentifikáciu, potom prehliadač MUSÍ používateľovi predložiť informácie o entite obsiahnuté v odpovedi, pretože tieto informácie o entite môžu obsahovať príslušné diagnostické informácie. Pozri RFC 2617. |
| 402 | Tento stavový kód je rezervovaný pre možné budúce požiadavky. |
| 403 | Server porozumel požiadavke, ale odmieta ju vykonať. Na rozdiel od odpovede 401 overenie neposkytuje žiadnu pomoc a táto požiadavka by sa nemala opätovne odosielať. Ak to nie je požiadavka HEAD a server chce byť schopný jasne hovoriť o tom, prečo sa požiadavka nemôže vykonať, potom by mal byť dôvod odmietnutia opísaný v rámci entity. Samozrejme, server môže vrátiť aj odpoveď 404, ak nechce klientovi poskytnúť žiadne informácie. |
| 404 | Požiadavka zlyhala, požadovaný prostriedok sa na serveri nenašiel. Neexistuje žiadna informácia, ktorá by používateľovi povedala, či je situácia dočasná alebo trvalá. Ak si je server vedomý tejto situácie, mal by použiť stavový kód 410, aby informoval používateľa, že starý zdroj je trvalo nedostupný z dôvodu nejakého vnútorného konfiguračného mechanizmu a že nie je k dispozícii žiadne presmerovanie. 404 sa široko používa, keď server nechce prezradiť, prečo bola požiadavka zamietnutá, alebo keď nie je k dispozícii žiadna iná vhodná odpoveď. |
| 405 | Metóda požiadavky uvedená v riadku požiadavky sa nedá použiť na vyžiadanie príslušného prostriedku. Odpoveď musí vrátiť hlavičku Allow (Povoliť), v ktorej je uvedený zoznam metód požiadavky, ktoré sú prijateľné pre aktuálny prostriedok. Vzhľadom na to, že metódy PUT a DELETE zapisujú do prostriedku na serveri, väčšina webových serverov tieto metódy požiadavky nepodporuje alebo ich štandardne nepovoľuje a v prípade takýchto požiadaviek vráti chybu 405. |
| 406 | Obsahové charakteristiky požadovaného prostriedku nespĺňajú podmienky v hlavičke požiadavky a entitu odpovede nie je možné vygenerovať. Ak nejde o požiadavku HEAD, odpoveď by mala vrátiť entitu obsahujúcu zoznam vlastností a adries entít, z ktorých si používateľ alebo prehliadač môže vybrať najvhodnejšiu entitu. Formát entity je určený typom média definovaným v hlavičke Content-Type. Prehliadače si môžu na základe formátu a vlastných možností vybrať tú najlepšiu. Špecifikácia však nedefinuje žiadne kritériá na takýto automatický výber. |
| 407 | Podobne ako odpoveď 401, s tým rozdielom, že klient sa MUSÍ overiť na proxy serveri. Proxy server MUSÍ vrátiť správu Proxy-Authenticate (Overenie proxy servera) na dopytovanie sa na identitu. Klient MÔŽE vrátiť hlavičku Proxy-Authorization na overenie. Pozri RFC 2617. |
| 408 | Časový limit požiadavky. Klient nedokončil odoslanie požiadavky v čase, na ktorý bol server pripravený čakať. Klient môže kedykoľvek opätovne odoslať požiadavku bez vykonania akýchkoľvek zmien. |
| 409 | Požiadavku nebolo možné dokončiť z dôvodu konfliktu s aktuálnym stavom požadovaného prostriedku. Tento kód sa smie použiť len vtedy, ak sa predpokladá, že používateľ je schopný konflikt vyriešiť a opätovne odoslať novú požiadavku. Odpoveď by mala obsahovať dostatok informácií, aby používateľ mohol zistiť zdroj konfliktu. Konflikty sa zvyčajne vyskytujú pri spracovaní požiadaviek PUT. Napríklad v prostredí kontroly verzií, ak sú informácie o verzii pripojené k požiadavke PUT odoslanej na úpravu konkrétneho prostriedku v konflikte s predchádzajúcou požiadavkou (tretej strany), server by mal vrátiť chybu 409 a informovať používateľa, že požiadavku nebolo možné dokončiť. V tomto prípade bude entita odpovede pravdepodobne obsahovať porovnanie rozdielov medzi oboma konfliktnými verziami, aby mohol používateľ po zlúčení znova odoslať novú verziu. |
| 410 | Požadovaný prostriedok už nie je na serveri dostupný a nemá žiadnu známu adresu na presmerovanie. Takýto stav by sa mal považovať za trvalý. Ak je to možné, klienti s možnosťou úpravy odkazov by mali so súhlasom používateľa odstrániť všetky odkazy na túto adresu. Ak server nevie alebo nemôže určiť, či je tento stav trvalý, mal by sa použiť stavový kód 404. Ak nie je uvedené inak, táto odpoveď sa dá uložiť do vyrovnávacej pamäte. 410 Účelom tejto odpovede je predovšetkým pomôcť správcovi webu pri údržbe stránky tým, že informuje používateľa, že zdroj už nie je k dispozícii a že vlastník servera si želá, aby boli odstránené aj všetky vzdialené spojenia na tento zdroj. Tento typ udalosti je bežný pri časovo obmedzených službách s pridanou hodnotou. Podobne sa odpoveď 410 používa na oznámenie klientom, že zdroj, ktorý pôvodne patril jednotlivcovi na aktuálnej lokalite servera, už nie je k dispozícii. Samozrejme, záleží len na vlastníkovi servera, či je potrebné všetky trvalo nedostupné zdroje označiť ako "410 Gone" a ako dlho je potrebné toto označenie udržiavať. |
| 411 | Server odmieta prijímať požiadavky bez definovanej hlavičky Content-Length. Po pridaní platnej hlavičky Content-Length (Dĺžka obsahu), ktorá udáva dĺžku tela správy s požiadavkou, môže klient opäť odoslať požiadavku. |
| 412 | Server nesplnil jednu alebo viacero podmienok pri overovaní, že boli uvedené v poli hlavičky požiadavky. Tento stavový kód umožňuje klientovi pri získavaní prostriedku nastaviť predbežné podmienky v meta-správe požiadavky (údaje v poli hlavičky požiadavky), čím sa zabráni tomu, aby sa metóda požiadavky použila na iné prostriedky, ako je požadovaný obsah. |
| 413 | Server odmietne spracovať aktuálnu požiadavku, pretože predkladá údaje o entite s väčšou veľkosťou, ako je server ochotný alebo schopný spracovať. V tomto prípade môže server uzavrieť spojenie, aby zabránil klientovi pokračovať v odosielaní tejto požiadavky. Ak je táto podmienka dočasná, server by mal vrátiť hlavičku odpovede Retry-After (Opakovanie po), aby informoval klienta, po akom čase môže opakovať pokus. |
| 414 | Dĺžka URI požiadavky presahuje dĺžku, ktorú dokáže server interpretovať, preto server odmietne požiadavku obslúžiť. Tento prípad sa vyskytuje zriedkavo a často sa stáva, keď sa z odoslania formulára, ktorý mal použiť metódu POST, stane metóda GET, čo má za následok dlhý reťazec dotazu. "Čierne diery" v URI presmerovania, napríklad použitie starého URI ako časti nového URI pri každom presmerovaní, čo má za následok dlhý URI po niekoľkých presmerovaniach. Klienti sa pokúšajú útočiť na servery využívaním bezpečnostných chýb, ktoré existujú v niektorých serveroch. Takéto servery používajú na čítanie alebo manipuláciu s URI požiadavky vyrovnávaciu pamäť pevnej dĺžky, a keď parametre po GET prekročia určitú hodnotu, môže dôjsť k pretečeniu vyrovnávacej pamäte, čo vedie k spusteniu ľubovoľného kódu [1]. Servery bez takýchto zraniteľností by mali vrátiť stavový kód 414. |
| 415 | Pre aktuálne požadovanú metódu a požadovaný prostriedok nie je entita odoslaná v požiadavke vo formáte podporovanom serverom, preto je požiadavka zamietnutá. |
| 416 | Ak požiadavka obsahuje hlavičku požiadavky Range (Rozsah) a všetky rozsahy údajov uvedené v Range (Rozsah) sa neprekrývajú s rozsahmi dostupnými pre aktuálny prostriedok a hlavička požiadavky If-Range (Rozsah) nie je v požiadavke definovaná, potom by mal server vrátiť stavový kód 416. Ak Range používa bajtové rozsahy, potom je to prípad, keď prvá pozícia bajtov všetkých dátových rozsahov špecifikovaných v požiadavke presahuje dĺžku aktuálneho prostriedku. Server by mal tiež zahrnúť hlavičku entity Content-Range, ktorá špecifikuje dĺžku aktuálneho prostriedku spolu so stavovým kódom 416. V tejto odpovedi je tiež zakázané používať multipart/byteranges ako Content-Type. |
| 417 | Očakávaný obsah špecifikovaný v hlavičke požiadavky Expect nemôže byť serverom splnený, alebo tento server je proxy server, ktorý má jasný dôkaz, že obsah Expect nemôže byť splnený v ďalšom uzle na aktuálnej trase. |
| 421 | Počet spojení na server z IP adresy, na ktorej sa nachádza aktuálny klient, prekračuje maximum povolené serverom. Zvyčajne sa tu IP adresa vzťahuje na adresu klienta, ako ju vidí server (napr. adresa brány používateľa alebo proxy servera). V tomto prípade môže počet spojení zahŕňať viac ako jedného koncového používateľa. |
| 422 | Počet spojení na server z IP adresy aktuálneho klienta prekračuje maximum povolené serverom. IP adresa sa tu zvyčajne vzťahuje na adresu klienta, ako je viditeľná zo servera (napr. adresa brány alebo servera proxy používateľa). V tomto prípade môže počet spojení zahŕňať viac ako jedného koncového používateľa. |
| 422 | Požiadavka bola správne naformátovaná, ale nebolo možné na ňu odpovedať, pretože obsahovala sémantické chyby. (RFC 4918 WebDAV) 423 Uzamknuté Aktuálny prostriedok je uzamknutý. (RFC 4918 WebDAV) |
| 424 | Aktuálna požiadavka zlyhala kvôli chybe, ktorá sa vyskytla v predchádzajúcej požiadavke, napríklad PROPPATCH (RFC 4918 WebDAV). |
| 425 | Definované v návrhu WebDav Advanced Collections, ale neobjavuje sa v protokole WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Klienti by mali prejsť na TLS/1.0. (RFC 2817) |
| 449 | Rozšírené spoločnosťou Microsoft, aby vyjadrovalo, že požiadavky by sa mali opakovať po vykonaní príslušnej akcie. |
| 500 | Server narazil na neočakávanú podmienku, ktorá mu zabránila dokončiť spracovanie požiadavky. Zvyčajne sa tento problém vyskytuje pri chybe v programovom kóde servera. |
| 501 | Server nepodporuje určitú funkciu, ktorá je potrebná pre aktuálnu požiadavku. Keď server nie je schopný rozpoznať požadovanú metódu a nie je schopný podporiť jej požiadavku na akýkoľvek zdroj. |
| 502 | Server, ktorý pracuje ako brána alebo proxy server, dostane pri pokuse o vykonanie požiadavky neplatnú odpoveď od servera na vyššej úrovni. |
| 503 | Server momentálne nie je schopný spracovať požiadavku z dôvodu dočasnej údržby alebo preťaženia servera. Tento stav je dočasný a po určitom čase sa obnoví. Ak možno očakávať oneskorenie, odpoveď môže obsahovať hlavičku Retry-After (Opakovanie po), ktorá toto oneskorenie označuje. Ak táto informácia Retry-After nie je uvedená, klient by s ňou mal zaobchádzať rovnako ako s odpoveďou 500. Poznámka: Existencia stavového kódu 503 neznamená, že ho server musí použiť, ak je preťažený. Niektoré servery jednoducho chcú klientovi odmietnuť pripojenie. |
| 504 | Server pracujúci ako brána alebo proxy server, ktorý sa pokúša vykonať požiadavku, nedostane včas odpoveď od servera vyššieho rádu (server identifikovaný pomocou URI, napríklad HTTP, FTP, LDAP) alebo sekundárneho servera (napríklad DNS). Poznámka: Niektoré proxy servery vracajú chybu 400 alebo 500, keď sa vyhľadávanie DNS skončí. |
| 505 | Server nepodporuje alebo odmieta podporovať verziu protokolu HTTP použitú v požiadavke. To znamená, že server nie je schopný alebo ochotný používať rovnakú verziu ako klient. Odpoveď by mala obsahovať entitu, ktorá opisuje, prečo nie je verzia podporovaná, a ktoré protokoly server podporuje. |
| 506 | Rozšírené protokolom Transparent Content Negotiation Protocol (RFC 2295) na vyjadrenie vnútornej chybnej konfigurácie na strane servera: požadovaný prostriedok Negotiation Variant je nakonfigurovaný tak, aby sa používal pri transparentnom vyjednávaní o obsahu, a preto nie je vhodným cieľom v procese vyjednávania. |
| 507 | Server nie je schopný uložiť obsah potrebný na dokončenie požiadavky. Tento stav sa považuje za dočasný.WebDAV (RFC 4918) |
| 509 | Server dosiahol svoj limit šírky pásma. Toto nie je oficiálny stavový kód, ale stále sa bežne používa. |
| 510 | Zásada požadovaná na získanie zdroja nebola splnená. (RFC 2774) |