Online tööriistad
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)
Juurdepääs dokumentidele: