Internetiniai įrankiai
Http būsenos kodai Būsenos kodo reikšmė
100 Klientas turėtų toliau siųsti užklausas. Šis laikinas atsakymas naudojamas klientui informuoti, kad serveris gavo dalį jo užklausos ir jos neatmetė. Klientas turėtų toliau siųsti likusią užklausos dalį arba ignoruoti šį atsakymą, jei užklausa buvo įvykdyta. Kai užklausa bus baigta, serveris turi išsiųsti galutinį atsakymą klientui.
101 Serveris suprato kliento užklausą ir per atnaujinimo antraštę informuos klientą, kad užklausai įvykdyti buvo naudojamas kitas protokolas. Išsiuntęs paskutinę tuščią atsakymo eilutę, serveris pereis prie atnaujinimo antraštėje apibrėžtų protokolų. Tai turėtų būti daroma tik tuo atveju, jei pereiti prie naujojo protokolo yra naudingiau. Pavyzdžiui, gali būti naudingiau pereiti prie naujos HTTP versijos, palyginti su senesne versija, arba pereiti prie realaus laiko, sinchroninio protokolo, kad būtų galima pateikti išteklius, kurie naudojasi tokiomis savybėmis.
102 Būsenos kodai, išplėsti WebDAV (RFC 2518), rodo, kad apdorojimas bus tęsiamas.
200 Užklausa buvo sėkminga, ir kartu su atsakymu bus grąžintos užklausoje pageidaujamos atsakymo antraštės arba duomenų visuma.
201 Užklausa buvo įvykdyta ir pagal užklausą sukurtas naujas išteklius, o jo URI grąžintas kartu su Location antraštėmis. Jei prašomo ištekliaus neįmanoma sukurti laiku, turėtų būti grąžinama'202 Accepted'。
202 Serveris priėmė užklausą, bet dar jos neapdorojo. Lygiai taip pat, kaip ji gali būti atmesta, užklausa galiausiai gali būti įvykdyta arba neįvykdyta. Atliekant asinchronines operacijas, nėra nieko patogesnio už šio būsenos kodo siuntimą. 202 atsakymo grąžinimo tikslas - leisti serveriui priimti užklausas iš kitų procesų (pavyzdžiui, paketinės operacijos, kuri vykdoma tik kartą per dieną), klientui nereikalaujant palaikyti ryšio su serveriu, kol paketinė operacija bus baigta. Atsakyme, kuriuo priimama apdorojimo užklausa ir grąžinamas 202 būsenos kodas, grąžinamoje esybėje turėtų būti tam tikra informacija, nurodanti dabartinę proceso būseną, taip pat nuoroda į apdorojimo būsenos monitorių arba būsenos prognozę, kad naudotojas galėtų įvertinti, ar operacija baigta, ar ne.
203 Serveris sėkmingai apdorojo užklausą, tačiau grąžinta esybės antraštės metainformacija nėra galutinis rinkinys, galiojantis pradiniame serveryje, o kopija iš vietinės arba trečiosios šalies. Dabartinė informacija gali būti originalo poaibis arba viršrinkinys. Pavyzdžiui, dėl metaduomenų, kuriuose yra išteklių, kilmės serveris gali žinoti metainformacijos superviršutinę informaciją. Šio būsenos kodo naudoti neprivaloma ir jis tinka tik tuo atveju, jei be jo atsakymas būtų grąžintas 200 OK.
204 Serveris sėkmingai apdorojo užklausą, tačiau jam nereikia grąžinti jokio fizinio turinio ir jis nori grąžinti atnaujintą metainformaciją. Atsakymas gali grąžinti naują arba atnaujintą metainformaciją esybių antraščių pavidalu. Jei šios antraštės egzistuoja, jos turėtų atitikti prašomus kintamuosius. Jei klientas yra naršyklė, naudotojo naršyklė TURI išsaugoti puslapį, kuriame buvo išsiųsta užklausa, nekeisdama dokumento rodinio, nors nauja arba atnaujinta metainformacija pagal specifikaciją TURI būti pritaikyta dokumentui naudotojo naršyklės aktyviajame rodinyje. Kadangi 204 atsakyme draudžiama pateikti bet kokį pranešimo turinį, jis visada baigiasi pirmąja tuščia eilute po pranešimo antraštės.
205 Serveris sėkmingai apdoroja užklausą ir nieko negrąžina. Tačiau, kitaip nei 204 atsakyme, atsakyme, kuriame grąžinamas šis būsenos kodas, prašoma prašytojo iš naujo nustatyti dokumento rodinį. Šis atsakas visų pirma naudojamas norint iš naujo nustatyti formą iš karto po naudotojo įvesties priėmimo, kad naudotojas galėtų lengvai pradėti kitą įvestį. Kaip ir 204 atsakyme, šiame atsakyme draudžiama pateikti bet kokį pranešimo tekstą ir jis baigiasi pirmąja tuščia eilute po pranešimo antraštės.
206 Serveris sėkmingai apdorojo dalį GET užklausos. HTTP atsisiuntimo įrankiai, tokie kaip "FlashGet" arba "Thunderbolt", naudoja šį atsakymo tipą, kad atliktų pertraukiamą atsisiuntimą arba išskaidytų didelį failą į kelis atsisiuntimus vienu metu. Užklausoje turi būti Range antraštė, nurodanti turinio, kurį klientas pageidauja gauti, diapazoną, ir gali būti If-Range kaip užklausos sąlyga. Atsakyme turi būti šie antraštės laukai: Content-Range, nurodantys šiame atsakyme grąžinamo turinio apimtį, arba, jei parsisiunčiama iš kelių dalių, kurių turinio tipas yra multipart/byteranges, kiekviename kelių dalių segmente turi būti Content-Range laukas, nurodantis to segmento turinio apimtį. Jei atsakyme yra Content-Length, jo vertė turi atitikti tikrąjį grąžinamo turinio intervalo baitų skaičių. Expires, Cache-Control ir (arba) Vary, jei jų vertės gali skirtis nuo kitų ankstesnių atsakymų su tais pačiais kintamaisiais verčių. Šiame atsakyme neturėtų būti kitų esybės antraščių, jei užklausoje naudojamas stiprus "If-Range" spartinančiosios talpyklos patvirtinimas, ir neturėtų būti kitų esybės antraščių, jei užklausoje naudojamas silpnas "If-Range" spartinančiosios talpyklos patvirtinimas; taip išvengiama neatitikimų tarp spartinančiosios talpyklos turinio ir atnaujintos esybės antraštės informacijos. Priešingu atveju šiame atsakyme TURI būti visi esybės antraštės laukai, kurie turėjo būti grąžinti 200 atsakyme. Jei ETag arba Last-Modified antraštės tiksliai nesutampa, kliento pusės talpykla turėtų neleisti derinti 206 atsakyme grąžinamo turinio su bet kokiu anksčiau talpykloje saugomu turiniu. Bet kuriai talpyklai, kuri nepalaiko Range ir Content-Range antraščių, draudžiama talpinti į talpyklą 206 atsakymu grąžintą turinį.
207 WebDAV išplėsti būsenos kodai(RFC 2518) WebDAV išplėstas būsenos kodas reiškia, kad tolesnis pranešimo kūnas bus XML pranešimas ir jame gali būti keletas atskirų atsakymo kodų, priklausomai nuo ankstesnių dalinių užklausų skaičiaus.
300 Prašomas išteklius turi keletą alternatyvių atsakymų, kurių kiekvienas turi savo konkretų adresą ir naršyklės valdomą derybų informaciją. Vartotojas arba naršyklė turi pasirinkti pageidaujamą nukreipimo adresą. Jei tai nėra HEAD užklausa, atsakyme turėtų būti esybė, kuri yra išteklių charakteristikų ir adresų sąrašas, iš kurio naudotojas arba naršyklė gali pasirinkti tinkamiausią nukreipimo adresą. Šios esybės formatą lemia Content-Type apibrėžties formatas. Naršyklė gali automatiškai pasirinkti tinkamiausią adresą, remdamasi atsakymo formatu ir pačios naršyklės galimybėmis. Žinoma, RFC 2616 specifikacijoje nenurodoma, kaip turėtų būti atliekamas šis automatinis pasirinkimas. Jei pats serveris jau turi pageidaujamą grąžinimo parinktį, grąžinimo URI turėtų būti nurodytas Location; naršyklės gali naudoti šią Location reikšmę kaip automatinio nukreipimo adresą. Be to, atsakymą galima talpinti į talpyklą, jei nenurodyta kitaip.
301 Prašomas išteklius buvo visam laikui perkeltas į naują vietą, o bet kokios būsimos nuorodos į jį turėtų naudoti vieną iš kelių šiame atsakyme grąžintų URI. Jei įmanoma, klientai, turintys nuorodų redagavimo galimybes, turėtų automatiškai pakeisti prašomą adresą į grąžintą iš serverio. Šis atsakymas taip pat talpinamas į talpyklą, jei nenurodyta kitaip. Naujasis nuolatinis URI turėtų būti grąžinamas atsakymo lauke Location (vieta). Jei tai nėra HEAD užklausa, atsakymo esybėje turėtų būti hipersaitas į naująjį URI ir trumpas aprašymas. Jei tai nėra GET arba HEAD užklausa, naršyklei draudžiama automatiškai nukreipti, nebent tai patvirtintų naudotojas, nes dėl to gali pasikeisti užklausos sąlygos. Pastaba: kai kurios HTTP/1.0 protokolą naudojančios naršyklės, išsiuntusios POST užklausą ir gavusios 301 atsakymą, kitą nukreipimo užklausą pateiks GET.
302 Prašomas išteklius dabar laikinai atsako į užklausą iš kito URI. Kadangi šis nukreipimas yra laikinas, klientas ir toliau turėtų siųsti būsimas užklausas pradiniu adresu. Atsakymą galima talpinti į spartinančiąją atmintinę tik tada, jei nurodyta Cache-Control arba Expires. Naujasis laikinasis URI turėtų būti grąžinamas atsakymo lauke Location. Jei tai nėra HEAD užklausa, atsakymo esybėje turėtų būti nuoroda į naująjį URI ir trumpas aprašymas. Jei tai nėra GET arba HEAD užklausa, naršyklei draudžiama automatiškai nukreipti, nebent tai patvirtintų naudotojas, nes dėl to gali pasikeisti užklausos sąlygos. Pastaba: nors RFC 1945 ir RFC 2068 specifikacijose klientui neleidžiama keisti užklausos metodo peradresavimo metu, daugelis esamų naršyklių 302 atsakymą traktuoja kaip 303 atsakymą ir naudoja GET, kad pasiektų vietos nuorodoje nurodytą URI, neatsižvelgdamos į pradinės užklausos metodą. 303 ir 307 būsenos kodai buvo pridėti siekiant paaiškinti, kokio atsakymo serveris tikisi iš kliento.
303 Atsakymą į dabartinę užklausą galima rasti kitame URI, ir klientas turėtų pasiekti tą išteklių naudodamas GET. Šis metodas visų pirma egzistuoja tam, kad scenarijaus aktyvuotos POST užklausos išvestį būtų galima nukreipti į naują išteklių. Šis naujas URI nėra pakaitinė nuoroda į pradinį išteklių. Be to, 303 atsakymo neleidžiama talpinti į spartinančiąją atmintinę. Žinoma, antroji užklausa (nukreipimas) gali būti talpinama spartinančiojoje atmintinėje. Naujasis URI turėtų būti grąžinamas atsakymo lauke Location (vieta). Jei tai nėra HEAD užklausa, atsakymo esybėje turėtų būti hipersaitas į naująjį URI ir trumpas aprašymas. Pastaba: Daugelis naršyklių, kurios buvo ankstesnės nei HTTP/1.1, netinkamai supranta 303 būseną. Jei reikia atsižvelgti į sąveiką su šiomis naršyklėmis, 302 būsenos kodas turėtų būti tinkamas, nes dauguma naršyklių 302 atsakymą tvarko lygiai taip pat, kaip pirmiau pateiktoje specifikacijoje reikalaujama, kad klientas tvarkytų 303 atsakymą.
304 Šį būsenos kodą serveris turėtų grąžinti, jei klientas siunčia sąlyginę GET užklausą ir užklausa yra leidžiama, o dokumento turinys nepasikeitė (nuo paskutinio apsilankymo arba pagal užklausos sąlygas). 304 atsakyme draudžiama pateikti pranešimo kūną, todėl jis visada baigiasi pirmąja tuščia eilute po pranešimo antraštės. Atsakyme turi būti ši antraštės informacija: Data, išskyrus atvejus, kai serveris neturi laikrodžio. Jei serveris neturi laikrodžio, vadovaujasi šiomis taisyklėmis, tada tarpinis serveris ir klientas gali patys įtraukti Data lauką į gaunamo atsakymo antraštę (kaip nurodyta RFC 2068), ir spartinančiosios atminties mechanizmas veiks tinkamai. ETag ir (arba) Content-Location, jei pagal tą pačią užklausą turėjo būti pateiktas 200 atsakymas. Expires, Cache-Control ir (arba) Vary, jei jų reikšmės gali skirtis nuo kitų ankstesnių atsakymų su tais pačiais kintamaisiais reikšmių. Jei atsakymo užklausoje naudojamas stiprus talpyklos tikrinimas, atsakyme neturėtų būti papildomų esybės antraščių; priešingu atveju (pvz., sąlyginėje GET užklausoje naudojamas silpnas talpyklos tikrinimas), atsakyme draudžiama naudoti papildomas esybės antraštes; taip išvengiama neatitikimų tarp talpyklos turinio ir atnaujintos esybės antraštės informacijos. Jei 304 atsakyme nurodoma, kad esybė šiuo metu nėra talpinama talpykloje, spartinančiosios talpyklos sistema turi ignoruoti atsakymą ir pakartoti užklausą be apribojimo. Jei gaunamas 304 atsakymas, kuriuo prašoma atnaujinti talpyklos įrašą, talpyklos sistema PRIVALO atnaujinti visą įrašą, kad jame atsispindėtų visų atsakyme atnaujintų laukų reikšmės.
305 Prašomas išteklius turi būti pasiekiamas per nurodytą tarpinį serverį. Lauke Location bus pateikta informacija apie nurodyto tarpinio serverio URI, o gavėjas turės pakartotinai siųsti atskirą užklausą, norėdamas pasiekti išteklių per šį tarpinį serverį. 305 atsakymą gali sukurti tik pradinis serveris. Pastaba: iš RFC 2068 nėra aišku, kad 305 atsakas yra skirtas nukreipti vieną užklausą ir jį gali sukurti tik pradinis serveris. Šių apribojimų nepaisymas gali turėti rimtų pasekmių saugumui.
306 Naujausioje specifikacijos versijoje 306 būsenos kodas nebenaudojamas.
307 Prašomi ištekliai dabar laikinai atsako į užklausas iš skirtingų URI. Kadangi šis nukreipimas yra laikinas, klientai ir toliau turėtų siųsti būsimas užklausas pradiniu adresu. Šį atsakymą galima talpinti į spartinančiąją atmintinę tik tada, jei nurodyta Cache-Control arba Expires. Naujasis laikinasis URI turėtų būti grąžinamas atsakymo lauke Location. Jei tai nėra HEAD užklausa, atsakymo esybėje turėtų būti nuoroda į naująjį URI ir trumpas aprašymas. Kadangi kai kurios naršyklės neatpažįsta 307 atsakymo, būtina pridėti pirmiau nurodytą informaciją, kad naudotojas galėtų suprasti ir paprašyti prieigos prie naujo URI. Jei tai nėra GET arba HEAD užklausa, tuomet naršyklė draudžia automatinį nukreipimą, nebent tai patvirtintų naudotojas, nes užklausos sąlygos gali pasikeisti.
400 1, semantinė klaida, dabartinės užklausos serveris negali suprasti. Jei ji nepakeista, klientas neturėtų kartoti užklausos. 2, užklausos parametrai neteisingi.
401 Dabartinei užklausai reikalingas naudotojo autentiškumo patvirtinimas. Atsakyme turi būti prašomo ištekliaus antraštė WWW-Authenticate, kurioje prašoma pateikti naudotojo informaciją. Klientas gali pakartotinai pateikti užklausą su atitinkama Authorisation antraštės informacija. Jei dabartinėje užklausoje jau yra Autorizavimo duomenys, 401 atsakymas reiškia, kad serveris patikrina, ar šie duomenys buvo atmesti. Jei 401 atsakyme yra ta pati autentifikavimo užklausa kaip ir ankstesniame atsakyme, o naršyklė jau atliko bent vieną autentifikavimo bandymą, tuomet naršyklė turėtų parodyti naudotojui atsakyme esančią esybės informaciją, nes šioje esybės informacijoje gali būti atitinkamos diagnostinės informacijos. Žr. RFC 2617.
402 Šis būsenos kodas rezervuotas galimiems būsimiems reikalavimams.
403 Serveris suprato užklausą, bet atsisako ją vykdyti. Skirtingai nuo 401 atsakymo, autentiškumo patvirtinimas nesuteikia jokios pagalbos, todėl užklausa neturėtų būti siunčiama iš naujo. Jei tai nėra HEAD užklausa ir serveris nori, kad būtų galima pasakyti, kodėl užklausa negali būti įvykdyta, tuomet atsisakymo priežastis turėtų būti aprašyta esybėje. Žinoma, serveris taip pat gali grąžinti 404 atsakymą, jei nenori, kad klientas gautų kokią nors informaciją.
404 Užklausa nepavyko, prašomo ištekliaus serveryje nerasta. Nėra informacijos, kuri vartotojui pasakytų, ar situacija laikina, ar nuolatinė. Jei serveris žino apie situaciją, jis turėtų naudoti būsenos kodą 410, kad praneštų, jog senasis išteklius yra visam laikui nepasiekiamas dėl tam tikro vidinės konfigūracijos mechanizmo ir kad nėra galimybės nukreipti. 404 plačiai naudojamas, kai serveris nenori atskleisti, kodėl užklausa buvo atmesta, arba kai nėra kito tinkamo atsakymo.
405 Užklausos eilutėje nurodytas užklausos metodas negali būti naudojamas atitinkamam ištekliui užklausti. Atsakyme turi būti grąžinama antraštė Allow, kurioje nurodomas užklausos metodų, priimtinų esamam ištekliui, sąrašas. Kadangi PUT ir DELETE metodai įrašo į serveryje esantį išteklių, dauguma žiniatinklio serverių šių užklausų metodų nepalaiko arba neleidžia jų naudoti pagal nutylėjimą, todėl pateikus tokias užklausas bus grąžinama 405 klaida.
406 Prašomo ištekliaus turinio charakteristikos neatitinka užklausos antraštėje nurodytų sąlygų, todėl atsakymo esybė negali būti sukurta. Išskyrus atvejus, kai tai yra HEAD užklausa, į atsakymą turėtų būti grąžinama esybė, kurioje būtų nurodytos tinkamiausios esybės charakteristikos ir adresų, iš kurių naudotojas arba naršyklė gali rinktis, sąrašas. Subjekto formatą lemia Content-Type antraštėje apibrėžtas medijos tipas. Naršyklė gali pasirinkti geriausią variantą, atsižvelgdama į formatą ir savo galimybes. Tačiau specifikacijoje neapibrėžiami jokie kriterijai, pagal kuriuos būtų galima atlikti tokį automatinį pasirinkimą.
407 Panašus į 401 atsakymą, išskyrus tai, kad klientas turi autentifikuotis tarpiniame serveryje. Tarpinis serveris PRIVALO grąžinti "Proxy-Authenticate" tapatybės užklausai. Klientas gali grąžinti Proxy-Authorisation antraštę autentiškumui nustatyti. Žr. RFC 2617.
408 Užklausos laiko limitas. Klientas neužbaigė užklausos per laiką, kurį serveris buvo pasirengęs laukti. Klientas gali bet kada iš naujo pateikti užklausą neatlikdamas jokių pakeitimų.
409 Užklausos nepavyko užbaigti dėl konflikto su dabartine prašomo ištekliaus būkle. Šį kodą leidžiama naudoti tik tuo atveju, jei manoma, kad naudotojas gali išspręsti konfliktą ir iš naujo pateikti naują užklausą. Atsakyme turėtų būti pakankamai informacijos, kad naudotojas galėtų nustatyti konflikto šaltinį. Konfliktai dažnai kyla apdorojant PUT užklausas. Pavyzdžiui, versijų tikrinimo aplinkoje PUT, pateiktas siekiant pakeisti tam tikrą išteklių su versijos informacija, kuri prieštarauja ankstesnei (trečiosios šalies) užklausai, turėtų grąžinti 409 klaidą, informuojančią naudotoją, kad užklausos nepavyko įvykdyti. Šiuo atveju atsakymo esybėje greičiausiai bus pateiktas dviejų konfliktuojančių versijų skirtumų palyginimas, kad naudotojas galėtų iš naujo pateikti naują, sujungtą versiją.
410 Prašomas išteklius nebėra prieinamas serveryje ir nėra žinomo persiuntimo adreso. Tokia situacija turėtų būti laikoma nuolatine. Jei įmanoma, klientai, turintys nuorodų redagavimo galimybes, naudotojui leidus, turėtų pašalinti visas nuorodas į šį adresą. Jei serveris nežino arba negali nustatyti, ar būklė yra nuolatinė, turėtų būti naudojamas 404 būsenos kodas. Jei nenurodyta kitaip, šį atsakymą galima talpinti į spartinančiąją atmintinę. 410 atsakymo paskirtis - visų pirma padėti svetainės administratoriui prižiūrėti svetainę, informuojant naudotoją, kad ištekliaus nebėra ir kad serverio savininkas pageidauja, jog visi nuotoliniai ryšiai su šiuo ištekliumi taip pat būtų ištrinti. Tokio tipo įvykis yra įprastas ribotos trukmės pridėtinės vertės paslaugoms. Panašiai 410 atsakymas naudojamas klientui pranešti, kad asmeniui priklausantis išteklius nebėra prieinamas dabartinėje serverio svetainėje. Žinoma, taip pat svarbu atsakyti į klausimą, ar visi nuolat neprieinami ištekliai turi būti pažymėti kaip tokie ir kiek laiko jie turi būti tokie laikomi.'410 Gone'， ir kaip ilgai jis turėtų būti saugomas, priklauso tik nuo serverio savininko.
411 Serveris atsisako priimti užklausas be apibrėžtos Content-Length antraštės. Klientas gali iš naujo pateikti užklausą, pridėjęs galiojančią Content-Length antraštę, nurodančią užklausos pranešimo kūno ilgį.
412 Serveris, tvirtindamas užklausą, neįvykdė vienos ar daugiau išankstinių sąlygų, nurodytų užklausos antraštės lauke. Šis būsenos kodas leidžia klientui nustatyti išankstines sąlygas užklausos metainformacijoje (užklausos antraštės lauko duomenys) gaunant išteklių, taip užkertant kelią užklausos metodo taikymui kitiems ištekliams nei pageidaujamas turinys.
413 Serveris atsisako apdoroti dabartinę užklausą, nes joje pateikiama daugiau fizinių duomenų, nei serveris nori ar gali apdoroti. Tokiu atveju serveris gali uždaryti ryšį, kad klientas negalėtų toliau siųsti užklausos. Jei situacija yra laikina, serveris turėtų grąžinti antraštę Retry-After, kad informuotų klientą, kiek laiko jis turi pakartoti bandymą.
414 Užklausos URI yra ilgesnis, nei serveris gali interpretuoti, todėl serveris atsisako aptarnauti užklausą. Tai pasitaiko retai ir dažniausiai, kai formos pateikimas, kuriam turėjo būti naudojamas POST metodas, tampa GET metodu, todėl gaunama ilga užklausos eilutė. Peradresavimo URI "juodosios skylės", pvz., senasis URI naudojamas kaip naujojo URI dalis kiekvienam peradresavimui, todėl po kelių peradresavimų gaunamas ilgas URI. Klientai bando atakuoti serverius pasinaudodami kai kuriuose serveriuose esančiomis saugumo spragomis. Tokie serveriai naudoja fiksuoto ilgio buferį prašomam URI skaityti arba juo manipuliuoti, todėl, kai GET parametras viršija tam tikrą reikšmę, gali atsirasti buferio perpildymas, dėl kurio gali būti vykdomas savavališkas kodas.[1]。 Tokių pažeidžiamumų neturintys serveriai turėtų grąžinti 414 būsenos kodą.
415 Šiuo metu prašomam metodui ir prašomam ištekliui užklausoje pateikta esybė nėra serverio palaikomo formato ir užklausa atmetama.
416 Jei užklausoje yra užklausos antraštė "Range" ir bet kokie duomenų intervalai, nurodyti "Range", nesutampa su dabartiniam ištekliui prieinamais intervalais, o užklausos antraštė "If-Range" užklausoje nėra apibrėžta, serveris turėtų grąžinti 416 būsenos kodą. Jei Range naudojami baitų intervalai, tai reiškia, kad visų užklausoje nurodytų duomenų intervalų pirmasis baitas viršija dabartinio ištekliaus ilgį. Kartu su 416 būsenos kodu serveris taip pat turėtų įtraukti Content-Range subjekto antraštę, kurioje nurodomas dabartinio ištekliaus ilgis. Šiame atsakyme taip pat draudžiama naudoti multipart/byteranges kaip Content-Type (turinio tipą).
417 Užklausos antraštėje Expect nurodyto laukiamo turinio serveris negali įvykdyti arba serveris yra tarpinis serveris, kuris turi aiškių įrodymų, kad Expect turinys negali būti įvykdytas kitame dabartinio maršruto mazge.
421 Iš dabartinio kliento IP adreso prisijungimų prie serverio skaičius viršija didžiausią serverio leidžiamą skaičių. Paprastai IP adresas čia reiškia kliento adresą, matomą iš serverio (pvz., naudotojo vartų arba tarpinio serverio adresą). Šiuo atveju ryšio skaičiavime gali dalyvauti daugiau nei vienas galutinis vartotojas.
422 Ryšių iš dabartinio kliento IP adreso į serverį skaičius viršija didžiausią serverio leidžiamą skaičių. Paprastai IP adresas čia reiškia kliento adresą, matomą iš serverio (pvz., naudotojo vartų arba tarpinio serverio adresą). Šiuo atveju ryšio skaičiavime gali dalyvauti daugiau nei vienas galutinis vartotojas.
422 Užklausa buvo suformatuota teisingai, tačiau į ją nebuvo galima atsakyti, nes joje buvo semantinių klaidų. (RFC 4918 WebDAV) 423 Užrakinta Dabartinis išteklius yra užrakintas. (RFC 4918 WebDAV) 423 Locked
424 Dabartinė užklausa nepavyko dėl klaidos ankstesnėje užklausoje, pavyzdžiui, PROPPATCH. (RFC 4918 WebDAV)
425 Apibrėžta "WebDav Advanced Collections" projekte, tačiau nėra nurodyta "WebDAV Sequential Collections" protokole (RFC 3658).
426 Klientai turėtų pereiti prie TLS/1.0. (RFC 2817)
449 Išplėsta "Microsoft", kad reikštų, jog užklausos turėtų būti bandomos iš naujo, kai atliekamas atitinkamas veiksmas.
500 Serveris susidūrė su nenumatyta sąlyga, dėl kurios negalėjo baigti apdoroti užklausos. Paprastai ši problema iškyla, kai serverio programos kode yra klaida.
501 Serveris nepalaiko funkcijos, kurios reikia pagal dabartinę užklausą. Kai serveris neatpažįsta prašomo metodo ir negali palaikyti jo užklausos dėl kokio nors ištekliaus.
502 Kai serveris, veikiantis kaip vartai arba tarpinis serveris, bandydamas įvykdyti užklausą gauna neteisingą atsakymą iš aukštesnio serverio.
503 Serveris šiuo metu negali apdoroti užklausos dėl laikinos serverio priežiūros arba perkrovos. Ši būklė yra laikina ir po kurio laiko bus atkurta. Jei galima tikėtis uždelsimo, atsakyme gali būti pateikta antraštė Retry-After, nurodanti uždelsimą. Jei ši Retry-After informacija nepateikiama, klientas turėtų elgtis taip pat, kaip ir su 500 atsakymu. Pastaba: 503 būsenos kodo egzistavimas nereiškia, kad serveris privalo jį naudoti, jei jis yra perkrautas. Kai kurie serveriai paprasčiausiai nori neleisti klientui užmegzti ryšio.
504 Serveris, veikiantis kaip šliuzas arba tarpinis serveris, kuris bando atlikti užklausą, laiku negauna atsakymo iš aukštesniojo serverio (serverio, identifikuojamo pagal URI, pavyzdžiui, HTTP, FTP, LDAP) arba antrinio serverio (pavyzdžiui, DNS). Pastaba: kai kurie tarpiniai serveriai grąžina 400 arba 500 klaidą, kai DNS paieška užtrunka.
505 Serveris nepalaiko arba atsisako palaikyti užklausoje naudotą HTTP versiją. Tai reiškia, kad serveris negali arba nenori naudoti tos pačios versijos kaip klientas. Atsakyme turėtų būti nurodyta, kodėl versija nepalaikoma ir kokius protokolus serveris palaiko.
506 Išplėstas pagal skaidraus turinio derybų protokolą (RFC 2295), kad reikštų serverio vidinę konfigūracijos klaidą: prašomas derybų varianto išteklius yra sukonfigūruotas taip, kad jis pats save naudotų skaidriose turinio derybose, todėl nėra tinkamas derybų proceso objektas.
507 Serveris negali saugoti prašymui įvykdyti reikalingo turinio. Ši sąlyga laikoma laikina.WebDAV(RFC 4918)
509 Serveris pasiekė savo pralaidumo ribą. Tai nėra oficialus būsenos kodas, tačiau jis vis dar plačiai naudojamas.
510 Neįvykdyta išteklių gavimui reikalinga politika. (RFC 2774)
Galimybė susipažinti su dokumentais: