Spletna orodja
Kode stanja http 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 preostanka 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 bo odjemalca prek glave Upgrade obvestil, da je bil za dokončanje zahteve uporabljen drug protokol. Po pošiljanju zadnje prazne vrstice odgovora bo strežnik preklopil na protokole, opredeljene v glavi Nadgradnja. To je treba storiti le, če je preklop na novi protokol ugodnejši. Na primer, prehod na novo različico protokola HTTP je lahko ugodnejši od starejše različice ali preklop na sinhroni protokol v realnem času za dostavo virov, ki izkoriščajo take funkcije.
102 Kode stanja, razširjene s protokolom WebDAV (RFC 2518), kažejo, da se bo obdelava nadaljevala.
200 Zahteva je bila uspešna in z odgovorom bodo vrnjene glave odgovora ali podatkovno telo, ki ga je zahtevala zahteva.
201 Zahteva je bila izpolnjena in kot odgovor na zahtevo je bil ustvarjen nov vir, njegov URI pa je bil vrnjen z glavo Location. Če zahtevanega vira ni mogoče pravočasno ustvariti, je treba vrniti naslednje'202 Accepted'。
202 Strežnik je zahtevo sprejel, vendar je še ni obdelal. Prav tako kot je lahko zavrnjena, se zahteva na koncu lahko izvede ali pa tudi ne. V primeru asinhronih operacij ni nič bolj priročnega kot pošiljanje te kode stanja. Namen vračanja odgovora 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 vzdrževati povezavo s strežnikom, dokler se paketna operacija ne zaključi. Odgovor, ki sprejme zahtevo za obdelavo in vrne kodo stanja 202, bi moral v vrnjeni entiteti vsebovati nekaj informacij, 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 ali ne.
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 izvirnika. Zaradi metapodatkov, ki vsebujejo vire, lahko na primer izvorni 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 te glave obstajajo, morajo ustrezati zahtevanim spremenljivkam. Če je odjemalec brskalnik, bi moral uporabnikov brskalnik ohraniti stran, na kateri je bila poslana zahteva, brez kakršnih koli sprememb v pogledu dokumenta, čeprav bi se morale nove ali posodobljene metainformacije v skladu s specifikacijo uporabiti za dokument v aktivnem pogledu 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 uspešno obravnava zahtevo in ne vrne ničesar. Vendar za razliko od odgovora 204 odgovor, ki vrne to kodo stanja, od prosilca zahteva, da ponastavi pogled 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 velike datoteke na več prenosov 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, ki označuje obseg vsebine, vrnjene v tem odgovoru, ali v primeru večdelnih prenosov z vrsto vsebine multipart/byteranges polje Content-Range v vsakem večdelnem segmentu, ki označuje obseg vsebine v tem segmentu. Če odgovor vsebuje polje Content-Length, se mora njegova vrednost ujemati z dejanskim številom bajtov v obsegu vrnjene vsebine. Expires, Cache-Control in/ali Vary, če se njihove vrednosti lahko razlikujejo od vrednosti drugih predhodnih odgovorov z istimi spremenljivkami. Ta odgovor ne sme vsebovati drugih glavi entitet, če zahteva uporablja močno preverjanje predpomnilnika If-Range, in ne sme 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 mora ta odgovor vsebovati vsa polja glave entitete, ki bi morala biti vrnjena v odgovoru 200. Če se glavi ETag ali Last-Modified ne ujemata natančno, mora predpomnilnik na strani odjemalca onemogočiti 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 predpomniti vsebine, vrnjene z odgovorom 206.
207 Kode stanja, ki jih razširja WebDAV(RFC 2518) Koda stanja, kot jo je razširil WebDAV, pomeni, da bo telo naslednjega sporočila v obliki sporočila XML in lahko vsebuje vrsto ločenih kod odgovora, odvisno od števila predhodnih podpovprašanj.
300 Zahtevani vir ima vrsto alternativnih odgovorov, vsak s svojim posebnim naslovom in informacijami o pogajanjih, ki jih določa brskalnik. Uporabnik ali brskalnik mora izbrati 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 ta samodejna izbira izvede. Če ima strežnik sam že prednostno možnost vrnitve, je treba URI vrnitve navesti v Location; brskalniki lahko to vrednost Location uporabijo kot naslov za samodejno preusmeritev. Poleg tega je 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 tudi 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 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. Odziv je mogoče shraniti v predpomnilnik samo, če je naveden v polju 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 med preusmeritvijo spremenil metodo zahteve, š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, odjemalec pa 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 nadomestni sklic na prvotni vir. Prav tako odgovora 303 ni dovoljeno shraniti v predpomnilnik. Seveda pa 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 HTTP/1.1 ne razumejo pravilno stanja 303. Če je treba upoštevati interakcijo s temi brskalniki, bi morala delovati koda stanja 302, saj večina brskalnikov obravnava odgovor 302 natanko tako, kot zgornja specifikacija zahteva, da odjemalec obravnava odgovor 303.
304 To kodo stanja mora strežnik vrniti, če odjemalec pošlje pogojno zahtevo GET in je zahteva dovoljena, vsebina dokumenta pa se ni spremenila (od zadnjega obiska ali v skladu s pogoji zahteve). 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 informacije v glavi: Datum, razen če strežnik nima ure. Če strežnik nima ure, sledi tem pravilom, potem 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 morala ista zahteva vrniti odgovor 200. Expires, Cache-Control in/ali Vary, če se njihove vrednosti lahko razlikujejo od vrednosti drugih predhodnih odgovorov z istimi spremenljivkami. Če zahteva za odziv uporablja močno preverjanje predpomnilnika, potem odgovor ne sme vsebovati dodatnih glavi entitet; v nasprotnem primeru (npr. pogojna zahteva GET uporablja šibko preverjanje predpomnilnika) odgovor ne sme vsebovati dodatnih glavi entitet; s tem se izognemo neskladnostim med vsebino entitete v predpomnilniku in posodobljenimi podatki v glavi 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 določenega posrednika, prejemnik pa bo 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 ga lahko ustvari samo izvorni strežnik. Neupoštevanje teh omejitev ima lahko resne varnostne posledice.
306 V zadnji različici specifikacije se koda stanja 306 ne uporablja več.
307 Zahtevani viri se zdaj začasno odzivajo na zahteve iz različnih URI. Ker je ta preusmeritev začasna, 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, semantična napaka, strežnik ne more razumeti trenutne zahteve. Odjemalec zahteve ne sme ponoviti, če je ne spremeni. 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 ponovno pošlje zahtevo z ustreznimi informacijami 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 opravil vsaj en poskus avtentikacije, potem mora brskalnik uporabniku prikazati 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 zahteve ne smete ponovno poslati. Če to ni zahteva HEAD in želi strežnik povedati, zakaj zahteve ni mogoče izvršiti, je treba razlog za zavrnitev opisati v entiteti. Seveda lahko strežnik vrne tudi odgovor 404, če ne želi, da odjemalec dobi kakršne koli informacije.
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, s katero ga 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. Ker metodi PUT in DELETE zapisujeta v vir v strežniku, ju večina spletnih strežnikov privzeto ne podpira ali ne dovoljuje in za take zahteve vrne 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 najprimernejše značilnosti entitete in seznam naslovov, med katerimi lahko uporabnik ali brskalnik izbere. Oblika entitete je določena s tipom medija, opredeljenim v glavi Content-Type. Brskalnik lahko na podlagi oblike in svojih zmožnosti izbere najboljšo možnost. Vendar specifikacija ne opredeljuje nobenih meril za takšno samodejno izbiro.
407 Podobno kot pri odgovoru 401, le da se mora odjemalec avtentificirati pri posredniškem strežniku. Posredniški strežnik MORA vrniti sporočilo Proxy-Authenticate za poizvedovanje o identiteti. Odjemalec lahko vrne glavo Proxy-Authorisation za preverjanje pristnosti. Glej RFC 2617.
408 Časovna omejitev zahtevka. Odjemalec ni dokončal 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 uporabnik meni, da lahko razreši konflikt in ponovno pošlje novo zahtevo. Odgovor mora vsebovati dovolj informacij, da lahko uporabnik odkrije vir konflikta. Konflikti se pogosto pojavijo pri obdelavi zahtevkov PUT. Na primer, v okolju za preverjanje različic mora zahteva PUT, poslana za spremembo določenega vira z informacijami o različici, ki je v nasprotju s prejšnjo zahtevo (tretje osebe), vrniti napako 409, ki uporabnika obvesti, 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 bo uporabnik lahko ponovno predložil novo, združeno različico.
410 Zahtevani vir ni več na voljo v strežniku in ni 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 stanje trajno, je treba uporabiti kodo stanja 404. Če ni drugače določeno, je ta odgovor mogoče shraniti v predpomnilnik. Namen odgovora 410 je predvsem pomagati spletnemu skrbniku pri vzdrževanju spletnega mesta z obveščanjem uporabnika, da vir ni več na voljo in da lastnik strežnika želi, da se izbrišejo tudi vse oddaljene povezave z virom. Ta vrsta dogodka je pogosta pri časovno omejenih storitvah z dodano vrednostjo. Podobno se odgovor 410 uporablja za obveščanje odjemalca, da vir, ki pripada posamezniku, ni več na voljo na trenutnem mestu strežnika. Seveda je pomembno tudi vprašanje, ali je treba vse trajno nedostopne vire označiti kot take in kako dolgo jih je treba tako hraniti.'410 Gone'， in kako dolgo ga je treba vzdrževati, je v celoti odvisno od lastnika strežnika.
411 Strežnik zavrne sprejemanje zahtevkov brez opredeljene glave Content-Length. Odjemalec lahko zahtevo ponovno pošlje, ko doda veljavno glavo Content-Length, ki označuje dolžino telesa sporočila zahteve.
412 Strežnik pri potrjevanju zahteve ni izpolnil enega ali več predpogojev, navedenih v polju glave zahteve. Ta statusna koda omogoča odjemalcu, da pri pridobivanju vira določi predpogoje v metainformacijah zahteve (podatki v polju glave zahteve) in tako prepreči uporabo metode zahteve za vire, ki niso želena vsebina.
413 Strežnik zavrne obdelavo trenutne zahteve, ker je v njej predloženih več fizičnih podatkov, kot jih je strežnik pripravljen ali sposoben obdelati. V tem primeru lahko strežnik zapre povezavo, da odjemalcu prepreči nadaljnje pošiljanje zahteve. Če je situacija začasna, mora strežnik vrniti glavo Retry-After, da odjemalcu sporoči, koliko časa ima na voljo za ponovno zahtevo.
414 URI zahteve je daljši, kot ga strežnik lahko interpretira, zato strežnik zavrne zahtevo. To se zgodi redko, običajno pa se zgodi, ko se pri oddaji obrazca, ki bi moral uporabiti metodo POST, uporabi metoda GET, kar povzroči dolg niz poizvedb. črne luknje v URI za preusmeritve, na primer uporaba starega URI kot dela novega URI za vsako preusmeritev, 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 manipulacijo z zahtevanim URI uporabljajo medpomnilnik s fiksno dolžino, kar lahko privede do prepolnitve medpomnilnika, ko parameter GET preseže določeno vrednost, kar lahko povzroči poljubno izvajanje 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 ujemajo z območji, ki so na voljo za trenutni vir, ter če v zahtevi ni opredeljena glava zahteve If-Range, mora strežnik vrniti kodo stanja 416. Če Range uporablja bajtne razpone, to pomeni, da prvi bajt vseh podatkovnih razponov, določenih v zahtevi, presega dolžino trenutnega vira. Strežnik mora poleg kode stanja 416 vključiti tudi glavo entitete Content-Range, ki določa dolžino trenutnega vira. V tem odgovoru 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 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 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 posrednika). V tem primeru je v štetje povezav lahko vključen več kot en končni uporabnik.
422 Število povezav z naslova IP trenutnega odjemalca do strežnika 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 je v štetje povezav lahko vključen več kot en končni uporabnik.
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) 423 Zaklenjeno
424 Trenutna zahteva ni uspela zaradi napake 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 morajo preiti na TLS/1.0. (RFC 2817)
449 Razširjeno s strani Microsofta, da bi predstavljalo, da je treba zahtevke po izvedbi ustreznega dejanja ponovno preizkusiti.
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 funkcije, ki jo zahteva trenutna zahteva. Kadar strežnik ne prepozna 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 ga identificira URI, kot so HTTP, FTP, LDAP) ali sekundarnega strežnika (kot je 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 transparentna pogajanja o vsebini (RFC 2295) za predstavitev notranje napačne konfiguracije na strani strežnika: zahtevani vir Varianta pogajanj je konfiguriran za uporabo samega sebe v transparentnih pogajanjih o 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 izpolnjena. (RFC 2774)
Dostop do dokumentacije: