| Http staatuskood | Staatuskood Tähendus |
|---|
| 100 | Klient peaks jätkama päringute saatmist. Seda ajutist vastust kasutatakse selleks, et teavitada klienti sellest, et osa tema taotlusest on server vastu võtnud ja seda ei ole tagasi lükatud. Klient peaks jätkama taotluse ülejäänud osa saatmist või ignoreerima seda vastust, kui taotlus on täielik. Server peab saatma kliendile lõpliku vastuse, kui taotlus on lõpetatud. |
| 101 | Server on kliendi taotlusest aru saanud ja teavitab klienti Upgrade-teate päise kaudu, et ta kasutaks taotluse lõpetamiseks teist protokolli. Pärast selle vastuse viimase tühja rea saatmist läheb server üle Upgrade-teate päises määratletud protokollidele. Seda tuleks teha ainult siis, kui uuele protokollile üleminek on kasulikum. Näiteks on üleminek uuele HTTP-versioonile kasulikum kui vanemale versioonile või üleminek reaalajas ja sünkroonsele protokollile, et edastada ressursse, mis kasutavad selliseid funktsioone ära. |
| 102 | WebDAVi (RFC 2518) poolt laiendatud staatuskoodid näitavad, et töötlemine jätkub. |
| 200 | Taotlus on olnud edukas ja selle vastusega tagastatakse taotlusega soovitud vastuse päis või andmekogu. |
| 201 | Taotlus on täidetud ja uus ressurss on loodud vastavalt taotlusele ning selle URI on tagastatud koos Location-pealkirjaga. Kui nõutud ressurssi ei ole võimalik õigeaegselt luua, tuleb tagastada vastus "202 Accepted". |
| 202 | Server on taotluse vastu võtnud, kuid ei ole seda veel töödelnud. Nii nagu see võidakse tagasi lükata, võidakse ka taotlus lõpuks täita või mitte täita. Asünkroonsete operatsioonide kontekstis ei ole midagi mugavamat kui selle staatuskoodi saatmine. 202 staatuskoodiga vastuse tagastamise eesmärk on võimaldada serveril võtta vastu teiste protsesside taotlusi (näiteks partiipõhine operatsioon, mida täidetakse ainult üks kord päevas), ilma et klient peaks olema serveriga ühenduses seni, kuni partiioperatsioon on täielikult lõpetatud. Vastus, mis võtab vastu taotluse töötlemiseks ja tagastab staatuskoodi 202, PEAB sisaldama tagastatavas üksuses teavet, mis näitab protsessi praegust seisundit, samuti osutajat töötlemise staatuse monitooringule või staatuse prognoosile, et kasutaja saaks hinnata, kas operatsioon on lõpetatud. |
| 203 | Server on taotlust edukalt töödelnud, kuid tagastatud olemuse päise metainfo ei ole algses serveris kehtiv lõplik kogum, vaid kohaliku või kolmanda osapoole koopia. Praegune teave võib olla algse versiooni alam- või ülemhulk. Näiteks võivad ressursse sisaldavad metaandmed põhjustada, et algne server teab metainformatsiooni super. Selle staatuskoodi kasutamine ei ole kohustuslik ja on asjakohane ainult siis, kui vastus oleks ilma selleta tagastanud 200 OK. |
| 204 | Server töötles päringut edukalt, kuid ei pea tagastama füüsilist sisu ja soovib tagastada ajakohastatud metainformatsiooni. Vastus võib tagastada uut või ajakohastatud metainfot üksuse päise kujul. Kui sellised päised on olemas, peaksid need vastama taotletud muutujatele. Kui kliendiks on veebilehitseja, siis PEAB kasutaja veebilehitseja säilitama lehe, mille kohta taotlus saadeti, ilma dokumendi vaate muutmiseta, kuigi spetsifikatsiooni kohaselt PEAB uus või ajakohastatud metainfo olema rakendatud kasutaja veebilehitseja aktiivses vaates olevale dokumendile. Kuna 204 vastus ei tohi sisaldada sõnumi keha, lõpeb see alati esimese tühja reaga pärast sõnumi päise. |
| 205 | Server töötles päringut edukalt ja ei tagastanud midagi. Erinevalt vastusest 204 palub see vastus, mis tagastab selle staatuskoodi, taotlejal siiski dokumendi vaade tagasi seada. Seda vastust kasutatakse peamiselt selleks, et nullida vorm kohe pärast kasutaja sisestuse vastuvõtmist, et kasutaja saaks hõlpsasti alustada uut sisestust. Nagu 204 vastus, ei tohi ka see vastus sisaldada sõnumi keha ja lõpeb esimese tühja reaga pärast sõnumi päise. |
| 206 | Server on edukalt töödelnud osa GET-päringust. HTTP allalaadimistööriistad nagu FlashGet või Thunderbolt kasutavad seda tüüpi vastust, et teostada katkendlikke allalaadimisi või jagada suur dokument korraga mitmeks allalaadimissegmendiks. Taotlus peab sisaldama Range-pealkirja, et näidata, millist sisu vahemikku klient soovib saada, ning võib sisaldada If-Range'i kui taotluse tingimust. Vastus peab sisaldama järgmisi päise välju: Content-Range, mis näitab vastuses tagastatava sisu ulatust; mitme segmendi allalaadimise korral, mille Content-Type on multipart/byteranges, peaks iga mitmeosaline segment sisaldama Content-Range-välja, mis näitab selle segmendi sisu ulatust. Kui vastus sisaldab Content-Length, peab selle väärtus vastama tagastatava sisu vahemiku tegelikule baitide arvule. kuupäev ETag ja/või Content-Location, kui sama taotlus oleks pidanud tagastama vastuse 200. Expires, Cache-Control ja/või Vary, kui nende väärtused võivad erineda teiste samade muutujatega vastustest. Expires, Cache-Control ja/või Vary, kui nende väärtused võivad erineda teiste eelmiste vastuste väärtustest samade muutujate puhul. See vastus EI TOHI sisaldada teisi olemuse päiseid, kui taotlus kasutab If-Range tugevat vahemälu valideerimist, ja EI TOHI sisaldada teisi olemuse päiseid, kui taotlus kasutab If-Range nõrka vahemälu valideerimist; sellega välditakse vastuolusid vahemällu salvestatud olemuse sisu ja uuendatud olemuse päise teabe vahel. Vastasel juhul PEAB see vastus sisaldama kõiki olemuse päise välju, mis oleks pidanud olema tagastatud kõigis 200 vastustes, mis oleks pidanud olema tagastatud. Kui ETag või Last-Modified päised ei vasta täpselt, PEAB kliendipoolne vahemälu keelama vastuses 206 tagastatud sisu kombineerimise mis tahes varem vahemällu salvestatud sisuga. Mis tahes vahemälu, mis ei toeta Range- ja Content-Range-pealkirju, ei tohi vahemällu salvestada vastusega 206 tagastatud sisu. |
| 207 | WebDAVi (RFC 2518) poolt laiendatud olekukood tähendab, et järgneva teate keha on XML-teade ja võib sisaldada mitmeid eraldi vastusekoode, sõltuvalt eelnevate alampäringute arvust. |
| 300 | Taotletud ressursil on rida alternatiivseid vastussõnumeid, millest igaühel on oma spetsiifiline aadress ja brauserist lähtuv läbirääkimiste teave. Kasutaja või veebilehitseja saab ise valida eelistatud aadressi ümbersuunamiseks. Kui tegemist ei ole HEAD-päringuga, peaks vastus sisaldama üksust, mis on ressursi omaduste ja aadresside loetelu, mille hulgast kasutaja või brauser saab valida kõige sobivama ümbersuunamisaadressi. Selle üksuse vorming on määratud Content-Type määratluse vorminguga. Brauser võib automaatselt teha sobivaima valiku, mis põhineb vastuse vormingul ja brauseri enda võimalustel. Loomulikult ei ole RFC 2616 spetsifikatsioonis täpsustatud, kuidas selline automaatne valik tuleks teha. Kui serveril endal on juba eelistatud vastusevariant, siis tuleks selle vastuse URI määrata Location'is; brauser võib kasutada seda Location'i väärtust automaatse ümbersuunamise aadressina. Lisaks sellele on see vastus ka vahemällu salvestatav, kui ei ole määratud teisiti. |
| 301 | Taotletud ressurss on püsivalt uude asukohta viidud ja kõik tulevased viited sellele peaksid kasutama ühte mitmest selles vastuses tagastatud URI-st. Kui võimalik, peaksid lingi redigeerimise võimekusega kliendid automaatselt muutma taotletud aadressi serverilt tagastatud aadressiks. See vastus on samuti vahemällu salvestatav, kui ei ole sätestatud teisiti. Uus püsiv URI tuleks tagastada vastuse lahtris Location. Kui tegemist ei ole HEAD päringuga, peaks vastusüksus sisaldama hüperlinki uuele URI-le ja lühikirjeldust. Kui tegemist ei ole GET- või HEAD-päringuga, ei tohi brauser seega automaatselt ümber suunata, kui kasutaja ei ole seda kinnitanud, sest selle tulemusena võivad päringu tingimused muutuda. Märkus: Mõnede HTTP/1.0 protokolli kasutavate brauserite puhul, kui nad saadavad POST päringu ja saavad 301 vastuse, on järgmine ümbersuunamispäring GET. |
| 302 | Taotletud ressurss vastab nüüd ajutiselt taotlusele teisest URI-st. Kuna see ümbersuunamine on ajutine, peaks klient jätkama edasiste päringute saatmist algsele aadressile. See vastus on vahemällu salvestatav ainult siis, kui see on määratud Cache-Control või Expires. Uus ajutine URI tuleks tagastada vastuse väljal Location. Kui tegemist ei ole HEAD päringuga, peaks vastusüksus sisaldama hüperlinki uuele URI-le ja lühikirjeldust. Kui tegemist ei ole GET- või HEAD-päringuga, siis ei tohi brauser automaatselt ümber suunata, kui kasutaja ei ole seda kinnitanud, sest selle tulemusena võivad päringu tingimused muutuda. Märkus: Kuigi RFC 1945 ja RFC 2068 spetsifikatsioonid ei luba kliendil muuta ümbersuunamise korral taotluse meetodit, käsitlevad paljud olemasolevad brauserid 302 vastust 303 vastusena ja kasutavad GET-i, et pääseda ligi asukohas määratud URI-le, ignoreerides algse taotluse meetodit. Staatusekoodid 303 ja 307 on lisatud, et selgitada, millist vastust server kliendilt ootab. |
| 303 | Vastus praegusele taotlusele on leitav teisest URI-st ja klient peaks sellele ressursile juurde pääsema, kasutades GET-i. See meetod on olemas peamiselt selleks, et võimaldada skripti aktiveeritud POST-päringu väljundit uuele ressursile ümber suunata. See uus URI ei ole alternatiivne viide algsele ressursile. Samuti on 303 vastuse vahemällu salvestamine keelatud. Loomulikult võib teise päringu (ümbersuunamine) vahemällu salvestada. Uus URI tuleks tagastada vastuse Location väljal. Kui tegemist ei ole HEAD-päringuga, peaks vastusüksus sisaldama hüperlinki uuele URI-le ja lühikirjeldust. Märkus: Paljud HTTP/1.1 versioonidele eelnevad brauserid ei mõista korralikult 303-staatust. Kui on vaja arvestada suhtlemist nende brauseritega, peaks 302 staatuskood piisama, sest enamik brausereid käitleb 302 vastust täpselt samamoodi, nagu ülaltoodud spetsifikatsioon nõuab, et klient käitleks 303 vastust. |
| 304 | Server PEAB tagastama selle staatuskoodi, kui klient saadab tingimusliku GET päringu, mis on lubatud ja dokumendi sisu (alates viimasest külastusest või vastavalt päringu tingimustele) ei ole muutunud. 304 vastused ei tohi sisaldada teate keha ja seetõttu lõppevad alati esimese tühja reaga pärast teate päise. Vastus PEAB sisaldama järgmisi päiseid: kuupäev, välja arvatud juhul, kui serveril ei ole kella. Kui server, millel ei ole kella, järgib neid reegleid, siis võivad proxy server ja klient ise lisada Date-välja sissetuleva vastuse päisesse (nagu on sätestatud RFC 2068-s) ja vahemälumehhanism töötab õigesti.ETag ja/või Content-Location, kui sama päring oleks andnud vastuse 200.Expires. Expires, Cache-Control ja/või Vary, kui väärtus võib erineda sama muutuja teiste eelmiste vastuste väärtusest. Kui see vastusetaotlus kasutab tugevat vahemälu valideerimist, siis ei tohiks see vastus sisaldada teisi olemuse päiseid; vastasel juhul (nt tingimuslik GET-taotlus kasutab nõrka vahemälu valideerimist), ei tohi see vastus sisaldada teisi olemuse päiseid; sellega välditakse vastuolusid vahemälu sisu ja uuendatud olemuse päise teabe vahel. Kui vastus 304 näitab, et üksus ei ole hetkel vahemällu salvestatud, peab vahemälusüsteem vastust ignoreerima ja kordama taotlust ilma piiranguta. Kui saadakse vastus 304, milles nõutakse vahemälu kirje uuendamist, PEAB vahemälusüsteem uuendama kogu kirjet, et see kajastaks kõigi vastuses uuendatud väljade väärtusi. |
| 305 | Taotletud ressursile tuleb pääseda juurde määratud proxy kaudu. väli Location annab teavet URI kohta, kus määratud proxy asub. vastuvõtja peab saatma eraldi taotluse korduvalt, et pääseda ressursile juurde selle proxy kaudu. Ainult algne server saab luua 305 vastuse. Märkus: RFC 2068-st ei selgu, et 305 vastus on mõeldud ühe taotluse ümbersuunamiseks ja seda saab koostada ainult algne server. Nende piirangute eiramine võib põhjustada tõsiseid tagajärgi turvalisusele. |
| 306 | Spetsifikaadi viimases versioonis ei kasutata enam 306 staatuskoodi. |
| 307 | Taotletud ressurss vastab nüüd ajutiselt päringule teisest URI-st. Kuna sellised ümbersuunamised on ajutised, peaksid kliendid ka edaspidi saatma päringuid algsele aadressile. See vastus on vahemällu salvestatav ainult siis, kui see on määratud Cache-Control või Expires. Uus ajutine URI tuleks tagastada vastuse väljal Location. Kui tegemist ei ole HEAD päringuga, peaks vastusüksus sisaldama hüperlinki uuele URI-le ja lühikirjeldust. Kuna mõned veebilehitsejad ei tunne 307 vastust, tuleb lisada ülaltoodud teave, et kasutaja saaks aru ja saaks taotleda juurdepääsu uuele URI-le. Kui tegemist ei ole GET- või HEAD-päringuga, siis keelab brauser automaatse ümbersuunamise, kui kasutaja seda ei kinnita, sest päringu tingimused võivad muutuda. |
| 400 | 1. On toimunud semantiline viga ja server ei saa praegusest taotlusest aru. Kui seda ei ole muudetud, ei tohiks klient seda taotlust korduvalt esitada. 2. Taotluse parameetrid on valed. |
| 401 | Praegune taotlus nõuab kasutaja autentimist. Vastus peab sisaldama WWW-Autenticate päise taotletud ressursi jaoks, et küsida kasutaja andmeid. Klient võib korduvalt esitada taotluse, mis sisaldab asjakohast autoriseerimise päise teavet. Kui praegune taotlus sisaldab juba autoriseerimisandmeid, siis tähendab vastus 401, et server kontrollib, et need andmed on tagasi lükatud. Kui 401-vastus sisaldab sama autentimisküsimustust kui eelmine vastus ja brauser on juba vähemalt korra autentimist üritanud, siis PEAB brauser esitama kasutajale vastuses sisalduvat olemusteavet, kuna see olemusteave võib sisaldada asjakohast diagnostilist teavet. Vt RFC 2617. |
| 402 | See staatuskood on reserveeritud võimalike tulevaste nõuete jaoks. |
| 403 | Server on päringust aru saanud, kuid keeldub seda täitmast. Erinevalt vastusest 401 ei anna autentimine mingit abi ja seda taotlust ei tohiks uuesti esitada. Kui tegemist ei ole HEAD päringuga ja server soovib selgelt rääkida, miks päringut ei saa täita, siis tuleks keeldumise põhjus kirjeldada üksuses. Loomulikult võib server tagastada ka 404-vastuse, kui ta ei soovi kliendile mingit teavet anda. |
| 404 | Taotlus ebaõnnestus, taotletud ressurssi ei leitud serverist. Kasutajale ei ole võimalik öelda, kas tegemist on ajutise või püsiva olukorraga. Kui server on olukorrast teadlik, peaks ta kasutama 410 staatuskoodi, et teavitada kasutajat sellest, et vana ressurss on mõne sisemise konfiguratsioonimehhanismi tõttu püsivalt kättesaamatu ja et ümbersuunamine ei ole võimalik. 404 kasutatakse laialdaselt, kui server ei soovi avaldada, miks taotlus lükati tagasi või kui muud sobivat vastust ei ole saadaval. |
| 405 | Päringurivis määratud päringumeetodit ei saa kasutada vastava ressursi taotlemiseks. Vastus peab tagastama Allow-pealkirja, mis näitab nimekirja taotluse meetoditest, mis on vastuvõetavad antud ressursi jaoks. Arvestades, et PUT- ja DELETE-meetodid kirjutavad ressurssi serveris, ei toeta enamik veebiservereid neid päringumeetodeid või ei luba neid vaikimisi ja tagastavad selliste päringute puhul vea 405. |
| 406 | Taotletava ressursi sisu omadused ei vasta taotluse päises esitatud tingimustele ja vastusüksust ei saa genereerida. Kui tegemist ei ole HEAD päringuga, peaks vastus tagastama üksuse, mis sisaldab üksuse omaduste ja aadresside loetelu, millest kasutaja või brauser saab valida kõige sobivama üksuse. Entiteedi formaat määratakse kindlaks Content-Type päises määratletud meediatüübiga. Veebilehitsejad võivad teha oma parima valiku, mis põhineb vormingul ja nende endi võimekusel. Spetsifikatsioon ei määratle siiski mingeid kriteeriume selliste automaatsete valikute tegemiseks. |
| 407 | Sarnane 401-vastusega, kuid klient PEAB autentima end proxy-serveris. Proxy-server PEAB tagastama Proxy-Authenticate'i identiteedi küsitlemiseks. Klient VÕIB tagastada autentimiseks päise Proxy-Authorization. Vt RFC 2617. |
| 408 | Taotluse aegumistähtaeg. Klient ei lõpetanud taotluse saatmist aja jooksul, mille server oli valmis ootama. Klient võib taotluse igal ajal uuesti saata ilma muudatusi tegemata. |
| 409 | Taotlust ei õnnestunud lõpule viia, kuna see oli vastuolus taotletava ressursi praeguse olekuga. Seda koodi tohib kasutada ainult siis, kui kasutaja on võimeline konflikti lahendama ja uue taotluse uuesti esitama. Vastus peaks sisaldama piisavalt teavet, et kasutaja saaks teada konflikti põhjuse. Konfliktid tekivad tavaliselt PUT-päringute töötlemisel. Näiteks kui versioonikontrolli keskkonnas on konkreetse ressursi muutmiseks esitatud PUT-taotlusele lisatud versiooniteave vastuolus varasema (kolmanda osapoole) taotlusega, peaks server tagastama 409 veateate, mis teatab kasutajale, et taotlust ei ole võimalik täita. Sellisel juhul sisaldab vastusüksus tõenäoliselt kahe vastuolulise versiooni erinevuste võrdlust, et kasutaja saaks pärast ühendamist uue versiooni uuesti esitada. |
| 410 | Taotletud ressurss ei ole serveris enam kättesaadav ja tal ei ole teadaolevat edastamisaadressi. Sellist seisundit tuleks pidada püsivaks. Võimaluse korral peaksid lingi redigeerimise võimekusega kliendid kasutaja loal eemaldama kõik viited sellele aadressile. Kui server ei tea või ei saa kindlaks teha, kas see tingimus on püsiv, tuleks kasutada 404 staatuskoodi. Kui ei ole märgitud teisiti, on see vastus vahemällu salvestatav. 410 Vastuse eesmärk on eelkõige aidata veebimeistril veebilehe hooldamisel, teavitades kasutajat, et ressurss ei ole enam kättesaadav ja et serveri omanik soovib, et ka kõik kaugühendused sellele ressursile eemaldataks. Seda tüüpi sündmus on tavaline ajaliselt piiratud väärtusteenuste puhul. Sarnaselt kasutatakse 410 vastust, et teavitada kliente sellest, et ressurss, mis algselt kuulus konkreetsele isikule praegusel serverisaidil, ei ole enam saadaval. Loomulikult on täielikult serveri omaniku otsustada, kas kõik püsivalt kättesaamatuks muutunud ressursid tuleb märkida "410 Gone" ja kui kaua seda märgistust tuleb säilitada. |
| 411 | Server keeldub taotlusi vastu võtmast ilma Content-Length päise määratlemata. Pärast kehtiva Content-Length-pealkirja lisamist, mis näitab päringu sõnumi pikkust, võib klient päringu uuesti esitada. |
| 412 | Server ei täitnud ühte või mitut eeltingimust, kui ta kontrollis, et need on esitatud taotluse päise väljal. See olekukood võimaldab kliendil ressursi hankimisel määrata eeltingimusi taotluse metasõnumis (taotluse päisvälja andmed), takistades seega taotluse meetodi rakendamist muude kui soovitud sisuga ressursside suhtes. |
| 413 | Server keeldub praeguse päringu töötlemisest, sest see esitab suurema suurusega olemuse andmeid, kui server tahab või suudab töödelda. Sellisel juhul võib server ühenduse sulgeda, et klient ei saaks seda päringut edasi saata. Kui see tingimus on ajutine, peaks server tagastama vastuse päise "Retry-After", et teavitada klienti sellest, kui palju aega hiljem ta saab uuesti proovida. |
| 414 | Taotluse URI pikkus ületab serveri poolt tõlgendatava pikkuse, mistõttu server keeldub taotluse teenindamisest. See on haruldane ja esineb sageli siis, kui vormi esitamine, mis oleks pidanud kasutama POST-meetodit, muutub GET-meetodiks, mille tulemuseks on pikk päringustring. URI ümbersuunamise "mustad augud", näiteks vana URI kasutamine uue URI osana iga ümbersuunamise korral, mille tulemuseks on pikk URI pärast mitut ümbersuunamist. Kliendid üritavad rünnata servereid, kasutades ära mõnes serveris esinevaid turvaauke. Sellised serverid kasutavad fikseeritud pikkusega puhvrit, et lugeda või manipuleerida taotluse URI-d. Kui GET-i järgsed parameetrid ületavad teatud väärtuse, võib tekkida puhvri ülevool, mis viib suvalise koodi täitmiseni [1]. Sellise haavatavuse puudumise korral peaksid serverid tagastama 414 staatuskoodi. |
| 415 | Hetkel taotletava meetodi ja taotletava ressursi puhul ei ole taotluses esitatud üksus serveris toetatud formaadis, mistõttu taotlus lükatakse tagasi. |
| 416 | Kui päring sisaldab päringu päise "Range" (vahemik) ja kõik andmevahemikud, mis on määratletud vahemikus, ei kattu praeguse ressursi jaoks kättesaadavate vahemikega ning kui päringu päis "If-Range" ei ole päringus määratletud, siis peaks server tagastama 416 staatuskoodi. Kui Range kasutab baitide vahemikke, siis on see nii, kui kõigi taotluses määratud andmevahemike esimene baitide positsioon ületab praeguse ressursi pikkuse. Server peaks lisama ka Content-Range-üksuse päise, mis määrab praeguse ressursi pikkuse koos 416 staatuskoodiga. Selle vastuse puhul on samuti keelatud kasutada multipart/byteranges'i kui Content-Type'i. |
| 417 | Palve päises Expect määratud oodatavat sisu ei saa server täita või see server on proxy-server, millel on selged tõendid, et Expecti sisu ei saa täita praeguse marsruudi järgmises sõlmes. |
| 421 | IP-aadressilt, kus praegune klient asub, on serveriga loodud rohkem ühendusi, kui server lubab. Tavaliselt viitab IP-aadress siinkohal kliendi aadressile, nagu seda näeb serverist (nt kasutaja värava või proxy-serveri aadress). Sellisel juhul võib ühenduse arv hõlmata rohkem kui ühte lõppkasutajat. |
| 422 | Praeguse kliendi IP-aadressilt serveriga loodud ühenduste arv ületab serveri poolt lubatud maksimumi. Tavaliselt viitab IP-aadress siinkohal kliendi aadressile, nagu seda näeb serverist (nt kasutaja värava või proxy-serveri aadress). Sellisel juhul võib ühenduse arv hõlmata rohkem kui ühte lõppkasutajat. |
| 422 | Taotlus oli õigesti vormistatud, kuid sellele ei saanud vastata, sest see sisaldas semantilisi vigu. (RFC 4918 WebDAV) 423 Locked Praegune ressurss on lukustatud. (RFC 4918 WebDAV) |
| 424 | Praegune päring ebaõnnestus eelmises päringus, näiteks PROPPATCH, ilmnenud vea tõttu. (RFC 4918 WebDAV) |
| 425 | Määratletud WebDav Advanced Collections eelnõus, kuid ei esine WebDAV Sequential Collections Protocol'is (RFC 3658). |
| 426 | Kliendid peaksid üle minema TLS/1.0-le.(RFC 2817) |
| 449 | Laiendatud Microsofti poolt, et näidata, et taotlusi tuleks uuesti proovida pärast asjakohase toimingu sooritamist. |
| 500 | Server puutus kokku ootamatu olukorraga, mis takistas taotluse töötlemise lõpetamist. Tavaliselt tekib see probleem siis, kui serveri programmikoodis on viga. |
| 501 | Server ei toeta teatud funktsiooni, mis on praeguse taotluse jaoks vajalik. Kui server ei suuda soovitud meetodit ära tunda ja ei suuda toetada selle taotlust mingi ressursi osas. |
| 502 | Värava- või proxy-teenusena töötav server saab ülesvoolu serverilt kehtetu vastuse, kui ta üritab päringut täita. |
| 503 | Server ei saa hetkel taotlust töödelda ajutise serveri hoolduse või ülekoormuse tõttu. See seisund on ajutine ja taastub mõne aja pärast. Kui on oodata viivitust, võib vastus sisaldada viivituse märkimiseks päise "Retry-After". Kui seda Retry-After-teavet ei ole antud, siis peaks klient käitlema seda samamoodi nagu vastust 500. Märkus: olekukoodi 503 olemasolu ei tähenda, et server peab seda kasutama, kui see on ülekoormatud. Mõned serverid soovivad lihtsalt keelduda kliendile ühenduse loomisest. |
| 504 | Värava- või proxy-teenusena töötav server, mis üritab täita päringut, ei saa õigeaegset vastust eelnevast serverist (server, mida identifitseeritakse URI abil, näiteks HTTP, FTP, LDAP) või sekundaarsest serverist (näiteks DNS). Märkus: mõned proxy-serverid annavad tagasi vea 400 või 500, kui DNS-i otsing aegub. |
| 505 | Server ei toeta või keeldub toetamast taotluses kasutatud HTTP-versiooni. See tähendab, et server ei suuda või ei taha kasutada sama versiooni kui klient. Vastus peaks sisaldama üksust, mis kirjeldab, miks versiooni ei toetata ja milliseid protokolle server toetab. |
| 506 | Laiendatud Transparent Content Negotiation Protocol (RFC 2295) poolt, et esindada serveri sisemist väärkonfiguratsiooni: taotletud Negotiation Variant ressurss on konfigureeritud kasutama iseennast läbipaistva sisu läbirääkimistel ja ei ole seetõttu sobiv fookus läbirääkimisprotsessis. |
| 507 | Server ei suuda salvestada taotluse täitmiseks vajalikku sisu. Seda tingimust peetakse ajutiseks.WebDAV (RFC 4918) |
| 509 | Server jõudis oma ribalaiuse piirini. See ei ole ametlik seisundikood, kuid seda kasutatakse siiski laialdaselt. |
| 510 | Ressursi saamiseks vajalik poliitika ei olnud täitmata. (RFC 2774) |