HTTP staatuskood on 3-kohaline kood, mille server tagastab vastuseks p?ringule ja mida kasutatakse p?ringu tulemuse tuvastamiseks. See t??riist pakub standardiseeritud klassifikatsiooni ja stsenaariumi t?lgendamist, mis sobib arendajatele, operatsiooni- ja hoolduspersonalile ning v?rgutehnoloogia ?ppijatele.
K?ik selgitused p?hinevad RFC standarddokumendil, v?ltides piirkondlikke erinevusi v?ljenduses ja tagades, et kasutajad kogu maailmas m?istavad sama.
| Http olekukoodid | Staatusekood T?hendus |
|---|---|
| 100 | Klient peaks j?tkama p?ringute saatmist. Seda ajutist vastust kasutatakse selleks, et teavitada klienti sellest, et server on osa tema taotlusest 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 teatab kliendile Upgrade-pealkirja kaudu, et taotluse t?itmiseks kasutati teistsugust protokolli. P?rast vastuse viimase tühja rea saatmist l?heb server üle Upgrade-pealkirjas m??ratletud protokollidele. Seda tuleks teha ainult siis, kui uuele protokollile üleminek on kasulikum. N?iteks v?ib üleminek uuele HTTP-versioonile olla kasulikum kui vanemale versioonile v?i üleminek reaalajas sünkroonprotokollile, et edastada ressursse, mis kasutavad selliseid funktsioone ?ra. |
| 102 | WebDAVi (RFC 2518) poolt laiendatud staatuskoodid n?itavad, et t??tlemine j?tkub. |
| 200 | Taotlus oli edukas ja vastuse p?ised v?i taotluses soovitud andmekorpus tagastatakse koos vastusega. |
| 201 | Taotlus on t?idetud ja vastuseks on loodud uus ressurss, mille URI on tagastatud koos Location-pealkirjaga. Kui taotletud ressurssi ei ole v?imalik ?igeaegselt luua, tuleb tagastada j?rgmine 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?ib taotlus l?puks t?itmisele j?uda v?i mitte. Asünkroonsete operatsioonide puhul ei ole midagi mugavamat kui selle staatuskoodi saatmine. Vastuse 202 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 s?ilitama ühendust serveriga, kuni partiioperatsioon on l?petatud. Vastus, mis v?tab vastu taotluse t??tlemiseks ja tagastab staatuskoodi 202, peaks sisaldama tagastatavas üksuses m?ningat teavet, mis n?itab protsessi praegust staatust, ning samuti osutajat t??tlemise staatuse j?lgimisele v?i staatuse prognoosimisele, et kasutaja saaks hinnata, kas toiming on l?petatud v?i mitte. |
| 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 originaali alam- v?i ülemhulk. N?iteks v?ivad ressursse sisaldavad metaandmed p?hjustada, et p?ritoluserver 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 metainfot. Vastus v?ib tagastada uut v?i ajakohastatud metainfot olemuse p?ise kujul. Kui need p?ised on olemas, peaksid need vastama taotletud muutujatele. Kui kliendiks on veebilehitseja, PEAB kasutaja veebilehitseja s?ilitama lehe, mille kohta taotlus saadeti, ilma et dokumendivaadet muudetaks, kuigi uus v?i ajakohastatud metainfo PEAB vastavalt spetsifikatsioonile rakenduma 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 k?sitleb taotlust edukalt ja ei tagasta midagi. Kuid erinevalt 204 vastusest palub selle staatuskoodi tagastav vastus taotlejal dokumendi vaade tagasi seada. Seda vastust kasutatakse peamiselt vormi l?htestamiseks 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 teate 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 fail mitmeks allalaadimiseks korraga. 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, v?i mitmeosalise allalaadimise puhul, mille Content-Type on multipart/byteranges, Content-Range v?li igas mitmeosalise segmendi puhul, mis n?itab selle segmendi sisu ulatust. Kui vastus sisaldab Content-Length, peab selle v??rtus vastama tagastatava sisu vahemiku tegelikule baitide arvule. Expires, Cache-Control ja/v?i Vary, kui nende v??rtused v?ivad erineda teiste eelmiste samade muutujatega vastuste v??rtustest. See vastus ei tohiks sisaldada teisi olemuse p?iseid, kui taotlus kasutab tugevat If-Range vahem?lu valideerimist, ja ei tohiks sisaldada teisi olemuse p?iseid, kui taotlus kasutab n?rka If-Range vahem?lu valideerimist; sellega v?lditakse vastuolusid vahem?llu salvestatud olemuse sisu ja uuendatud olemuse p?ise vahel. Vastasel juhul PEAB see vastus sisaldama k?iki olemuse p?ise v?lju, mis oleks pidanud olema tagastatud vastuses 200. Kui ETag v?i Last-Modified p?ised ei vasta t?pselt, peaks kliendipoolne vahem?lu keelama vastuses 206 tagastatud sisu kombineerimise eelnevalt 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 poolt laiendatud staatuskoodid(RFC 2518) WebDAVi poolt laiendatud staatusekood t?hendab, et j?rgneva s?numi keha on XML-teade ja v?ib sisaldada mitmeid eraldi vastusekoode, s?ltuvalt eelnevate alamp?ringute arvust. |
| 300 | Taotletud ressursil on rida alternatiivseid vastuseid, millest igaühel on oma spetsiifiline aadress ja brauserist l?htuv l?bir??kimiste teave. Kasutaja v?i veebilehitseja peab ise valima 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 seda automaatset valikut teha. Kui serveril endal on juba eelistatud vastusevariant, tuleks vastuse URI m??rata Location'is; brauserid v?ivad kasutada seda Location'i v??rtust automaatse ümbersuunamise aadressina. Lisaks sellele on vastus 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 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. Vastus on vahem?llu salvestatav ainult juhul, 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 ümberjuhtimise ajal taotluse meetodit muuta, 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 p?ringule 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-taotluse v?ljundi ümbersuunamist uuele ressursile. See uus URI ei ole asendusviide algsele ressursile. Samuti ei tohi 303 vastust vahem?llu salvestada. 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-eelsed brauserid ei m?ista korralikult 303-staatust. Kui on vaja arvestada nende brauserite koostoimimist, peaks 302 staatuskood toimima, kuna enamik brausereid k?itleb 302 vastust t?pselt nii, nagu ülaltoodud spetsifikatsioon n?uab, et klient k?itleks 303 vastust. |
| 304 | Selle staatuskoodi peaks server tagastama, kui klient saadab tingimusliku GET p?ringu ja p?ring on lubatud ning dokumendi sisu ei ole muutunud (kas p?rast viimast külastust v?i vastavalt p?ringu tingimustele). 304 vastused ei tohi sisaldada s?numi keha ja seet?ttu l?ppevad alati esimese tühja reaga p?rast s?numi p?ise l?ppu. Vastus peab sisaldama j?rgmist p?ise teavet: kuup?ev, v?lja arvatud juhul, kui serveril puudub kellaaeg. Kui serveril 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 korralikult. ETag ja/v?i Content-Location, kui sama p?ring oleks pidanud tagasi andma 200 vastuse. Expires, Cache-Control ja/v?i Vary, kui nende v??rtused v?ivad erineda teiste samade muutujatega varasemate vastuste v??rtustest. Kui vastusetaotlus kasutab tugevat vahem?lu valideerimist, siis ei tohiks vastus sisaldada t?iendavaid olemuse p?iseid; vastasel juhul (nt tingimuslik GET-taotlus kasutab n?rka vahem?lu valideerimist) ei tohi vastus sisaldada t?iendavaid 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 vastuse 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 ligi m??ratud proxy kaudu. V?ljal "Location" esitatakse teave m??ratud proxy URI kohta ja vastuv?tja peab saatma korduvalt eraldi taotluse, et p??seda ressursile ligi 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 luua ainult algserver. Nende piirangute eiramine v?ib p?hjustada t?siseid tagaj?rgi turvalisusele. |
| 306 | Spetsifikaadi viimases versioonis ei kasutata enam 306 staatuskoodi. |
| 307 | Taotletud ressursid vastavad nüüd ajutiselt erinevatest URIdest tulevatele p?ringutele. Kuna see ümbersuunamine on ajutine, 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 brauserid ei tunne 307 vastust, on vaja lisada eespool nimetatud 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, semantiline viga, praegune taotlus ei ole serverile arusaadav. Kui seda ei ole muudetud, ei tohiks klient p?ringut korrata. 2, p?ringu 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 esitada taotluse uuesti koos asjakohase Authorisation-pealkirja teabega. 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 teinud v?hemalt ühe autentimiskatse, siis peaks brauser n?itama kasutajale vastuses sisalduvat olemiteavet, kuna see olemiteave 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 taotlust ei tohiks uuesti esitada. Kui tegemist ei ole HEAD-p?ringuga ja server soovib, et oleks v?imalik ?elda, 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, et klient saaks mingit teavet. |
| 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 teatada serverile, 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 taha avaldada, miks taotlus tagasi lükati 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. Kuna PUT ja DELETE meetodid kirjutavad ressurssi serveris, ei toeta v?i luba enamik veebiservereid neid vaikimisi ja tagastavad selliste p?ringute puhul veateate 405. |
| 406 | Taotletava ressursi sisuomadused 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 k?ige sobivamaid üksuse omadusi ja aadresside loetelu, mille hulgast kasutaja v?i brauser saab valida. Entiteedi vorming m??ratakse kindlaks Content-Type p?ises m??ratletud meediatüübiga. Brauser saab teha parima valiku, mis p?hineb vormingul ja tema enda v?imalustel. Spetsifikatsioon ei m??ratle siiski mingeid kriteeriume selliste automaatsete valikute tegemiseks. |
| 407 | Sarnane 401-vastusega, kuid klient peab autentima end proxy-serveri juures. Proxy-server PEAB tagastama Proxy-Authenticate'i identiteedi küsitlemiseks. Klient v?ib autentimiseks tagastada p?ise Proxy-Authorisation. Vt RFC 2617. |
| 408 | Taotluse aegumist?htaeg. Klient ei l?petanud taotlust aja jooksul, mille server oli valmis ootama. Klient v?ib taotluse igal ajal uuesti esitada 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 sageli PUT-p?ringute t??tlemisel. N?iteks versioonikontrolli keskkonnas peaks PUT, mis on esitatud konkreetse ressursi muutmiseks versiooniteabega, mis on vastuolus varasema (kolmanda osapoole) taotlusega, 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, nii et kasutaja saab uue, ühendatud versiooni uuesti esitada. |
| 410 | Taotletud ressurss ei ole serveris enam k?ttesaadav ja edastamisaadress puudub. Sellist olukorda 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 olukord on püsiv, tuleks kasutada 404 staatuskoodi. Kui ei ole s?testatud teisiti, on see vastus vahem?llu salvestatav. 410-vastuse eesm?rk on eelk?ige aidata veebimeistril veebilehte hooldada, teavitades kasutajat, et ressurss ei ole enam k?ttesaadav ja et serveri omanik soovib, et ka k?ik kaugühendused ressursiga kustutatakse. Seda tüüpi sündmus on tavaline ajaliselt piiratud v??rtusteenuste puhul. Sarnaselt kasutatakse 410 vastust, et teavitada klienti sellest, et isikule kuuluv ressurss ei ole enam praegusel serverisaidil k?ttesaadav. Loomulikult on oluline ka küsimus, kas k?ik püsivalt k?ttesaamatuks muutunud ressursid tuleb sellisena m?rkida ja kui kaua neid sellisena hoida.'410 Gone'， ja kui kaua seda tuleks s?ilitada, on t?ielikult serveri omaniku otsustada. |
| 411 | Server keeldub vastu v?tmast p?ringuid ilma Content-Length p?ise m??ratlemata. Klient v?ib taotluse uuesti saata p?rast kehtiva Content-Length p?ise lisamist, mis n?itab taotluse s?numi pikkust. |
| 412 | Server ei suutnud taotluse valideerimisel t?ita ühte v?i mitut taotluse p?ise v?ljal esitatud eeltingimust. See olekukood v?imaldab kliendil m??rata ressursi hankimisel taotluse metainformatsioonis (taotluse p?ise v?ljade andmed) eeltingimusi, takistades seega taotluse meetodi rakendamist muudele kui soovitud sisuga ressurssidele. |
| 413 | Server keeldub praeguse taotluse t??tlemisest, sest see esitab rohkem füüsilisi andmeid, kui server tahab v?i suudab t??delda. Sellisel juhul v?ib server ühenduse sulgeda, et klient ei saaks j?tkata p?ringu saatmist. Kui olukord on ajutine, peaks server tagastama p?ise Retry-After, et teatada kliendile, kui palju aega tal on aega uuesti proovida. |
| 414 | Taotluse URI on pikem, kui server suudab t?lgendada, seega keeldub server taotluse teenindamisest. See juhtub harva ja tavaliselt siis, kui vormi esitamine, mis oleks pidanud kasutama POST-meetodit, muutub GET-meetodiks, mille tulemuseks on pikk Query String. URI ümbersuunamise "mustad augud", n?iteks vana URI kasutamine uue URI osana iga ümbersuunamise puhul, mille tulemuseks on pikk URI p?rast mitut ümbersuunamist. Kliendid üritavad rünnata servereid, kasutades ?ra m?nes serveris esinevaid turvaauke. Sellised serverid kasutavad taotletud URI lugemiseks v?i manipuleerimiseks fikseeritud pikkusega puhvrit, mis v?ib p?hjustada puhvri ülevoolu, kui GET-parameeter ületab teatud v??rtuse, mis viib suvalise koodi t?itmiseni.[1]。 Sellise haavatavuseta serverid peaksid tagastama 414 staatuskoodi. |
| 415 | Hetkel taotletava meetodi ja taotletava ressursi puhul ei ole taotluses esitatud üksus serveri poolt toetatud formaadis ja 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 lange kokku 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 t?hendab see, et k?igi taotluses m??ratud andmevahemike esimene bait ü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 tüüpi Content-Type. |
| 417 | Palve p?ises Expect m??ratud oodatavat sisu ei saa server t?ita v?i server on proxy-server, millel on selged t?endid, et Expecti sisu ei saa t?ita praeguse marsruudi j?rgmises s?lmes. |
| 421 | Praeguse kliendi IP-aadressilt serveriga loodud ühenduste arv ületab serveri poolt lubatud maksimumi. Tavaliselt viitab IP-aadress siinkohal kliendi aadressile, nagu seda n?eb server (nt kasutaja v?rava v?i proxy-serveri aadress). Sellisel juhul v?ib ühenduse loendisse olla kaasatud rohkem kui üks l?ppkasutaja. |
| 422 | Praeguse kliendi IP-aadressi ja serveri vaheliste ühenduste arv ületab serveri poolt lubatud maksimumi. Tavaliselt viitab IP-aadress siinkohal kliendi aadressile, nagu seda n?eb server (nt kasutaja v?rava v?i proxy-serveri aadress). Sellisel juhul v?ib ühenduse loendisse olla kaasatud rohkem kui üks l?ppkasutaja. |
| 422 | Taotlus oli korrektselt vormistatud, kuid sellele ei saanud vastata, sest see sisaldas semantilisi vigu. (RFC 4918 WebDAV) 423 Locked Praegune ressurss on lukustatud. (RFC 4918 WebDAV) 423 Locked |
| 424 | Praegune p?ring eba?nnestus eelmise p?ringu, n?iteks PROPPATCH, 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 esitada, et taotlusi tuleks uuesti proovida p?rast asjakohase toimingu sooritamist. |
| 500 | Serveril tekkis etten?gematu tingimus, mis takistas taotluse t??tlemise l?petamist. Tavaliselt tekib see probleem siis, kui serveri programmikoodis on viga. |
| 501 | Server ei toeta praeguses taotluses n?utavat funktsiooni. Kui server ei tunne taotletavat meetodit ja ei saa toetada selle taotlust m?ne ressursi osas. |
| 502 | V?rava- v?i proxy-teenusena t??tav server saab taotluse t?itmisel ülesvoolu serverilt kehtetu vastuse. |
| 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 tahavad lihtsalt keelduda kliendile ühenduse loomisest. |
| 504 | V?rava- v?i proxy-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 ennast Transparent Content Negotiation'is 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 ole t?idetud. (RFC 2774) |