Online nástroje
Stavové kódy Http Význam stavového kódu
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 Upgrade oznámi klientovi, že na dokončenie požiadavky bol použitý iný protokol. Po odoslaní posledného prázdneho riadku odpovede server prejde na protokoly definované v hlavičke 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 môže byť výhodnejší ako prechod na staršiu verziu alebo prechod na synchrónny protokol v reálnom čase na doručovanie zdrojov, ktoré využívajú takéto vlastnosti.
102 Stavové kódy rozšírené o WebDAV (RFC 2518) naznačujú, že spracovanie bude pokračovať.
200 Požiadavka bola úspešná a spolu s odpoveďou sa vrátia hlavičky alebo telo údajov požadované v požiadavke.
201 Požiadavka bola splnená a v odpovedi na požiadavku bol vytvorený nový prostriedok a jeho URI bol vrátený spolu s hlavičkou Location (Umiestnenie). Ak sa požadovaný prostriedok nedá vytvoriť včas, mali by sa vrátiť tieto údaje'202 Accepted'。
202 Server prijal požiadavku, ale ešte ju nespracoval. Rovnako ako môže byť odmietnutá, požiadavka sa nakoniec môže, ale nemusí vykonať. V prípade asynchrónnych operácií nie je nič vhodnejšie ako odoslanie tohto stavového kódu. Účelom vrátenia odpovede 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 klient musel udržiavať spojenie so serverom, kým sa dávková operácia nedokončí. Odpoveď, ktorá prijíma požiadavku na spracovanie a vracia stavový kód 202, by mala vo vrátenej entite obsahovať určitú informáciu označujúcu aktuálny stav procesu, ako aj ukazovateľ na monitor stavu spracovania alebo predikciu stavu, aby používateľ mohol odhadnúť, či sa operácia dokončila alebo nie.
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ôvodných informácií. Napríklad metadáta obsahujúce zdroje môžu spôsobiť, že pôvodný server pozná metainformáciu super. Použitie tohto stavového kódu nie je povinné a je vhodné len vtedy, ak by 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 tieto hlavičky existujú, mali by zodpovedať požadovaným premenným. Ak je klientom prehliadač, prehliadač používateľa MUSÍ zachovať stránku, na ktorej bola požiadavka odoslaná, bez akýchkoľvek zmien v zobrazení dokumentu, hoci nové alebo aktualizované metainformácie sa podľa špecifiká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 spracuje požiadavku a nevráti 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 súboru na viacero sťahovaní 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 alebo v prípade sťahovania viacerých častí s typom obsahu multipart/byteranges pole Content-Range v každom segmente viacerých častí na označenie rozsahu obsahu v tomto segmente. Ak odpoveď obsahuje pole Content-Length, jeho hodnota musí zodpovedať skutočnému počtu bajtov v rozsahu vráteného obsahu. 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ď by nemala obsahovať iné hlavičky entít, ak požiadavka používa silnú validáciu If-Range cache, a nemala by obsahovať iné hlavičky entít, ak požiadavka používa slabú validáciu If-Range cache; tým sa zabráni nekonzistentnosti medzi obsahom entity uloženým v medzipamäti a aktualizovanými informáciami hlavičky entity. V opačnom prípade by táto odpoveď MALA obsahovať všetky polia hlavičky entity, ktoré mali byť vrátené v odpovedi 200. Ak sa hlavičky ETag alebo Last-Modified presne nezhodujú, vyrovnávacia pamäť na strane klienta by mala znemožniť kombinovanie obsahu vráteného v odpovedi 206 s akýmkoľvek predtým uloženým obsahom v medzipamä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ódy rozšírené pomocou WebDAV(RFC 2518) Stavový kód rozšírený pomocou WebDAV 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 odpovedí, z ktorých každá má svoju vlastnú špecifickú adresu a informácie o vyjednávaní riadené prehliadačom. Je na používateľovi alebo prehliadači, aby si vybral 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 tento automatický výber vykonať. Ak už samotný server má preferovanú možnosť návratu, URI návratu by sa mal uviesť v Location (Umiestnenie); prehliadače môžu použiť túto hodnotu Location (Umiestnenie) ako adresu pre automatické presmerovanie. Okrem toho, ak nie je uvedené inak, odpoveď je možné uložiť do vyrovnávacej pamäte.
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č 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. 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 počas presmerovania, 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 náhradným odkazom za pôvodný zdroj. Takisto nie je povolené 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 verziou HTTP/1.1 nerozumejú správne stavu 303. Ak je potrebné zvážiť interakciu s týmito prehliadačmi, mal by fungovať stavový kód 302, pretože väčšina prehliadačov spracúva odpoveď 302 presne tak, ako uvedená špecifikácia vyžaduje, aby klient spracúval odpoveď 303.
304 Tento stavový kód by mal server vrátiť, ak klient odošle podmienenú požiadavku GET a požiadavka je povolená a obsah dokumentu sa nezmenil (buď od poslednej návštevy, alebo podľa podmienok požiadavky). 304 odpovede majú zakázané 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 informácie v hlavičke: Dátum, pokiaľ server nemá hodiny. Ak server nemá hodiny, riadi sa týmito pravidlami, potom proxy server a klient môžu sami pridať pole Date do hlavičky prichádzajúcej odpovede (ako je uvedené v RFC 2068) a mechanizmus ukladania do vyrovnávacej pamäte bude fungovať správne. 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 hodnôt iných predchádzajúcich odpovedí s rovnakými premennými. Ak požiadavka na odpoveď používa silnú validáciu vyrovnávacej pamäte, potom by odpoveď nemala obsahovať ďalšie hlavičky entít; v opačnom prípade (napr. podmienená požiadavka GET používa slabú validáciu vyrovnávacej pamäte) odpoveď nesmie obsahovať ďalšie hlavičky entít; tým sa zabráni nekonzistentnosti medzi obsahom entít uloženým v vyrovnávacej pamäti a aktualizovanými informáciami v hlavičkách 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í 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 určeného proxy servera a príjemca bude musieť opakovane poslať samostatnú žiadosť o prístup k prostriedku prostredníctvom tohto proxy servera. Odpoveď 305 môže vytvoriť iba 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í môže 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é zdroje teraz dočasne odpovedajú na požiadavky z rôznych URI. Keďže toto presmerovanie je 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ť uvedené informácie, aby používateľ mohol pochopiť a 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, sémantická chyba, aktuálnej požiadavke server nerozumie. Pokiaľ nie je zmenená, klient by nemal požiadavku opakovať. 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 opätovne odoslať požiadavku s príslušnými informáciami v hlavičke Authorisation. Ak aktuálna požiadavka už obsahuje poverenia Authorisation, potom odpoveď 401 znamená, že server overuje, či boli tieto poverenia odmietnuté. Ak odpoveď 401 obsahuje rovnakú autentifikačnú požiadavku ako predchádzajúca odpoveď a prehliadač už vykonal aspoň jeden pokus o autentifikáciu, potom by mal prehliadač zobraziť používateľovi informácie o entite obsiahnuté v odpovedi, pretože tieto informácie o entite môžu obsahovať relevantné 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 požiadavka by sa nemala opätovne odoslať. Ak to nie je požiadavka HEAD a server chce byť schopný povedať, prečo sa požiadavka nemôže vykonať, potom by sa mal v entite opísať dôvod odmietnutia. Samozrejme, server môže vrátiť aj odpoveď 404, ak nechce, aby klient dostal žiadne informácie.
404 Požiadavka zlyhala, požadovaný zdroj 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 ho informoval, ž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. Keďže metódy PUT a DELETE zapisujú do prostriedku na serveri, väčšina webových serverov ich štandardne nepodporuje alebo nepovoľuje a v prípade takýchto požiadaviek vráti chybu 405.
406 Charakteristiky obsahu požadovaného prostriedku nespĺňajú podmienky v hlavičke požiadavky a entitu odpovede nie je možné vygenerovať. Pokiaľ nejde o požiadavku HEAD, odpoveď by mala vrátiť entitu, ktorá obsahuje najvhodnejšie charakteristiky entity a zoznam adries, z ktorých si používateľ alebo prehliadač môže vybrať. Formát entity je určený typom média definovaným v hlavičke Content-Type. Prehliadač môže urobiť najlepší výber na základe formátu a svojich vlastných možností. Špecifikácia však nedefinuje žiadne kritériá na takýto automatický výber.
407 Podobná odpoveď ako 401, s tým rozdielom, že klient sa musí overiť na proxy serveri. Proxy server MUSÍ vrátiť správu Proxy-Authenticate na dotazovanie identity. Klient môže vrátiť hlavičku Proxy-Authorisation na overenie totožnosti. Pozri RFC 2617.
408 Časový limit požiadavky. Klient nedokončil požiadavku 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 často vyskytujú pri spracovaní požiadaviek PUT. Napríklad v prostredí kontroly verzií by sa pri požiadavke PUT odoslanej na úpravu konkrétneho prostriedku s informáciami o verzii, ktorá je v konflikte s predchádzajúcou požiadavkou (tretej strany), mala vrátiť chyba 409 informujúca 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, takže používateľ môže znovu odoslať novú, zlúčenú verziu.
410 Požadovaný prostriedok už nie je na serveri dostupný a nie je známa žiadna adresa na jeho presmerovanie. Takáto situácia by sa mala 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 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. Účelom odpovede 410 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 sa odstránili 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 klientovi, že zdroj patriaci jednotlivcovi už nie je na aktuálnom mieste servera dostupný. Samozrejme, dôležitá je aj otázka, či všetky trvalo nedostupné zdroje musia byť takto označené a ako dlho musia byť takto uchovávané.'410 Gone'， a to, ako dlho by mali byť udržiavané, závisí výlučne od vlastníka servera.
411 Server odmietne prijať požiadavky bez definovanej hlavičky Content-Length. Klient môže opätovne odoslať požiadavku po pridaní platnej hlavičky Content-Length, ktorá udáva dĺžku tela správy s požiadavkou.
412 Server pri overovaní požiadavky nesplnil jednu alebo viacero podmienok uvedených v poli hlavičky požiadavky. Tento stavový kód umožňuje klientovi pri získavaní zdroja nastaviť predbežné podmienky v metainformáciách požiadavky (údaje v poli hlavičky požiadavky), čím sa zabráni použitiu metódy požiadavky na iné zdroje, ako je požadovaný obsah.
413 Server odmietne spracovať aktuálnu požiadavku, pretože sa v nej predkladá viac fyzických údajov, ako je server ochotný alebo schopný spracovať. V tomto prípade môže server uzavrieť spojenie, aby klientovi zabránil pokračovať v odosielaní požiadavky. Ak je situácia dočasná, server by mal vrátiť hlavičku Retry-After, aby informoval klienta, koľko času má na opakovanie.
414 URI požiadavky je dlhšie, ako dokáže server interpretovať, preto server odmietne požiadavku obslúžiť. Táto situácia je zriedkavá a zvyčajne nastá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 Query String. "Č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 požadovaným URI vyrovnávaciu pamäť pevnej dĺžky, čo môže viesť k pretečeniu vyrovnávacej pamäte, keď parameter GET prekročí určitú hodnotu, č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 a požiadavka je zamietnutá.
416 Ak požiadavka obsahuje hlavičku požiadavky Range (Rozsah) a všetky rozsahy údajov uvedené v Range (Rozsah) sa nezhodujú 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 to znamená, že prvý bajt 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 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 aktuálneho klienta prekračuje maximum povolené serverom. IP adresa sa tu zvyčajne vzťahuje na adresu klienta, ako ju vidí server (napr. adresa brány používateľa alebo adresa proxy servera). V tomto prípade môže byť do počtu spojení zapojený viac ako jeden koncový používateľ.
422 Počet spojení z IP adresy aktuálneho klienta na server presahuje maximum povolené serverom. Typicky sa tu IP adresa 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 byť do počtu spojení zapojený viac ako jeden koncový používateľ.
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) 423 Locked
424 Aktuálna požiadavka zlyhala z dôvodu chyby 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 tak, aby vyjadrovalo, že požiadavky by sa mali opakovať po vykonaní príslušnej akcie.
500 Server narazil na nepredvídanú podmienku, ktorá mu zabránila dokončiť spracovanie požiadavky. Zvyčajne sa tento problém vyskytne, keď sa v programovom kóde servera vyskytne chyba.
501 Server nepodporuje funkciu požadovanú aktuálnou požiadavkou. Keď server nerozpozná požadovanú metódu a nemôže podporiť jej požiadavku na žiadny prostriedok.
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, ktorý funguje 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 aké 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ý na použitie seba samého v Transparent Content Negotiation, a preto nie je vhodným cieľom v procese vyjednávania.
507 Server nie je schopný uložiť obsah potrebný na splnenie 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ásady požadované na získanie zdroja neboli splnené. (RFC 2774)
Prístup k záznamom: