| Http būsenos kodas | Būsenos kodo reikšmė |
|---|
| 100 | Klientas turėtų toliau siųsti užklausas. Šis laikinas atsakas 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 yra baigta. Kai užklausa bus baigta, serveris turi išsiųsti galutinį atsakymą klientui. |
| 101 | Serveris suprato kliento užklausą ir per atnaujinimo pranešimo antraštę praneš klientui, kad šis užklausai užbaigti naudotų kitą protokolą. Išsiuntęs paskutinę tuščią šio atsakymo eilutę, serveris pereis prie tų protokolų, kurie apibrėžti atnaujinimo pranešimo antraštėje. Tai turėtų būti daroma tik tuo atveju, jei naudingiau pereiti prie naujo protokolo. Pavyzdžiui, pereiti prie naujos HTTP versijos yra naudingiau nei prie senesnės versijos arba pereiti prie realaus laiko ir 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 šiuo atsakymu bus grąžinta užklausoje pageidaujama atsakymo antraštė arba duomenų korpusas. |
| 201 | Užklausa įvykdyta, sukurtas naujas išteklius, kaip reikalaujama pagal užklausą, ir jo URI grąžintas kartu su antraštės Location (Vieta) kodu. Jei reikiamo ištekliaus nepavyksta 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, galiausiai užklausa gali būti arba nebūti įvykdyta. Atliekant asinchronines operacijas, nėra nieko patogesnio už šio būsenos kodo siuntimą. Atsakymo su 202 būsenos kodu grąžinimo tikslas - leisti serveriui priimti užklausas iš kitų procesų (pavyzdžiui, paketinės operacijos, kuri vykdoma tik kartą per dieną), nelaikant kliento prisijungusio prie serverio, kol paketinė operacija bus visiškai baigta. Atsakyme, kuriuo priimama apdorojimo užklausa ir grąžinamas 202 būsenos kodas, TURI 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. |
| 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 pradinės versijos poaibis arba viršrinkinys. Pavyzdžiui, dėl metaduomenų, kuriuose yra išteklių, pradinis 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 tokios antraštės yra, 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 pagal specifikaciją nauja arba atnaujinta metainformacija TURI būti taikoma 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 apdorojo užklausą ir nieko negrąžino. 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 pirmiausia 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, pavyzdžiui, "FlashGet" arba "Thunderbolt", naudoja šį atsakymo tipą, kad atliktų pertraukiamą atsisiuntimą arba išskaidytų didelį dokumentą į kelis atsisiuntimo segmentus 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į; jei atsisiunčiama iš kelių segmentų su Content-Type of multipart/byteranges, kiekviename kelių dalių segmente turėtų būti Content-Range laukas, nurodantis to segmento turinio apimtį. Jei atsakyme yra Content-Length, jo vertė turi atitikti tikrąjį grąžinamo turinio diapazono baitų skaičių. data ETag ir (arba) Content-Location, jei pagal tą pačią užklausą turėjo būti gautas atsakymas 200. Expires, Cache-Control ir (arba) Vary, jei jų vertės gali skirtis nuo kitų atsakymų su tais pačiais kintamaisiais. Expires, Cache-Control ir (arba) Vary, jei jų reikšmės gali skirtis nuo kitų ankstesnių atsakymų su tais pačiais kintamaisiais reikšmių. Šiame atsakyme NEGALI būti kitų esybių antraščių, jei užklausoje naudojamas "If-Range" stiprus talpyklos patvirtinimas, ir NEGALI būti kitų esybių antraščių, jei užklausoje naudojamas "If-Range" silpnas talpyklos patvirtinimas; taip išvengiama neatitikimų tarp talpyklos turinio ir atnaujintos esybių antraščių informacijos. Priešingu atveju šiame atsakyme TURI būti visi esybės antraštės laukai, kurie turėjo būti grąžinti visuose 200 atsakymuose, kurie turėjo būti grąžinti. Jei ETag arba Last-Modified antraštės tiksliai nesutampa, kliento pusės talpykla PRIVALO uždrausti derinti 206 atsakyme grąžintą turinį 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 | Būsenos kodas, išplėstas WebDAV (RFC 2518), reiškia, kad tolesnis pranešimo kūnas bus XML pranešimas ir jame gali būti keletas atskirų atsakymo kodų, priklausomai nuo ankstesnių pakartojimų skaičiaus. |
| 300 | Prašomas išteklius turi keletą alternatyvių grįžtamųjų pranešimų, kurių kiekvienas turi savo konkretų adresą ir naršyklės valdomą derybų informaciją. Vartotojas arba naršyklė gali patys pasirinkti pageidaujamą nukreipimo adresą. Išskyrus atvejus, kai tai yra HEAD užklausa, į atsakymą turėtų būti įtraukta esybė - 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 toks automatinis pasirinkimas turėtų būti atliekamas. Jei pats serveris jau yra pasirinkęs pageidaujamą grąžinimo variantą, tuomet šio grąžinimo URI turėtų būti nurodytas Location; naršyklė gali naudoti šią Location reikšmę kaip automatinio nukreipimo adresą. Be to, šį atsakymą taip pat galima talpinti į talpyklą, nebent nurodyta 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, todėl 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 peradresavimas 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 peradresuojant užklausą, 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 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 alternatyvi nuoroda į pradinį išteklių. Be to, 303 atsakymą draudžiama talpinti į spartinančiąją atmintinę. Žinoma, antroji užklausa (nukreipimas) gali būti talpinama į talpyklą. 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 nuoroda į naująjį URI ir trumpas aprašymas. Pastaba: Daugelis naršyklių, kurių versijos ankstesnės nei HTTP/1.1, netinkamai supranta 303 būseną. Jei reikia atsižvelgti į sąveiką su šiomis naršyklėmis, turėtų pakakti 302 būsenos kodo, nes dauguma naršyklių 302 atsakymus apdoroja lygiai taip pat, kaip pirmiau pateiktoje specifikacijoje reikalaujama, kad klientas apdorotų 303 atsakymą. |
| 304 | Serveris TURI grąžinti šį būsenos kodą, jei klientas siunčia sąlyginę GET užklausą, kuri buvo leista, ir dokumento turinys (nuo paskutinio apsilankymo arba pagal užklausos sąlygas) nepasikeitė. 304 atsakymuose draudžiama pateikti pranešimo kūną, todėl jie visada baigiasi pirmąja tuščia eilute po pranešimo antraštės. Atsakyme PRIVALO būti šios antraštės: Data, išskyrus atvejus, kai serveris neturi laikrodžio. Jei laikrodžio neturintis serveris laikosi šių taisyklių, tada tarpinis serveris ir klientas gali patys įtraukti Data lauką į gaunamo atsakymo antraštę (kaip nurodyta RFC 2068), ir spartinančiosios atminties mechanizmas veiks teisingai.ETag ir (arba) Content-Location, jei ta pati užklausa būtų grąžinusi 200 atsakymą.Expires Expires, Cache-Control ir (arba) Vary, jei reikšmė gali skirtis nuo reikšmės, atitinkančios kitus ankstesnius to paties kintamojo atsakymus. Jei šioje atsakymo užklausoje naudojamas stiprus talpyklos tikrinimas, šiame atsakyme neturėtų būti kitų esybių antraščių; priešingu atveju (pvz., sąlyginėje GET užklausoje naudojamas silpnas talpyklos tikrinimas), šiame atsakyme draudžiama naudoti kitas esybių antraštes; taip išvengiama neatitikimų tarp talpyklos turinio ir atnaujintos esybių antraščių 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į. laukas Location (vieta) pateiks informaciją apie URI, kuriame yra nurodytas tarpinis serveris. gavėjas turėtų pakartotinai siųsti atskirą užklausą, norėdamas pasiekti išteklių per šį tarpinį serverį. Tik pradinis serveris gali sukurti 305 atsakymą. 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 | Dabar prašomas išteklius laikinai atsako į užklausą iš kito URI. Kadangi tokie nukreipimai yra laikini, 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, reikia pridėti pirmiau nurodytą informaciją, kad naudotojas galėtų suprasti ir paprašyti prieigos prie naujojo 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. Yra semantinė klaida ir serveris negali suprasti dabartinės užklausos. Jei ji nepakeista, klientas neturėtų pakartotinai teikti šios užklausos. 2, užklausos parametrai yra neteisingi. |
| 401 | Dabartinei užklausai reikia naudotojo autentiškumo patvirtinimo. Atsakyme turi būti prašomo ištekliaus antraštė WWW-Authenticate, kurioje prašoma pateikti naudotojo informaciją. Klientas gali pakartotinai pateikti užklausą, kurioje yra 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, ir naršyklė jau bent kartą bandė autentifikuoti, tuomet naršyklė PRIVALO pateikti 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 ši užklausa neturėtų būti siunčiama iš naujo. Jei tai nėra HEAD užklausa ir serveris nori aiškiai pasakyti, kodėl užklausa negali būti įvykdyta, tuomet atsisakymo priežastis turėtų būti aprašyta esybės viduje. Žinoma, serveris taip pat gali grąžinti 404 atsakymą, jei nenori klientui suteikti jokios informacijos. |
| 404 | Užklausa nepavyko, prašomo ištekliaus serveryje nerasta. Nėra informacijos, kuri vartotojui pasakytų, ar situacija yra laikina, ar nuolatinė. Jei serveris žino apie situaciją, jis turėtų naudoti būsenos kodą 410, kad informuotų naudotoją, jog senasis išteklius dėl tam tikro vidinio konfigūracijos mechanizmo yra visam laikui nepasiekiamas 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. Atsižvelgiant į tai, kad 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. Jei tai nėra HEAD užklausa, atsakyme turėtų būti grąžinama esybė, kurioje yra esybių charakteristikų ir adresų sąrašas, iš kurio naudotojas arba naršyklė gali pasirinkti tinkamiausią esybę. Subjekto formatą lemia Content-Type antraštėje apibrėžtas medijos tipas. Naršyklės gali pačios pasirinkti geriausią variantą, atsižvelgdamos į 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 PRIVALO autentifikuotis tarpiniame serveryje. Tarpinis serveris PRIVALO grąžinti "Proxy-Authenticate" tapatybės užklausai. Klientas GALI grąžinti Proxy-Authorization antraštę autentiškumui nustatyti. Žr. RFC 2617. |
| 408 | Užklausos laiko limitas. Klientas nebaigė siųsti užklausos per laiką, kurį serveris buvo pasirengęs laukti. Klientas bet kuriuo metu gali iš naujo išsiųsti 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 paprastai kyla apdorojant PUT užklausas. Pavyzdžiui, versijų tikrinimo aplinkoje, jei prie PUT užklausos, pateiktos siekiant pakeisti tam tikrą išteklių, pridėta informacija apie versiją prieštarauja ankstesnei (trečiosios šalies) užklausai, serveris turėtų grąžinti 409 klaidą, informuodamas naudotoją, kad užklausos nepavyko įvykdyti. Tokiu atveju atsakymo esybėje greičiausiai bus pateiktas dviejų konfliktuojančių versijų skirtumų palyginimas, kad naudotojas po sujungimo galėtų iš naujo pateikti naują versiją. |
| 410 | Prašomas išteklius nebėra prieinamas serveryje ir neturi jokio žinomo persiuntimo adreso. Tokia būklė 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 ši sąlyga 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 yra padėti žiniatinklio valdytojui prižiūrėti svetainę, informuojant naudotoją, kad išteklius nebėra prieinamas ir kad serverio savininkas pageidauja, jog visi nuotoliniai ryšiai su šiuo ištekliu taip pat būtų pašalinti. Tokio tipo įvykis yra įprastas ribotos trukmės pridėtinės vertės paslaugoms. Panašiai 410 atsakymas naudojamas klientams pranešti, kad išteklius, kuris iš pradžių priklausė asmeniui dabartinėje serverio svetainėje, nebėra prieinamas. Žinoma, tik nuo serverio savininko priklauso, ar visi nuolat neprieinami ištekliai turi būti pažymėti kaip "410 dingo" ir kiek laiko toks žymėjimas turi išlikti. |
| 411 | Serveris atsisako priimti užklausas be apibrėžtos Content-Length antraštės. Pridėjęs galiojančią Content-Length antraštę, nurodančią užklausos pranešimo kūno ilgį, klientas gali vėl pateikti užklausą. |
| 412 | Serveriui nepavyko patenkinti vienos ar daugiau išankstinių sąlygų tikrinant, ar jos buvo pateiktos užklausos antraštės lauke. Šis būsenos kodas leidžia klientui nustatyti išankstines sąlygas užklausos metažinutėje (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 pateikiami didesnio dydžio esybės duomenys, nei serveris nori ar gali apdoroti. Tokiu atveju serveris gali uždaryti ryšį, kad klientas negalėtų toliau siųsti šios užklausos. Jei ši sąlyga yra laikina, serveris turėtų grąžinti atsakymo antraštę Retry-After, kad informuotų klientą, po kiek laiko jis gali pakartoti bandymą. |
| 414 | Užklausos URI ilgis viršija ilgį, kurį serveris gali interpretuoti, todėl serveris atsisako aptarnauti užklausą. Tai pasitaiko retai, dažnai taip nutinka, 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", pavyzdžiui, senojo URI naudojimas kaip naujojo URI dalies su kiekvienu peradresavimu, 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į užklausos URI nuskaityti arba juo manipuliuoti, o kai parametrai po GET viršija tam tikrą vertę, gali įvykti buferio perpildymas, dėl kurio įvykdomas savavališkas kodo vykdymas [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, todėl užklausa atmetama. |
| 416 | Jei užklausoje yra užklausos antraštė "Range" ir bet kokie užklausoje "Range" nurodyti duomenų intervalai nesutampa su dabartiniam ištekliui prieinamais intervalais, o užklausos antraštė "If-Range" užklausoje neapibrėžta, serveris turėtų grąžinti 416 būsenos kodą. Jei Range naudojami baitų intervalai, tai taip yra tuo atveju, jei visų užklausoje nurodytų duomenų intervalų pirmoji baitų pozicija viršija dabartinio ištekliaus ilgį. Kartu su 416 būsenos kodu serveris taip pat turėtų įtraukti Content-Range esybės 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 šis serveris yra tarpinis serveris, turintis aiškių įrodymų, kad "Expect" turinys negali būti įvykdytas kitame dabartinio maršruto mazge. |
| 421 | Iš IP adreso, kuriame yra dabartinis klientas, 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 į prisijungimų skaičių gali būti įtrauktas daugiau nei vienas galutinis naudotojas. |
| 422 | Jungimų prie serverio iš dabartinio kliento IP adreso 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 į prisijungimų skaičių gali būti įtrauktas daugiau nei vienas galutinis naudotojas. |
| 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) |
| 424 | Dabartinė užklausa nepavyko dėl klaidos, kuri įvyko 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ėstas "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 tam tikros funkcijos, kuri reikalinga dabartinei užklausai. Kai serveris negali atpažinti prašomo metodo ir negali palaikyti jo prašymo dėl bet kokio 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 nutrūksta. |
| 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ę neteisingą konfigūraciją: 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 turinio, reikalingo užklausai įvykdyti. Ši sąlyga laikoma laikina.WebDAV (RFC 4918) |
| 509 | Serveris pasiekė savo pralaidumo ribą. Tai nėra oficialus būsenos kodas, tačiau vis dar plačiai naudojamas. |
| 510 | Ištekliui gauti reikalinga politika nebuvo neįvykdyta. (RFC 2774) |