| Koda stanja http | Koda stanja Pomen kode stanja |
|---|
| 100 | Odjemalec lahko nadaljuje s pošiljanjem zahtevkov. Ta začasni odgovor se uporablja za obveščanje odjemalca, da je strežnik prejel del njegove zahteve in da ta ni bila zavrnjena. Odjemalec naj nadaljuje s pošiljanjem preostalega dela zahteve ali ignorira ta odgovor, če je zahteva popolna. Strežnik mora odjemalcu poslati končni odgovor, ko je zahteva končana. |
| 101 | Strežnik je razumel odjemalčevo zahtevo in ga bo prek glave sporočila Upgrade obvestil, naj za dokončanje zahteve uporabi drug protokol. Po pošiljanju zadnje prazne vrstice tega odgovora bo strežnik preklopil na tiste protokole, ki so opredeljeni v glavi sporočila o nadgradnji. To je treba storiti le, če je preklop na nov protokol koristnejši. Na primer, preklop na novo različico protokola HTTP je ugodnejši od starejše različice ali preklop na protokol v realnem času in sinhroni protokol za dostavo virov, ki izkoriščajo take funkcije. |
| 102 | Kode stanja, razširjene s protokolom WebDAV (RFC 2518), pomenijo, da se bo obdelava nadaljevala. |
| 200 | Zahteva je bila uspešna in s tem odgovorom bo vrnjena zahtevana glavička odgovora ali podatkovno telo, ki je bilo zahtevano z zahtevo. |
| 201 | Zahteva je bila izpolnjena in ustvarjen je bil nov vir, kot je zahtevala zahteva, njegov URI pa je bil vrnjen z glavo Location. Če zahtevanega vira ni mogoče pravočasno ustvariti, je treba vrniti "202 Accepted". |
| 202 | Strežnik je zahtevo sprejel, vendar je še ni obdelal. Tako kot je lahko zavrnjena, se lahko zahteva sčasoma izvede ali pa tudi ne. V kontekstu asinhronih operacij ni nič bolj priročnega kot pošiljanje te kode stanja. Namen vračanja odgovora s kodo stanja 202 je omogočiti strežniku, da sprejme zahteve iz drugih procesov (na primer paketne operacije, ki se izvede samo enkrat na dan), ne da bi moral odjemalec ostati povezan s strežnikom, dokler se paketna operacija v celoti ne zaključi. Odgovor, ki sprejme zahtevo za obdelavo in vrne kodo stanja 202, MORA v vrnjeni entiteti vsebovati nekatere informacije, ki kažejo trenutno stanje procesa, ter kazalec na monitor stanja obdelave ali napoved stanja, tako da lahko uporabnik oceni, ali se je operacija končala. |
| 203 | Strežnik je uspešno obdelal zahtevo, vendar metainformacije v glavi vrnjene entitete niso končni nabor, ki velja v prvotnem strežniku, temveč kopija iz lokalnega strežnika ali strežnika tretje osebe. Trenutne informacije so lahko podmnožica ali nadmnožica prvotne različice. Na primer metapodatki, ki vsebujejo vire, lahko povzročijo, da prvotni strežnik pozna nadpomenko metainformacij. Uporaba te kode stanja ni obvezna in je primerna le, če bi se odgovor brez nje vrnil v obliki 200 OK. |
| 204 | Strežnik je uspešno obdelal zahtevo, vendar mu ni treba vrniti nobene fizične vsebine, želi pa vrniti posodobljene metainformacije. Odgovor lahko vrne nove ali posodobljene metainformacije v obliki glave entitete. Če take glave obstajajo, morajo ustrezati zahtevanim spremenljivkam. Če je odjemalec brskalnik, potem bi moral uporabnikov brskalnik ohraniti stran, na kateri je bila poslana zahteva, brez kakršnih koli sprememb prikaza dokumenta, čeprav se v skladu s specifikacijo nove ali posodobljene metainformacije MORAJO uporabiti za dokument v aktivnem prikazu uporabnikovega brskalnika. Ker odgovor 204 ne sme vsebovati nobenega telesa sporočila, se vedno konča s prvo prazno vrstico za glavo sporočila. |
| 205 | Strežnik je uspešno obdelal zahtevo in ni vrnil ničesar. Za razliko od odgovora 204 pa odgovor, ki vrne to kodo stanja, od prosilca zahteva, da ponastavi prikaz dokumenta. Ta odziv se uporablja predvsem za ponastavitev obrazca takoj po sprejemu uporabniškega vnosa, tako da lahko uporabnik brez težav začne nov vnos. Tako kot odziv 204 tudi ta odziv ne sme vsebovati nobenega telesa sporočila in se konča s prvo prazno vrstico za glavo sporočila. |
| 206 | Strežnik je uspešno obdelal del zahteve GET. Orodja za prenos HTTP, kot sta FlashGet ali Thunderbolt, uporabljajo to vrsto odziva za izvajanje prekinjenih prenosov ali za razdelitev velikega dokumenta na več segmentov prenosa hkrati. Zahteva mora vsebovati glavo Range, ki označuje obseg vsebine, ki jo želi odjemalec prejeti, in lahko vsebuje If-Range kot pogoj zahteve. Odgovor mora vsebovati naslednja polja glave: Content-Range za navedbo obsega vsebine, vrnjene v tem odgovoru; v primeru prenosa več segmentov z vrsto vsebine multipart/byteranges mora vsak večdelni segment vsebovati polje Content-Range, ki navaja obseg vsebine v tem segmentu. Če odgovor vsebuje polje Content-Length, se mora njegova vrednost ujemati z resničnim številom bajtov v obsegu vsebine, ki jo vrača. date ETag in/ali Content-Location, če bi morala ista zahteva vrniti odgovor 200. Expires, Cache-Control in/ali Vary, če se njihove vrednosti lahko razlikujejo od drugih odgovorov z istimi spremenljivkami. Expires, Cache-Control in/ali Vary, če se njihove vrednosti lahko razlikujejo od vrednosti drugih prejšnjih odgovorov z istimi spremenljivkami. Ta odgovor NE MORA vsebovati drugih glavi entitet, če zahteva uporablja močno preverjanje predpomnilnika If-Range, in NE MORA vsebovati drugih glavi entitet, če zahteva uporablja šibko preverjanje predpomnilnika If-Range; s tem se izognemo neskladnostim med vsebino entitete v predpomnilniku in posodobljenimi podatki glave entitete. V nasprotnem primeru ta odgovor PRAVILNO vsebuje vsa polja glave entitete, ki bi morala biti vrnjena v vseh 200 odgovorih, ki bi morali biti vrnjeni. Če se glavi ETag ali Last-Modified ne ujemata natančno, predpomnilnik na strani odjemalca PREPOVEDUJE združevanje vsebine, vrnjene v odgovoru 206, s katero koli predhodno predpomnilniško shranjeno vsebino. Predpomnilnik, ki ne podpira glave Range in glave Content-Range, ne sme predpominkovati vsebine, vrnjene z odgovorom 206. |
| 207 | Koda stanja, kot jo razširja WebDAV (RFC 2518), pomeni, da bo telo naslednjega sporočila sporočilo XML in lahko vsebuje vrsto ločenih kod odgovora, odvisno od števila predhodnih podpovprašanj. |
| 300 | Zahtevani vir ima vrsto alternativnih povratnih sporočil, vsako s svojim posebnim naslovom in informacijami o pogajanjih, ki jih določa brskalnik. Uporabnik ali brskalnik lahko sam izbere prednostni naslov za preusmeritev. Če ne gre za zahtevo HEAD, mora odgovor vključevati entiteto, ki je seznam značilnosti vira in naslovov, s katerih lahko uporabnik ali brskalnik izbere najprimernejši naslov za preusmeritev. Oblika te entitete je določena z obliko opredelitve Content-Type. Brskalnik lahko na podlagi oblike odgovora in lastnih zmožnosti brskalnika samodejno izbere najprimernejšo enoto. Seveda specifikacija RFC 2616 ne določa, kako naj se takšna samodejna izbira izvede. Če ima strežnik sam že prednostno izbiro vrnitve, je treba URI te vrnitve navesti v polju Lokacija; brskalnik lahko to vrednost Location uporabi kot naslov za samodejno preusmeritev. Poleg tega je ta odgovor mogoče shraniti v predpomnilnik, razen če ni določeno drugače. |
| 301 | Zahtevani vir je bil trajno premaknjen na novo lokacijo, zato je treba pri vseh prihodnjih sklicih nanj uporabiti enega od več URI, vrnjenih v tem odgovoru. Če je mogoče, morajo odjemalci z možnostjo urejanja povezav samodejno spremeniti zahtevani naslov v tistega, ki ga je vrnil strežnik. Če ni drugače določeno, je ta odgovor mogoče shraniti v predpomnilnik. Novi stalni URI je treba vrniti v polju Lokacija v odgovoru. Če ne gre za zahtevo HEAD, mora entiteta odgovora vsebovati hiperpovezavo do novega URI in kratek opis. Če to ni zahteva GET ali HEAD, je zato brskalniku prepovedano samodejno preusmerjanje, razen če to potrdi uporabnik, saj se lahko pogoji zahteve zaradi tega spremenijo. Opomba: Pri nekaterih brskalnikih, ki uporabljajo protokol HTTP/1.0, bo ob pošiljanju zahteve POST in prejemu odgovora 301 naslednja zahteva za preusmeritev GET. |
| 302 | Zahtevani vir se zdaj začasno odzove na zahtevo iz drugega URI. Ker je ta preusmeritev začasna, mora odjemalec prihodnje zahteve še naprej pošiljati na prvotni naslov. Ta odgovor je mogoče shraniti v predpomnilnik samo, če je naveden v Cache-Control ali Expires. Novi začasni URI je treba vrniti v polju Location v odgovoru. Če ne gre za zahtevo HEAD, mora entiteta odgovora vsebovati hiperpovezavo do novega URI in kratek opis. Če to ni zahteva GET ali HEAD, potem je brskalniku prepovedano samodejno preusmerjanje, razen če to potrdi uporabnik, saj se lahko pogoji zahteve zaradi tega spremenijo. Opomba: Čeprav specifikaciji RFC 1945 in RFC 2068 odjemalcu ne omogočata, da bi spremenil metodo zahteve ob preusmeritvi, številni obstoječi brskalniki odgovor 302 obravnavajo kot odgovor 303 in uporabijo GET za dostop do URI, določenega v lokaciji, pri čemer ne upoštevajo metode prvotne zahteve. Kodi stanja 303 in 307 sta bili dodani za pojasnitev, kakšen odziv strežnik pričakuje od odjemalca. |
| 303 | Odgovor na trenutno zahtevo je mogoče najti na drugem URI in odjemalec mora do tega vira dostopati z uporabo GET. Ta metoda obstaja predvsem zato, da se omogoči preusmeritev izpisa zahteve POST, aktivirane s skriptom, na nov vir. Ta novi URI ni alternativna referenca na prvotni vir. Prav tako je prepovedano, da bi se odgovor 303 shranil v predpomnilnik. Seveda se lahko druga zahteva (preusmeritev) shrani v predpomnilnik. Novi URI mora biti vrnjen v polju Lokacija v odgovoru. Če ne gre za zahtevo HEAD, mora entiteta odgovora vsebovati hiperpovezavo do novega URI in kratek opis. Opomba: Številni brskalniki pred različicami HTTP/1.1 ne razumejo pravilno stanja 303. Če je treba upoštevati interakcijo s temi brskalniki, mora zadostovati koda stanja 302, saj večina brskalnikov obravnava odgovor 302 na popolnoma enak način, kot zgornja specifikacija zahteva, da odjemalec obravnava odgovor 303. |
| 304 | Strežnik MORA vrniti to kodo stanja, če odjemalec pošlje pogojno zahtevo GET, ki je bila dovoljena in se vsebina dokumenta (od zadnjega obiska ali glede na pogoje zahteve) ni spremenila. 304 Odgovori ne smejo vsebovati telesa sporočila, zato se vedno končajo s prvo prazno vrstico za glavo sporočila. Odgovor MORA vsebovati naslednje glave: Datum, razen če strežnik nima ure. Če strežnik brez ure upošteva ta pravila, lahko posredniški strežnik in odjemalec sama dodata polje Datum v glavo dohodnega odgovora (kot je določeno v RFC 2068) in mehanizem predpomnjenja bo deloval pravilno. ETag in/ali Content-Location, če bi ista zahteva vrnila odgovor 200. Expires Expires, Cache-Control in/ali Vary, če je vrednost lahko drugačna od vrednosti, ki ustreza drugim predhodnim odgovorom za isto spremenljivko. Če ta zahteva za odziv uporablja močno preverjanje predpomnilnika, potem ta odgovor ne sme vsebovati drugih glavi entitet; v nasprotnem primeru (npr. pogojna zahteva GET uporablja šibko preverjanje predpomnilnika) ta odgovor ne sme vsebovati drugih glavi entitet; s tem se izognemo neskladnostim med vsebino entitete v predpomnilniku in posodobljenimi podatki glave entitete. Če odgovor 304 kaže, da entiteta trenutno ni v predpomnilniku, mora sistem predpomnilnika ignorirati odgovor in ponoviti zahtevo brez omejitve. Če je prejet odgovor 304, ki zahteva posodobitev vnosa predpomnilnika, mora sistem predpomnilnika posodobiti celoten vnos, da odraža vrednosti vseh polj, posodobljenih v odgovoru. |
| 305 | Do zahtevanega vira je treba dostopati prek določenega posrednika. polje Lokacija bo podalo informacije o URI, kjer se nahaja določeni posrednik. prejemnik bi moral za dostop do vira prek tega posrednika večkrat poslati ločeno zahtevo. Odgovor 305 lahko ustvari samo prvotni strežnik. Opomba: Iz standarda RFC 2068 ni jasno razvidno, da je odgovor 305 namenjen preusmeritvi posamezne zahteve in da ga lahko ustvari samo prvotni strežnik. Neupoštevanje teh omejitev lahko povzroči resne varnostne posledice. |
| 306 | V zadnji različici specifikacije se koda stanja 306 ne uporablja več. |
| 307 | Zahtevani vir zdaj začasno odgovori na zahtevo iz drugega URI. Ker so take preusmeritve začasne, morajo odjemalci prihodnje zahteve še naprej pošiljati na prvotni naslov. Ta odgovor je mogoče shraniti v predpomnilnik samo, če je naveden v Cache-Control ali Expires. Novi začasni URI je treba vrniti v polju Location v odgovoru. Če ne gre za zahtevo HEAD, mora entiteta odgovora vsebovati hiperpovezavo do novega URI in kratek opis. Ker nekateri brskalniki ne prepoznajo odgovora 307, je treba dodati zgornje informacije, da lahko uporabnik razume in zahteva dostop do novega URI. Če ne gre za zahtevo GET ali HEAD, potem brskalnik prepove samodejno preusmeritev, razen če jo potrdi uporabnik, saj se lahko pogoji zahteve spremenijo. |
| 400 | 1. Prišlo je do semantične napake in strežnik trenutne zahteve ne more razumeti. Odjemalec te zahteve ne sme večkrat poslati, razen če je spremenjena. 2, parametri zahteve so napačni. |
| 401 | Trenutna zahteva zahteva avtentikacijo uporabnika. Odgovor mora vsebovati glavo WWW-Authenticate za zahtevani vir, ki zahteva podatke o uporabniku. Odjemalec lahko večkrat predloži zahtevo, ki vsebuje ustrezne informacije v glavi Authorisation. Če trenutna zahteva že vsebuje poverilnice za avtorizacijo, potem odgovor 401 pomeni, da strežnik preverja, ali so bile te poverilnice zavrnjene. Če odgovor 401 vsebuje isto avtentikacijsko poizvedbo kot prejšnji odgovor in je brskalnik že vsaj enkrat poskusil avtentikacijo, potem brskalnik PRAVILNO predstavi uporabniku informacije o entiteti, ki jih vsebuje odgovor, saj lahko te informacije o entiteti vsebujejo ustrezne diagnostične informacije. Glej RFC 2617. |
| 402 | Ta koda stanja je rezervirana za morebitne prihodnje zahteve. |
| 403 | Strežnik je razumel zahtevo, vendar je noče izvršiti. Za razliko od odgovora 401 preverjanje pristnosti ne zagotavlja nobene pomoči, zato te zahteve ne smete ponovno poslati. Če to ni zahteva HEAD in želi strežnik jasno povedati, zakaj zahteve ni mogoče izvršiti, je treba razlog za zavrnitev opisati znotraj entitete. Seveda lahko strežnik vrne tudi odgovor 404, če odjemalcu ne želi posredovati nobenih informacij. |
| 404 | Zahteva ni uspela, zahtevanega vira ni bilo mogoče najti v strežniku. Ni informacij, ki bi uporabniku povedale, ali je stanje začasno ali trajno. Če se strežnik zaveda situacije, mora uporabiti kodo stanja 410, da uporabnika obvesti, da je stari vir trajno nedostopen zaradi nekega mehanizma notranje konfiguracije in da preusmeritev ni na voljo. 404 se pogosto uporablja, kadar strežnik ne želi razkriti, zakaj je bila zahteva zavrnjena, ali kadar ni na voljo drugega ustreznega odgovora. |
| 405 | Metoda zahteve, navedena v vrstici zahteve, se ne more uporabiti za zahtevanje ustreznega vira. Odgovor mora vrniti glavo Allow, v kateri je naveden seznam metod zahtevka, ki so sprejemljive za trenutni vir. Glede na to, da metodi PUT in DELETE zapisujeta v vir v strežniku, večina spletnih strežnikov teh metod zahtevka ne podpira ali jih privzeto ne dovoljuje in bo za take zahteve vrnila napako 405. |
| 406 | Vsebinske značilnosti zahtevanega vira ne izpolnjujejo pogojev v glavi zahteve, zato entitete odgovora ni mogoče ustvariti. Če ne gre za zahtevo HEAD, mora odgovor vrniti entiteto, ki vsebuje seznam lastnosti entitet in naslovov, s katerih lahko uporabnik ali brskalnik izbere najprimernejšo. Oblika entitete je določena s tipom medija, opredeljenim v glavi Content-Type. Brskalniki lahko sami izberejo najboljšo možnost glede na obliko in svoje zmožnosti. Vendar specifikacija ne opredeljuje nobenih meril za takšno samodejno izbiro. |
| 407 | Podobno kot pri odgovoru 401, le da se odjemalec MORA avtentificirati v posredniškem strežniku. Posredniški strežnik MORA vrniti sporočilo Proxy-Authenticate za zaslišanje identitete. Odjemalec LAHKO vrne glavo Proxy-Authorization za preverjanje pristnosti. Glej RFC 2617. |
| 408 | Časovna omejitev zahtevka. Odjemalec ni dokončal pošiljanja zahteve v času, ki ga je bil strežnik pripravljen čakati. Odjemalec lahko kadar koli ponovno pošlje zahtevo brez kakršnih koli sprememb. |
| 409 | Zahteve ni bilo mogoče dokončati zaradi konflikta s trenutnim stanjem zahtevanega vira. To kodo je dovoljeno uporabiti le, če se šteje, da lahko uporabnik razreši konflikt in ponovno pošlje novo zahtevo. Odgovor mora vsebovati dovolj informacij, da lahko uporabnik odkrije vir konflikta. Do konfliktov običajno pride pri obdelavi zahtevkov PUT. Če so na primer v okolju za preverjanje različic informacije o različici, priložene zahtevi PUT, poslani za spremembo določenega vira, v nasprotju s prejšnjo zahtevo (tretje osebe), mora strežnik vrniti napako 409 in uporabnika obvestiti, da zahteve ni bilo mogoče dokončati. V tem primeru bo entiteta odgovora verjetno vsebovala primerjavo razlik med obema različicama, ki si nasprotujeta, tako da lahko uporabnik po združitvi ponovno predloži novo različico. |
| 410 | Zahtevani vir ni več na voljo v strežniku in nima nobenega znanega naslova za posredovanje. Takšno stanje je treba obravnavati kot trajno. Če je mogoče, morajo odjemalci z možnostjo urejanja povezav z dovoljenjem uporabnika odstraniti vsa sklicevanja na ta naslov. Če strežnik ne ve ali ne more ugotoviti, ali je to stanje trajno, je treba uporabiti kodo stanja 404. Če ni drugače navedeno, je ta odgovor mogoče shraniti v predpomnilnik. 410 Namen odgovora je predvsem pomagati spletnemu skrbniku pri vzdrževanju spletnega mesta z obvestilom uporabniku, da vir ni več na voljo in da lastnik strežnika želi, da se odstranijo tudi vse oddaljene povezave do tega vira. Ta vrsta dogodka je pogosta pri časovno omejenih storitvah z dodano vrednostjo. Podobno se odgovor 410 uporablja za obveščanje odjemalcev, da vir, ki je prvotno pripadal posamezniku na trenutnem mestu strežnika, ni več na voljo. Seveda je povsem odvisno od lastnika strežnika, ali je treba vse trajno nedostopne vire označiti kot "410 Gone" in kako dolgo je treba to oznako vzdrževati. |
| 411 | Strežnik zavrne sprejemanje zahtevkov brez opredeljene glave Content-Length. Po dodajanju veljavne glave Content-Length, ki označuje dolžino telesa sporočila zahteve, lahko odjemalec zahtevo ponovno pošlje. |
| 412 | Strežnik ni izpolnil enega ali več predpogojev pri preverjanju, ali so bili podani v polju glave zahteve. Ta statusna koda omogoča odjemalcu, da pri pridobivanju vira določi predpogoje v meta sporočilu zahteve (podatki v polju glave zahteve) in tako prepreči, da bi se metoda zahteve uporabila za vire, ki niso vsebina, ki jo želi. |
| 413 | Strežnik zavrne obdelavo trenutne zahteve, ker so v njej predloženi podatki o entiteti večje velikosti, kot jo je strežnik pripravljen ali sposoben obdelati. V tem primeru lahko strežnik zapre povezavo, da odjemalcu prepreči nadaljnje pošiljanje te zahteve. Če je ta pogoj začasen, mora strežnik vrniti odzivno glavo Retry-After, da odjemalcu sporoči, po kolikšnem času lahko ponovi zahtevo. |
| 414 | Dolžina URI zahteve presega dolžino, ki jo strežnik lahko interpretira, zato strežnik zavrne zahtevo. To se zgodi le redko, pogosto pa se zgodi, ko oddaja obrazca, ki bi morala uporabiti metodo POST, postane metoda GET, kar povzroči dolg niz poizvedb. "črne luknje" v URI preusmeritev, na primer uporaba starega URI kot dela novega URI pri vsaki preusmeritvi, zaradi česar je URI po več preusmeritvah dolg. Odjemalci poskušajo napasti strežnike z izkoriščanjem varnostnih ranljivosti, ki obstajajo v nekaterih strežnikih. Takšni strežniki za branje ali manipuliranje z URI zahteve uporabljajo buffer fiksne dolžine, in ko parametri po GET presežejo določeno vrednost, lahko pride do prepolnitve bufferja, kar vodi do poljubnega izvajanja kode [1]. Strežniki brez takih ranljivosti morajo vrniti kodo stanja 414. |
| 415 | Za trenutno zahtevano metodo in zahtevani vir entiteta, predložena v zahtevi, ni v obliki, ki jo podpira strežnik, zato je zahteva zavrnjena. |
| 416 | Če zahteva vsebuje glavo zahteve Range in se vsa podatkovna območja, določena v Range, ne prekrivajo z območji, ki so na voljo za trenutni vir, ter v zahtevi ni opredeljena glava zahteve If-Range, mora strežnik vrniti kodo stanja 416. Če Range uporablja bajtne razpone, potem je to v primeru, če prvi bajtni položaj vseh podatkovnih razponov, določenih v zahtevi, presega dolžino trenutnega vira. Strežnik mora vključiti tudi glavo entitete Content-Range, ki skupaj s kodo stanja 416 določa dolžino trenutnega vira. V tem odzivu je prepovedano uporabljati tudi vrsto vsebine multipart/byteranges. |
| 417 | Strežnik ne more izpolniti pričakovane vsebine, določene v glavi zahteve Expect, ali pa je ta strežnik posredniški strežnik, ki ima jasne dokaze, da vsebine Expect ni mogoče izpolniti v naslednjem vozlišču na trenutni poti. |
| 421 | Število povezav s strežnikom z naslova IP, na katerem se nahaja trenutni odjemalec, presega največje število, ki ga dovoljuje strežnik. Običajno se naslov IP v tem primeru nanaša na naslov odjemalca, kot ga vidi strežnik (npr. naslov uporabnikovega prehoda ali strežnika posrednika). V tem primeru lahko število povezav vključuje več kot enega končnega uporabnika. |
| 422 | Število povezav s strežnikom z naslova IP trenutnega odjemalca presega največje število, ki ga dovoljuje strežnik. Običajno se naslov IP v tem primeru nanaša na naslov odjemalca, kot ga vidi strežnik (npr. naslov uporabnikovega prehoda ali strežnika proxy). V tem primeru lahko število povezav vključuje več kot enega končnega uporabnika. |
| 422 | Zahteva je bila pravilno oblikovana, vendar nanjo ni bilo mogoče odgovoriti, ker je vsebovala semantične napake. (RFC 4918 WebDAV) 423 Zaklenjeno Trenutni vir je zaklenjen. (RFC 4918 WebDAV) |
| 424 | Trenutna zahteva ni uspela zaradi napake, ki se je pojavila v prejšnji zahtevi, na primer PROPPATCH (RFC 4918 WebDAV). |
| 425 | Opredeljeno v osnutku naprednih zbirk WebDav, ni pa v protokolu zaporednih zbirk WebDAV (RFC 3658). |
| 426 | Odjemalci naj preidejo na TLS/1.0. (RFC 2817) |
| 449 | Razširjeno s strani Microsofta, da bi predstavljalo, da je treba zahteve ponovno preizkusiti, ko je bilo izvedeno ustrezno dejanje. |
| 500 | Strežnik je naletel na nepredviden pogoj, ki mu je preprečil dokončanje obdelave zahteve. Običajno se ta težava pojavi ob napaki v programski kodi strežnika. |
| 501 | Strežnik ne podpira določene funkcije, ki je potrebna za trenutno zahtevo. Kadar strežnik ne more prepoznati zahtevane metode in ne more podpreti njene zahteve za kateri koli vir. |
| 502 | Strežnik, ki deluje kot prehod ali posrednik, prejme neveljaven odgovor od strežnika višje stopnje, ko poskuša izvesti zahtevo. |
| 503 | Strežnik trenutno ne more obdelati zahteve zaradi začasnega vzdrževanja ali preobremenitve strežnika. To stanje je začasno in se bo po določenem času ponovno vzpostavilo. Če je mogoče pričakovati zamudo, lahko odgovor vsebuje glavo Retry-After, ki označuje zamudo. Če ta informacija Retry-After ni navedena, jo mora odjemalec obravnavati na enak način kot odgovor 500. Opomba: Obstoj kode stanja 503 ne pomeni, da jo mora strežnik uporabiti, če je preobremenjen. Nekateri strežniki želijo odjemalcu preprosto zavrniti povezavo. |
| 504 | Strežnik, ki deluje kot prehod ali posrednik in poskuša izvesti zahtevo, ne prejme pravočasnega odgovora od strežnika v začetni verigi (strežnik, ki je identificiran z URI, na primer HTTP, FTP, LDAP) ali sekundarnega strežnika (na primer DNS). Opomba: Nekateri posredniški strežniki vrnejo napako 400 ali 500, ko se iskanje DNS prekine. |
| 505 | Strežnik ne podpira ali noče podpirati različice HTTP, ki je bila uporabljena v zahtevi. To pomeni, da strežnik ne more ali noče uporabljati iste različice kot odjemalec. Odgovor mora vsebovati entiteto, ki opisuje, zakaj različica ni podprta, in katere protokole podpira strežnik. |
| 506 | Razširjeno s protokolom za pogajanja o pregledni vsebini (RFC 2295) za predstavitev notranje napačne konfiguracije na strani strežnika: zahtevani vir Varianta pogajanj je konfiguriran za uporabo samega sebe pri pogajanjih o pregledni vsebini in zato ni ustrezen cilj v postopku pogajanj. |
| 507 | Strežnik ne more shraniti vsebine, potrebne za izpolnitev zahteve. To stanje se šteje za začasno.WebDAV (RFC 4918) |
| 509 | Strežnik je dosegel omejitev pasovne širine. To ni uradna oznaka stanja, vendar se še vedno pogosto uporablja. |
| 510 | Politika, potrebna za pridobitev vira, ni bila neizpolnjena. (RFC 2774) |