| Http būsenos kodas |
Būsenos kodas reikšmė |
| 100 |
Klientas turėtų tęsti užklausos siuntimą. Šis laikinas atsakas skirtas pranešti klientui, kad jo dalinė užklausa jau buvo priimta serverio ir dar nebuvo atmesta. Klientas turėtų tęsti siųsti likusią užklausos dalį, arba, jei užklausa jau baigta, ignoruoti šį atsakymą. Serveris privalo siųsti galutinį atsakymą klientui po užklausos užbaigimo. |
| 101 |
Serveris jau suprato kliento užklausą ir praneš apie tai per Upgrade antraštę, kad klientas gali naudoti kitą protokolą šiai užklausai atlikti. Atsiųs atšąlą po šio atsakymo, serveris pereis prie tų protokolų, kurie apibrėžti Upgrade antraštėje. Panašias priemones turėtų imtis tik tada, kai perėjimas prie naujo protokolo yra naudingesnis. Pavyzdžiui, perėjimas į naują HTTP versiją, palyginti su ankstesne, yra naudingesnis, arba perėjimas prie realaus laiko ir sinchroninio protokolo, kad būtų perduodami tokie šaltiniai, kurie tuo naudojasi. |
| 102 |
WebDAV (RFC 2518) pratęstas būsenos kodas, nurodantis, kad apdorojimas bus tęsiamas. |
| 200 |
Užklausa sėkminga, užklausos pageidaujama atsakymo antraštė arba duomenų turinys bus pateikti su šiuo atsakymu. |
| 201 |
Užklausa buvo įvykdyta, ir buvo sukurtas naujas išteklius, atsižvelgiant į užklausą, ir jo URI buvo grąžintas su Location antrašte. Jei pageidaujamas išteklius negali būti sukurtas laiku, turėtų būti grąžintas '202 Accepted'. |
| 202 |
Serveris priėmė užklausą, tačiau dar neapdorota. Kaip ji gali būti atmesta, galutinis užklausa gali būti arba nebūti įvykdyta. Asinchroninių operacijų atveju greičiau ir lengviau siųsti šį būsenos kodą. Atsakymo, grąžinamo su 202 būsenos kodu, tikslas yra leisti serveriui priimti kitų procesų užklausas (pavyzdžiui, kai kurie užduotys, vykdomos kartą per dieną, pagrindinės užduoties), nesukuriant kliento nuolatinės jungties su serveriu, kol visos pagrindinės užduotys yra baigtos. Atsakyme, grąžinamame priimant užklausą ir grąžinant 202 būsenos kodą, turėtų būti pateikta tam tikra informacija apie apdorojimo dabartinę būseną, taip pat nuoroda į būsenos stebėjimo ar prognozavimo informaciją, kad vartotojas galėtų apskaičiuoti, ar operacija jau buvo užbaigta. |
| 203 |
Serveris sėkmingai apdorojęs užklausą, tačiau grąžinto tinklo informacija nėra patvirtinta, jog tai galioja pradiniame serveryje, o yra iš vietos ar trečiųjų šalių kopijos. Dabartiniai duomenys gali būti pradinės versijos subkoppis ar supersetas. Pavyzdžiui, išteklių metaduomenys gali prieinami tik pradiniam serveriui. Naudojantis šiuo būsenos kodu nėra būtina, ir jis tinka tik tuo atveju, jei atgalinėje atsakyme to paties statuso kodas nebūtų 200 OK. |
| 204 |
Serveris sėkmingai apdorojęs užklausą, tačiau nereikia grąžinti jokių turinio elementų ir nori grąžinti atnaujintą metainformaciją. Atsakymas gali grąžinti naują ar atnaujintą metainformaciją kaip antraštes. Jei yra šios antraštės, jos turėtų atitikti prašytą kintamąjį. Jei klientas yra naršyklė, vartotojo naršyklė turėtų išlaikyti puslapį, iš kurio buvo atlikta ši užklausa, nesukeldama jokių pakeitimų dokumento vaizde, net jei pagal taisyklę nauji ar atnaujinti metainformaciją turėtų būti pritaikyti naujo naršyklės aktyvaus vaizdo dokumentams. Kadangi 204 atsakyme draudžiama turėti žinutės kūną, jis visada baigiasi pirmu tuščiu eilute po žinutės pabaigos. |
| 205 |
Serveris sėkmingai apdorojęs užklausą, ir negrįžo jokio turinio. Tačiau, skirtingai nuo 204 atsakymo, šio būsenos kodo atsakymas reikalauja, kad užklausėjas atnaujintų dokumento vaizdą. Šis atsakymas daugiausia naudojamas priėmus vartotojo įvestį, iš karto atnaujinti formą, kad vartotojas lengvai galėtų pradėti kitą įvedimą. Kaip ir 204 atsakyme, šis atsakymas taip pat draudžia turėti žinutės kūną, ir jis baigiasi pirmuoju tuščiu eilute po žinutės pabaigos. |
| 206 |
Serveris sėkmingai apdorojęs kai kurią GET užklausą. Panašiai kaip FlashGet ar Thunder, šios atsakymo rūšys buvo naudojamos nutraukti ehardą ar padalinti didelį dokumentą į kelis atsisiuntimo segmentus. Ši užklausa turi apimti Range antraštę, kad nurodytų, kokio turinio sritį klientas nori gauti, ir ji gali įtraukti If-Range kaip užklausos sąlygą. Atsakymas turi apimti šias antraštes: Content-Range, nurodančią turinio ribą, grąžinamo atsakymo; jei tai yra multipart/byteranges daugiapakopinis atsisiuntimas, kiekvienas multipart segmentas turėtų turėti Content-Range antraštę, kad nurodytų šio segmento turinio ribas. Jei atsakyme yra Content-Length, tuomet jo vertė turi atitikti tikrą grąžinamo turinio ribų skaičių baitais. Date ETag ir / arba Content-Location, jei tas pats užklausa turėtų grąžinti 200 atsakymą. Expires, Cache-Control, ir / arba Vary, jei jų vertė gali skirtingai atitikti anksčiau minėtų kintamųjų kitų atsakymų atitinkamas vertes. Jei šis atsakymas buvo pareikalautas naudojant stiprų talpyklos patvirtinimą, tai šis atsakymas neturėtų apimti kitų elementų antraščių; jei šio atsakymo užklausa panaudojo silpną talpyklos patvirtinimą, šis atsakymas draudžia apimti kitų elementų antraštes; tai užkerta kelią talpyklos elementų turiniui ir atnaujintų antraščių nutraukiama. |
| 207 |
WebDAV (RFC 2518) pratęstas būsenos kodas, nurodantis, kad vėlesnis atsiųstas turinys bus XML pranešimas, ir gali apimti atskiras atsakymo kodus, priklausomai nuo iki šiol pagaminto subužklausų skaičiaus. |
| 300 |
Prašytas išteklius turi keletą galimų pasirinkimų grąžinimo variantų, kiekvienas su savo specifiniu adresu ir naršyklės sukurtomis pirkimo informacija. Naudotojas arba naršyklė gali pasirinkti prioritetinį adresą tam, kad jį peradresuoti. Nebent tai yra HEAD užklausa, šis atsakymas turėtų apimti sąrašą, kuriame yra išteklių savybių ir adresų, kad naudotojas ar naršyklė galėtų pasirinkti geriausią peradresavimo adresą. Šios elemento forma apibrėžiama pagal Content-Type nustatytą formatą. Naršyklė gali automatiškai atlikti atitinkamas pasirinkimas pagal atsakymo formatą ir naršyklės galimybes. Žinoma, RFC 2616 specifikacija nenustato, kaip šis automatinis pasirinkimas turėtų būti atliekamas. Jei serveris jau turi prioritetinį pasirinkimą, tad URI su šiuo rezultatu turėtų būti nurodyta Location; naršyklė gali šią Location vertę naudoti kaip automatinio peradresavimo adresą. Be to, išskyrus jei nurodoma kitaip, šis atsakymas taip pat gali būti talpinamas. |
| 301 |
Prašytas išteklius buvo visam laikui perkeliamas į naują vietą, ir visi ateities šio išteklių nuorodos turėtų naudoti šiuos kelis URI, grąžintus su šiuo atsakymu. Jei įmanoma, klientas su linkų redagavimo funkcionalumu turėtų automatiškai modifikuoti užklausos adresą, kad jis atitiktų serverio teikiamą adresą. Nebent nurodyta kitaip, šis atsakymas taip pat gali būti talpinamas. Naujas, nuolatinis URI turi būti grąžintas atsakyme su Location lauku. Nebent tai yra HEAD užklausa, atsakymo elemente turi būti nuoroda į naują URI ir trumpas paaiškinimas. Jei tai nėra GET ar HEAD užklausa, tuo atveju naršyklė neleidžia automatiškai peradresuoti, nebent gautas vartotojo patvirtinimas, nes užklausos aplinkybės gali pasikeisti. Atkreipkite dėmesį: kai kurioms naršyklėms, naudojančioms HTTP/1.0 protokolą, kai jie siunčia POST užklausą, gavus 301 atsakymą, susiję vėlesni peradresavimo užklausimai taps GET užklausomis. |
| 302 |
Prašytas išteklius šiuo metu laikinas našem pat teikiamas iš skirtingo URI. Kadangi toks peradresavimas yra laikinas, klientas turėtų toliau siųsti užklausas į pradinį adresą. Tik jei tai nurodyta Cache-Control arba Expires, šis atsakymas gali būti talpinamas. Naujas laikinas URI turi būti grąžintas atsakyme su Location lauku. Nebent tai yra HEAD užklausa, atsakymo elemente turi būti nuoroda į naują URI ir trumpas paaiškinimas. Jei tai nėra GET ar HEAD užklausa, naršyklė neleidžia automatiškai peradresuoti, nebent gautas vartotojo patvirtinimas, kadangi užklausos aplinkybės gali pasikeisti. Atkreipkite dėmesį: nors RFC 1945 ir RFC 2068 specifikacijos neleidžia klientui keičiant užklausimo metodą peradresavimų metu, dauguma šiuolaikinių naršyklių laiko 302 atsakymą kaip 303 atsakymą, besinaudodamos GET metodu, ignoruodamos pirmą užklausimą. |
| 303 |
Atsakymas atitinkantis šią užklausą gali būti surastas kitoje URI, ir klientas turėtų ją gauti naudojant GET metodą. Šio metodo tikslas yra leisti POST užklausoms, paleidžiamoms iš scenarijų, kad būtų nukreipti į naują išteklių. Šis naujas URI nesuteikia naujos nuorodos pradiniam ištekliui. Taip pat 303 atsakymai draudžia talpinti. Žinoma, antra užklausa (peradresavimas) gali būti talpinama. Naujasis URI turi būti grąžintas atsakyme su Location lauku. Nebent tai yra HEAD užklausa, atsakymo elemente turi būti nuoroda į naują URI ir trumpas paaiškinimas. Atkreipkite dėmesį: daugelis HTTP/1.1 versijų prieš tai esančių naršyklių neteisingai interpretuoja 303 būseną. Jei reikia atsižvelgti į bendravimą su šiomis naršyklėmis, 302 statuss turėtų būti tinkamas, nes dauguma naršyklių elgiasi taip, kaip reikalaujama normos, kad 303 atsakymas turėtų būti tvarkomas. |
| 304 |
Jei klientas siunčia sąlyginę GET užklausą, ir ji buvo leidžiama, o dokumento turinys (nuo paskutinio apsilankymo ar pagal užklausos sutartį) nepasikeitė, tuomet serveris turėtų grąžinti šį būsenos kodą. 304 atsakymas draudžia turėti žinutės kūną, todėl visada baigiasi pirmu tuščiu eilute po žinutės pabaigos. Šis atsakymas turi būti su šiomis antraštėmis: Date, nebent tas serveris neturi laikrodžio. Jei serveris neturi laikrodžio, laikydamasis šių taisyklių, tada tarpinis serveris ir klientas gali pridėti Date lauką prie gaunamų atsakymo antraščių (kaip apibrėžta RFC 2068), ir talpyklų mechanizmas veiks normaliai. ETag ir/iš Content-Location, jei pirmiau minėta užklausa turėtų grąžinti 200 atsakymą. Expires, Cache-Control, ir/iš Vary, jei jų vertės gali skirtis nuo kitų atsakymų atžvilgiu. Jei šio atsakymo užklausa naudojasi stipria talpykla, tuomet šis atsakymas neturėtų turėti kitų objektų antraščių; kitaip (pavyzdžiui, sąlyginės GET užklausos kartojimas naudojantis silpna talpykla), šis atsakymas draudžia turėti kitų objektų antraščių; tai sukelia nesuderinamumą tarp talpyklų turinio ir atnaujintų objektų antraščių. Jei 304 atsakymas nurodo, kad konkretus objektas neturi talpyklos, talpyklų sistema turėtų ignoruoti šį atsakymą ir pakartoti užklausą be jokių apribojimų. Jei gaunamas 304 atsakymas, informuojantis, kad reikia atnaujinti konkretų talpyklos įrašą, talpyklų sistema turėtų atnaujinti visą įrašą, kad atspindėtų visus atnaujintus laukus atsakyme. |
| 305 |
Prašytas išteklius turi būti pasiekiamas per nurodyto tarpinio serverio. Location lauke bus pateikta nurodyto tarpinio serverio URI informacija, gavėjas turėtų pakartoti pačių užklausą, kad pasiektų pagal nurodytą išteklių. Tik originalus serveris gali sugeneruoti 305 atsakymą. Atkreipkite dėmesį: RFC 2068 nenurodo, jog 305 atsakymas yra skirtas nukreipti atskirą užklausą, ir tik originalus serveris turi galią šio atsakymo. Ignoruodami šias taisykles, gali kilti rimtų saugumo problemų. |
| 306 |
Naujausioje specifikacijoje 306 statusas nebenaudojamas. |
| 307 |
Prašytas išteklius dabar laikinai reaguoja iš skirtingo URI. Kadangi šis peradresavimas yra laikinas, klientas turėtų toliau siųsti užklausas į originalų adresą. Tik jei tai nurodyta Cache-Control ar Expires, ši atsakymas gali būti talpintas. Naujas laikinas URI turi būti grąžintas atsakyme su Location lauku. Nebent tai yra HEAD užklausa, atsakymo elemente turi būti nuoroda į naują URI ir trumpas paaiškinimas. Kadangi kai kurie naršyklės nepalaiko 307 atsakymo, būtina pridėti reikalingą informaciją, kad vartotojas galėtų suprasti ir pasiekti naują URI. Jei tai nėra GET ar HEAD užklausa, tuomet naršyklė neleidžia automatiškai peradresuoti, nebent gautas vartotojo patvirtinimas, nes užklausos aplinkybės gali pasikeisti. |
| 400 |
1. Semantika yra neteisinga, šiuo metu užklausa negali būti suvokta serverio. Jei nebus atlikti pakeitimai, klientas neturėtų pakartotinai pateikti šios užklausos. 2. Užklausos parametrai yra neteisingi. |
| 401 |
Šiuo metu užklausa reikalauja vartotojo autentifikacijos. Atsakymas turi būti su WWW-Authenticate informacijos antrašte, kad būtų užklausta vartotojo informacija. Klientas gali pakartotinai pateikti užklausą, jei pateiks teisingą Authorization antraštę. Jei šiuo metu užklausa jau turi Authorization pažymėjimus, tuomet 401 atsakymas reiškia, kad serveris atmetė tuos pažymėjimus. Jei 401 atsakymas turi tą patį autentifikavimo užklausimą kaip ankstesnis atsakymas, ir naršyklė jau bandė bent kartą, naršyklė turėtų parodyti turinį, kurį apima atsakymas, nes šis turinys gali turėti diagnostinę informaciją. Žr. RFC 2617. |
| 402 |
Šis statusas yra rezervuotas galimiems reikalavimams ateityje. |
| 403 |
Serveris suprato užklausą, tačiau atsisako ją vykdyti. Skirtingai nuo 401 atsakymo, autentifikacija čia padėti negali, o ši užklausa neturėtų būti pakartota. Jei tai nėra HEAD užklausa, ir serveris nori paaiškinti, kodėl užklausa negali būti vykdoma, tai turėtų būti paaiškinta atsakymo turinyje. Žinoma, serveris taip pat gali grąžinti 404 atsakymą, jei nenori, kad klientas gautų jokios informacijos. |
| 404 |
Užklausa nepavyko, išteklius, kurio prašoma, nebuvo rastas serveryje. Nėra jokios informacijos, kuri pasakytų naudotojui, ar tai yra laikinas, ar nuolatinis. Jei serveris žino situaciją, jis turėtų naudoti 410 statusą, kad informuotų, jog senas išteklius dėl vidinių konfigūravimo problemų tapo neprieinamas, ir kad nėra jokio adreso, į kurį galima peradresuoti. 404 šis statusas yra plačiai taikomas, kuomet serveris nenori atskleisti, kodėl užklausa buvo atmesta arba kai neturi jokių kitų tinkamų atsakymo. |
| 405 |
Užklausoje nurodytas užklausos metodas negali būti naudojamas šiam ištekliui. Šis atsakymas turi grąžinti Allow antraštę nurodydamas sąrašą metodų, kuriuos šaltinis gali priimti. Kadangi PUT, DELETE metodai daro rašymo operacijas serveryje, dauguma serverių nepalaiko šių metodų arba, pagal numatytąsias konfigūravimo normas, jie negali būti leidžiami, todėl tokioms užklausoms būtų grąžintas 405 klaidos kodas. |
| 406 |
Užklausomos išteklių turinio savybės negali atitikti sąlygų nurodytų užklausos antraštėje, todėl negalima sugeneruoti atsakymo turinio. Nebent tai yra HEAD užklausa, šis atsakymas turėtų grąžinti turinį su galimais turinio savybių ir adresų srautais, leidžiančiais naudotojui ar naršyklei pasirinkti geriausias turinio savybes. Turinio forma apibrėžiama pagal Content-Type antraštėje nurodytą medijos tipą. Naršyklė gali pasirinkti geriausią atsižvelgdama į formatą ir savo galimybes. Tačiau normos nenurodo, kad tokiems automatiniams pasirinkimams yra standartai. |
| 407 |
Panašus į 401 atsakymą, tik klientas turi autentifikuotis per tarpinį serverį. Tarpinis serveris privalo grąžinti Proxy-Authenticate norint paklausti dėl autentifikavimo. Klientas gali grąžinti Proxy-Authorization antraštę autentifikacijai. Žr. RFC 2617. |
| 408 |
Užklausa viršija laiką. Klientas nesugebėjo įgyvendinti užklausos per laiką, kurį serveris buvo pasiruošęs laukti. Klientas gali bet kada vėl pateikti šią užklausą be jokių pakeitimų. |
| 409 |
Dėl konfliktų su dabartine užklausos išteklių būsena, užklausa negali būti įvykdyta. Šis kodas leidžiamas tik tokiu atveju, kai vartotojas gali išspręsti konfliktą ir pakartotinai pateikti naują užklausą. Atsakymas turėtų apimti pakankamai informacijos, kad vartotojas galėtų nustatyti konflikto kilmę. Konfliktai dažniausiai kyla, kai apdorojama PUT užklausa. Pavyzdžiui, jei aplinkoje, kurioje tikrinama versija, kai kuriuo PUT pateikimo prie konkretaus išteklių versijos informacija prieš tai buvusią trečią pusę prieštarauti, serveris turėtų grąžinti 409 klaidos atsakymą, informuodamas, kad užklausa negali būti įvykdyta. Atsakyme dažniausiai būtų pateikta dviejų konfliktuojančių versijų skirtumų analizė, kad vartotojas galėtų pakartoti sujungtą naujo versiją. |
| 410 |
Prašytas išteklius serverio nebėra prieinamas, ir nėra jokių žinomų peradresavimo adresų. Toks atvejis turėtų būti laikomas nuolatiniu. Jei įmanoma, turinčius linkų redagavimo galimybes, klientas turėtų turėti naudotojo leidimą pašalinti visas nuorodas, rodančias šį adresą. Jei serveris nežino arba negali nustatyti, ar ši situacija yra nuolatinė, tada jis turėtų naudoti 404 statusą. Nebent nurodytas kitaip, šis atsakymas yra talpinamas. 410 atsakymas skiriamas padėti svetainės administratoriams palaikyti svetainę, informuojant vartotojus, kad išteklius turi būti pašalintas, ir serverio savininkas tikisi, kad visi nuorodų ryšiai taip pat buvo pašalinti. Tokių įvykių žymėjimas 410 yra labai dažnas, tarp laikinių paslaugų ir pridėtų vertybių. Be to, 410 atsakymas taip pat naudojamas užtikrinti, kad vartotojas sužinotų, kad kažkuris asmens resursas, anksčiau, nebėra prieinamas svetainėje. Žinoma, ar visi nuolatiniai nenustatomi ištekliai turėtų būti pažymėti kaip '410 Gone' ir kiek laiko tai turėtų būti daroma, priklauso nuo serverio savininko. |
| 411 |
Serveris atsisako priimti užklausą, nes nėra apibrėžtas Content-Length laukelis. Klientas gali pakartotinai pateikti užklausą pridedais teisingą Content-Length laukelį, nurodantį užklausos kūno ilgį. |
| 412 |
Serveris, tikrindamas anksčiau pateiktų sąlygų galiojimą, neįvykdė vieno arba daugiau nurodytų. Šis statusas leidžia klientui, gaunant išteklius, nustatyti ankstesnes sąlygas (užklausos antraščių laukų duomenis) saugoti, norint išvengti šio metodo taikymo jūsų pageidaujamoms medžiagoms. |
| 413 |
Serveris atsisako apdoroti šią užklausą, nes iš pateiktų elementų duomenų dydis viršija serverio norimą ar galintį apdoroti ribą. Šiuo atveju serveris gali uždaryti ryšį, kad neleisti klientui tęsti šios užklausos. Jei ši situacija yra laikina, serveris turėtų grąžinti Retry-After atsakymą, nurodydamas, po kiek laiko klientas gali bandyti dar kartą. |
| 414 |
Prašytas URI ilgis viršija serverio galimybes, todėl serveris atsisako paslaugų šiai užklausai. Tai yra reti atvejai; paprastai atsitikimai apima: forma, kuri turėjo naudoti POST metodą, dabar buvo pateikta kaip GET metodas, dėl ko užklausos stringas buvo per ilgas. Peradresavimas URI „juodojo skylės“ atvejų, kai kiekvieną kartą buvo peradresuojamas senas URI kaip naujo URI dalis, sukelia, kad daugybės peradresavimų metu URI viršija ilgio limitą. Klientas bando pasinaudoti kai kuriomis serverio saugumo spragomis. Tokių serverių naudojimas turėtų turėti mayrainuoto ilgio talpyklą ir gali sukelti lankstų kodo vykdymą, jei get parametrai viršija tam tikrą skaičių. Serveriai, neturintys tokių spragų, turėtų grąžinti 414 statusą. |
| 415 |
Dėl šiuo metu užklausos metodo ir prašomo ištekliaus pateiktas turinys nėra serverio palaikomas formatas, todėl užklausa atmesta. |
| 416 |
Jei užklausoje buvo Range antraštė, ir jokie duomenų intervalai, nurodyti Range, nepriklauso dabartiniams ištekliams, serveris turėtų grąžinti 416 statusą, jeigu Range naudoja baitų diapazoną. Šiuo atveju tai reiškia, kad visi užklausos duomenų intervalai viršija dabartinio ištekliaus ilgį. Serveris turėtų grąžinti 416 statusą kartu su Content-Range turinio antrašte, nurodančia dabartinio ištekliaus ilgį. Šis atsakymas taip pat draudžia naudoti multipart/byteranges como Content-Type. |
| 417 |
Užsakymo reikalaujamasis turinys nurodytas Expect užklausų antraštėje negali būti patenkintas serverio. Arba, jei serveris yra tarpinis serveris, jis gali turėti aiškių įrodymų, kad tikėtinas turinys, nurodytas Expect, negali būti patenkintas. |
| 421 |
Kliento IP adresas iki serverio viršija leistinų ryšių skaičių. Paprastai tai turėtų nurodyti klientų adresą, matomą serverio (pvz., vartotojo vartai ar tarpinio serverio adresas). Tokiu atveju ryšių skaičiavimas gali apimti daugiau nei tik vienas terminalinis vartotojas. |
| 422 |
Užklausa formatuota teisingai, tačiau dėl semantinių klaidų ji negali būti įvykdyta. (RFC 4918 WebDAV) 423 Locked šis išteklius yra užrakintas. (RFC 4918 WebDAV) |
| 424 |
Dėl išankstinio užklausos klaidų, aktuali užklausa nesugebama, pavyzdžiui, PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Apibrėžta WebDav Advanced Collections projekte, tačiau neatrasta WebDAV užsakymų sekoso protokole (RFC 3658). |
| 426 |
Klientas turėtų pereiti prie TLS/1.0. (RFC 2817) |
| 449 |
Microsoft pratęstas, nurodantis, kad užklausa turėtų būti pakartota tinkamai atlikus veiksmus. |
| 500 |
Serveris susidūrė su nenumatyta situacija, dėl kurios jis negali atlikti užklausos. Paprastai šis problemos atvejis atsiranda serveryje, kai programinė įranga sugenda. |
| 501 |
Serveris nepalaiko šiai užklausai reikalingos funkciją. Kai serveris negali identifikuoti užklausos metodo, ir negali palaikyti jokio paprašymo šaltiniu. |
| 502 |
Serveris, dirbdamas kaip tarpinis ar proxy serveris, gavo netinkamą atsakymą užklausoje, kai bandė vykdyti prašymus skaitmeninio serverio pradinio. |
| 503 |
Serveris laikinai negali aptarnauti užklausos, paprastai dėl laikino serverio remontų ar perkrovimo. Šis atvejas yra laikinas, o atkurti galima po tam tikro laiko. Jei įmanoma prognozuoti atidėto laiko, atsakyme gali būti nurodytas Retry-After laikas. Jei šis Retry-After informacijos pateikimas nėra grąžintas, tuomet klientas turėtų tvarkyti jį, kaip ir 500 atsakymą. Atkreipkite dėmesį: faktas, kad 503 statusas egzistuoja, nereiškia, jog serveris privalo jį naudoti, kai jis yra perkrautas. Kai kurie serveriai nori atmesti kliento ryšį. |
| 504 |
Serveris, dirbdamas kaip tarpinis arba proxy serveris, ne gavo atsako laiku nusipirktas iš ankstesnio serverio (URI grindžiamos serverio, kaip HTTP, FTP, LDAP) arba pagalbinio serverio (pavyzdžiui, DNS) atsako. Atkreipkite dėmesį: kai kurie tarpiniai serveriai grąžina 400 arba 500 klaidas DNS užklausoms, kai jie laiku nesulaukia.) |
| 505 |
Serveris nepalaiko ar atsisako palaikyti HTTP versiją, naudojamą šioje užklausime. Tai reiškia, kad serveris negali naudoti tos pačios versijos, kaip ir klientas. Atsakyme turėtų būti pateikta aprašymas, kodėl versija nėra palaikoma, ir kokių protokolų serveris remiasi. |
| 506 |
Serveris turi vidinę konfigūracijos klaidą: prašoma sukamuos transportacijos medžiaga buvo konfigūruota naudojant save, todėl ji nėra tinkama orientyro metu. |
| 507 |
Serveris negali saugoti visų turiniui užbaigti reikiamų medžiagų. Ši situacija laikoma laikina. WebDAV (RFC 4918) |
| 509 |
Serveris pasiekė juostos ribą. Tai nėra oficialus statusas, bet vis dar plačiai naudojamas. |
| 510 |
Registruotos išteklis buvo nė išsilaikyti. |