| HTTP statuss kods |
Statusa koda nozīme |
| 100 |
Klientam jāturpina sūtīt pieprasījumu. Šī pagaidu atbilde tiek izmantota, lai paziņotu klientam, ka daļa no viņa pieprasījuma ir saņemta serverī un vēl nav noraidīta. Klientam jāturpina sūtīt pārējo pieprasījuma daļu vai, ja pieprasījums ir pabeigts, jānoliedz šī atbilde. Serverim pēc pieprasījuma pabeigšanas jāatsūta galīgā atbilde klientam. |
| 101 |
Serveris ir sapratis klienta pieprasījumu un brīdinās klientu par to, kā nomainīt protokolu, ar Upgrade galveni, lai pabeigtu šo pieprasījumu. Pēc pēdējā tukšā rinda nosūtīšanas šis serveris pāries uz tajā norādītajiem protokoliem. Tikai tad, ja jauni protokoli sniedz lielāku ieguvumu, tad šīs darbības ir jāveic. Piemēram, pāreja uz jauno HTTP versiju, jo tas ir labāk nekā vecā versija, vai pāreja uz reāllaika sinhronizētu protokolu resursu sūtīšanai. |
| 102 |
Statusa kods, kas paplašināts ar WebDAV (RFC 2518), kas apzīmē, ka apstrāde tiks turpināta. |
| 200 |
Pieprasījums ir izpildīts, pieprasītā atbilde vai datu ķermenis tiks atsūtīts kopā ar šo atbildi. |
| 201 |
Pieprasījums ir izpildīts, un ir izveidota jauna resursa vieta nepieciešamības dēļ, un tās URI ir atgriezta kopā ar Location galveni. Ja nepieciešamais resurss nevar tikt izveidots nekavējoties, jāatgriež "202 Akceptēts". |
| 202 |
Serveris ir pieņēmis pieprasījumu, bet vēl nav apstrādājis. Kā tam var būt noraidīšana, beidzamo pieprasījumu var izpildīt vai neizpildīt. Asinhronās operācijās nav nekā ērtāka, kā atgriezt šo statusa kodu. Atbilde ar 202 statusa kodu tiek sniegta, lai serveris varētu pieņemt citu procesu pieprasījumus (piemēram, kāds, kas tiek izpildīts reizi dienā) bez nepieciešamības, lai klients nemitīgi vilktu pieslēgumu serverim, kamēr pilna procesa izpilde nav pabeigta. Atbilde, kurā pieņemts pieprasījumu apstrādi un tiek atgriezts 202 statusa kods, ir jābūt atgrieztai ar dažām norādēm par šī procesa pašreizējo stāvokli, kā arī norādi uz pārvaldniekiem vai prognozēm, lai lietotājo varētu novērtēt, vai operācija jau ir pabeigta. |
| 203 |
Serveris ir veiksmīgi apstrādājis pieprasījumu, bet atsūtītā metadatu informācija nav derīga oriģinālajā serverī, bet ir no vietnes vai trešās puses kopijas. Pašreizējā informācija var būt oriģināla versija vai tās apakškopa vai superset. Piemēram, resursu metadati var novest pie oriģinālā servera apziņas par metainformācijas superskaitu. Šī statusa koda izmantošana nav obligāta, un tas ir pieņemams tikai gadījumos, kad, nesaņemot šo statusa kodu, atbilde tiks atgriezta kā 200 OK. |
| 204 |
Serveris veiksmīgi apstrādāja pieprasījumu, bet nevēlas atgriezt nekādu metadatu saturu, un vēlas atgriezt atjauninātu metadatu informāciju. Atbilde var atgriezt jaunus vai atjauninātus metadatus kā atbildes galvenē. Ja šie galvenes informācijas lauki ir, tie jāsaskaņo ar pieprasīto mainīgo. Ja klients ir pārlūkprogramma, tad lietotāja pārlūkprogrammai ir jāturēs lapa, kas izsūtījusi šo pieprasījumu, bez izmaiņām dokumentā vizuālajā izskatā, pat ja jaunās vai atjauninātās metadatu informācijas attiecīgi jāievieš lietotāja pārlūkprogrammas darba logā. Tā kā 204 atbilde ir aizliegta, lai iekļautu jebkādu ziņojumu, tā vienmēr beidzas ar pirmo tukšo rindu pēc galvenēm. |
| 205 |
Serveris veiksmīgi apstrādāja pieprasījumu un nesniedza nevienu saturu. Tomēr, atšķirībā no 204 atbildes, atgriežot šo statusa kodu, pieprasītājs tiek aicināts atiestatīt dokumenta skatījumu. Šī atbilde galvenokārt tiek izmantota, lai tūlītēji atiestatītu formu pēc tā, kad ir saņemti lietotāja dati, lai lietotājs varētu viegli uzsākt jauna ievadīšanu. Tāpat kā 204 atbilde, šī atbilde ir aizliegta, lai iekļautu jebkādu ziņojumu, un beidzas ar pirmo tukšo rindu pēc galvenēm. |
| 206 |
Serveris ir veiksmīgi apstrādājis daļēju GET pieprasījumu. Līdzīgi kā FlashGet vai Thunder, HTTP lejupielādes rīki izmanto šādus atbildes kodus, lai īstenotu atsāknēšanu vai dalītu lielu dokumentu vairākos lejupielādes segmentos. Šim pieprasījumam jāietver Range galvene, lai norādītu, kādu saturu klients vēlas saņemt, un tas var saturēt If-Range kā pieprasījuma nosacījumu. Atbildei jāietver šādas galvenes: Content-Range, lai norādītu šīs atbildes ietverto satura diapazonu; ja noklusējuma veids ir multipart/byteranges, katrā multipart segmentā tam jāietver Content-Range, lai norādītu šā segmenta satura diapazonu. Gadījumā, ja atbilde ietver Content-Length, tā vērtībai jāsakrīt ar atgrieztā satura reālo baitiem. Date, ETag un / vai Content-Location, ja šis pieprasījums varētu atgriezt 200 atbildi. Expires, Cache-Control un / vai Vary, ja to vērtības var būt atšķirīgas, nekā konkrētiem mainīgajiem, citiem atbilstošiem. Gadījumā, ja šī atbilde ir attiecīga If-Range stiprā kešatmiņas verificēšanai, šī atbilde nedrīkst saturēt citus standarta galvenes; gadījumā, ja šī atbilde ir attiecīga If-Range vājai kešatmiņas verificēšanai, šī atbilde ir aizliegta, lai iekļautu citus galvenes; tas novērš pretrunību starp kešatmiņas datu saturu un to atjaunināto galvenēm. Pretējā gadījumā šai atbildei jāietver visi galvenes, kas jāatgriež ar 200 atbildi. Ja ETag vai Last-Modified galvenes nevar precīzi sakrist, klients kešatmiņai ir jāizvairās apvienot 206 atbildes saturu ar iepriekš jebkurai kešotajai saturam. Visas kešatmiņas, kas neatbalsta Range un Content-Range galvenes, ir aizliegtas kešot 206 atbildes saturu. |
| 207 |
Statusa kods, kas paplašināts ar WebDAV (RFC 2518), pārstāv, ka tālākā ziņojuma saturs būs XML ziņojums, kas var saturēt sēriju neatkarīgu atbilžu kodu atkarībā no tā, cik daudz apakš pieprasījumu ir veikta. |
| 300 |
Pieprasītajam resursam ir vairāki iespējamie atbilžu kodi, katram ir savs konkrētais adrese un pārlūkprogrammas norādījuma informācija. Lietotājs vai pārlūkprogramma var brīvi izvēlēties vienu iecienītu adresi, lai tai atkal pāradresētu. Izņemot gadījumus, kad tas ir HEAD pieprasījums, šai atbildei jāietver arī resursu īpašību un adreses saraksts, lai lietotājs vai pārlūkprogramma varētu izvēlēties vispiemērotāko pāradresācijas adresi. Šī satura formāts tiek noteikts ar Content-Type definēto formātu. Pārlūkprogrammas var automātiski veikt vispiemērotākās izvēles, pamatojoties uz atbildes formātu un pašu pārlūkprogrammu iespējām. Protams, RFC 2616 specifikācijas nenosaka, kāda veida automātiskās izvēles jāveic. Ja serverim jau ir veiksmīga atbilžu izvēle, tad šim atbildes parametram jānorāda šis atbilžu URI; pārlūkprogramma varīgi var automātiski izmantot šo Location vērtību kā automātisko pāradresēšanas adresi. Izņemot gadījumus, ja sitienu izsaka citādi, šī atbilde ir cacheable. |
| 301 |
Pieprasītais resurss ir pastāvīgi pārvietots uz jauno adresi, turpmāk jekurām šī resursa atsaucēm vajadzētu izmantot kādu no šīm atbildē atgrieztajām URI. Ja iespējams, klientiem ar saites rediģēšanas funkcionalitāti automātiski jāpārraksta pieprasījuma adrese uz adresi, kas saņemta no servera. Izņemot gadījumus, kad norādīts citādi, šī atbilde ir cacheable. Jaunas pastāvīgas URI ir jāatgriež atbildes Location laukā. Ja tas nav HEAD pieprasījums, atbildes ķermenī jāizvēlas adreses un īsas skaidrojošas informācijas, attiecībā uz jauno URI. Ja šis pieprasījums nav GET vai HEAD pieprasījums, tad pārlūkprogramma aizliedz automātisku pāradresēšanu, līdz tiek apstiprināta lietotāja izvēle, jo pieprasījuma nosacījumi var mainīties. Pievērsiet uzmanību: dažiem pārlūkprogrammām, kas izmanto HTTP/1.0 protokolu, ja to nosūtītā POST pieprasījuma rezultātā tiek saņemta 301 atbilde, nākamais pāradresēšanas pieprasījums var kļūt par GET. |
| 302 |
Pieprasītais resurss pašlaik tiek pagaidu uz jaunu URI. Tā kā šī pāradresēšana ir pagaidu, klientiem jāturpina sūtīt turpmākos pieprasījumus uz iepriekšējo adresi. Tikai tad, ja Cache-Control vai Expires ir noteikts, šī atbilde ir cacheable. Jaunais pagaidu URI jāatgriež atbildes Location laukā. Ja tas nav HEAD pieprasījums, tad atbildes ķermenī vajadzētu iekļaut saiti uz jauno URI kopā ar īsu izklāstu. Ja šis pieprasījums nav GET vai HEAD pieprasījums, tad pārlūkprogramma aizliedz automātisku pāradresēšanu, līdz tiek apstiprināta lietotāja izvēle, jo pieprasījuma nosacījumi var mainīties. Pievērsiet uzmanību: bet RFC 1945 un RFC 2068 normas neatļauj klientiem mainīt pieprasījuma metodi pāradresēšanas intereses pēc tam, kad ir saņemts 302 atbilde, un daudzas esošas pārlūkprogrammas uzskata 302 atbildi par 303 to pašu atbildi, piekļūstot URI no Location zīmes, ignorējot sākotnējo pieprasījuma metodi. Statusa koda 303 un 307 mērķis ir nodrošināt skaidri, kādas reakcijas serverim sagaida no klienta. |
| 303 |
Atbilde, kas atbilst iepriekšējam pieprasījumam, tiek atrasta citā URI, un klients jāveic piekļuve, izmantojot GET metodi, uz šo resursu. Šī metode ir izstrādāta, lai atļautu, ka ar skriptiem aktivizēti POST pieprasījumi var tikt pāradresēti uz jauniem resursiem. Šis jaunais URI nebūs oriģinālā resursa apmaiņas atsauce. Tajā pašā laikā 303 atbilde ir aizliegta kešatmiņā. Protams, otrais pieprasījums (pāradresing) var tikt kešots. Jaunajam URI jāatgriežas atbildes Location laukā. Ja tas nav HEAD pieprasījums, tad atbildes ķermenī jāietver saite uz jauno URI un īsa izklāsts. Pievērsiet uzmanību: daudzas pārlūkprogrammas pirms HTTP/1.1 nevar pareizi saprast 303 statusu. Ja nepieciešams ņemt vērā šos pārlūkus, 302 statuss varētu būt piemērots, jo daudz pārlūkprogrammas apstrādā 302 atbildi, kā šādi paredzēts prasību atbildes, kas paredzētas 303 statusam. |
| 304 |
Ja klients nosūtījis nosacītu GET pieprasījumu, un šis pieprasījums ir atļauts, un dokumenta saturs (kopš pēdējās piekļuves vai atbilstoši pieprasījuma nosacījumiem) nav mainījies, tad serverim būtu jāsūta šo statusu. 304 atbildei ir aizliegts iekļaut ziņojumu, tāpēc tā vienmēr beidzas ar pirmo tukšo rindu pēc galvenēm. Šai atbildei jāietver šāda galvas informācija: Date, ja vien šis serveris nav bez pulksteņa. Ja pulksteņu nav, tomēr serveris ievēro šīs prasības, tad starpniekserveriem un klientiem ir jāspēj pievienot Date laukā, ko saņēmuši galvenēs (kā nosaka RFC 2068), un kešatmiņas mehānisms darbosies normāli. ETag un / vai Content-Location, ja arī šis pieprasījums varētu atgriezt 200 atbildi. Expires,Cache-Control un / vai Vary, ja to vērtības varētu būt atšķirīgas, nekā citām atsaucēm. Ja šis pieprasījums ir attiecīgs spēcīgai kešatmiņas verificēšanai, tad šai atbildei nevajadzētu iekļaut citus oriģinālo galvju; ja šis pieprasījums ir attiecīgi tendences kešatmiņas izmantošanai, šai atbildei jāaizliedz citas galvenes; tas novērš pretrunību starp kešatmiņā uzkrāto saturu un atjauninātajām galvenēm. Ja 304 atbilde norāda, ka kāda konkrēta saturs nav kešots, tad kešatmiņas sistēmai jāignorē šī atbilde un jāpārsūta pieprasījums bez ierobežojumiem. Ja tiek saņemta 304 atbilde, kas uzdod atjaunot kādas kešatmiņas ierakstu, tad kešatmiņas sistēmai jāatjauno viss ieraksts, lai atspoguļotu visas izmaiņas, kas tika atjaunotas atbildē. |
| 305 |
Pieprasītais resurss jāpieprasa caur konkrētu starpnieku. Location laukā tiks sniegta informācija par šo proxy, un saņēmējam jāpārsūta atsevišķu pieprasījumu, izmantojot šo starpnieku, lai piekļūtu atbilstošajam resursam. Tikai oriģinālais serveris var veidot 305 atbildi. Lūdzu, ņemiet vērā: RFC 2068 neuzskata 305 atbildi kā atsevišķa pieprasījuma pāradresēšanu un norāda, ka to var izveidot tikai oriģinālais serveris. Šo ierobežojumu ignorēšana var izraisīt nopietnas drošības sekas. |
| 306 |
Jaunā specifikācijā 306 statuss vairs netiek izmantots. |
| 307 |
Pieprasītais resurss šobrīd tiek pagaidu atbildēts no cita URI. Tā kā šī pāradresēšana ir pagaidu, klientiem jāturpina sūtīt turpmākos pieprasījumus uz iepriekšējo adresi. Tikai tad, ja Cache-Control vai Expires ir noteikts, šī atbilde ir cacheable. Jaunais pagaidu URI jāpaziņo atbildes Location laukā. Ja tas nav HEAD pieprasījums, atbildes ķermenī jāietver saite uz jaunajiem URI kopā ar īsu izklāstu. Ņemiet vērā, ka, jo daudzas pārlūkprogrammas nesaprot 307 statusu, ir jāpievieno iepriekš minētā informācija, lai nodrošinātu, ka lietotājs saprastu un lūgtu piekļūt jaunajiem URI. Ja šis pieprasījums nav GET vai HEAD pieprasījums, tad pārlūkprogramma aizliedz automātisku pāradresēšanu, kamēr lietotājs to nav apstiprinājis, jo pieprasījuma nosacījumi var mainīties. |
| 400 |
1. Semantika ir kļūdaina, un pašreizējais pieprasījums serverim nav saprotams. Izņemot izmaiņas, klients nedrīkst atkārtoti iesniegt šo pieprasījumu. 2. Pieprasījuma parametri ir kļūdaini. |
| 401 |
Pašreizējam pieprasījumam ir nepieciešama lietotāja autentifikācija. Šai atbildei jāietver piemērota WWW-Authenticate galviene lai pieprasītu informāciju no lietotāja. Klients var atkārtoti nosūtīt pieprasījumu ar atbilstošo Authorization galvieni. Ja pašreizējais pieprasījums jau satur Authorization sertifikātus, tad 401 atbilde norāda, ka serveris ir noraidījis šos sertifikātus. Ja 401 atbilde satur tādu pašu autentifikācijas pieprasījumu kā iepriekšējā atbilde, un pārlūkprogramma ir vismaz reizi mēģinājusi izsniegt autentifikāciju, pārlūkprogramma jāparāda lietotājam atbildes saturu, jo šis saturs var ietvert attiecīgās diagnostikas informācijas. Skatīt RFC 2617. |
| 402 |
Šis statuss ir rezervēts nākotnē potenciālo prasību izpildīšanai. |
| 403 |
Serveris ir sapratis pieprasījumu, bet atsakās to veikt. Atšķirībā no 401 atbildes, autentifikācija nevar sniegt nekādu palīdzību, un šis pieprasījums nedrīkst atkārtoti iet. |
| 404 |
Pieprasījums ir neveiksmīgs, pieprasītais resurss nav atrasts serverī. Nav informācijas, lai pastāstītu lietotājam, vai šī situācija ir pagaidu vai pastāvīga. Ja serveris zina, situācija būtu jāizmanto 410 statuss, lai paziņotu, ka resurss ir pastāvīgi nepieejams iekšējo konfigurācijas mehānismu dēļ, un nav nekādas iespējas pārosdīt. 404 šis statuss ir plaši izmantots, kad serveris nevēlas atklāt iemeslu, kāpēc pieprasījums tika noraidīts vai nav citu piemērotu atbilžu. |
| 405 |
Pieprasījumā norādītā pieprasījuma metode nav atļauta pieprasītā resursa adresē. Šai atbildei jāatgriež Allow galvene ar pieejamo pieprasījumu metožu sarakstu, ko pašreizējais resurss var pieņemt. Ņemot vērā, ka PUT un DELETE metodes modificē un rakstiski ieraksta resursus serverī, tad lielākā daļa tīmekļa serveri pēc noklusējuma neatzīst šīs pieprasījumu metodes, viņi atgriezīs 405 kļūdu par tiem."," |
| 406 |
Pieprasītā resursa satura īpašības neatbilst pieprasījumu galvenēm, tāpēc nevar tikt izveidojusi atbilde. Ja tas nav HEAD pieprasījums, tad šai atbildei jāatgriež iekšējā resursa saturu ar sarakstu, kurā ir iespējams izvēlēties vispiemērotāko saturu un adreses. Satura formāts nosaka Content-Type galviene iekšējo mediju tipu. Pārlūkprogrammas var automātiski izvēlēties vispiemērotāko, pamatojoties uz formātu un tās iespējām. Taču, specifikācijās nebija definētas nekādas vadlīnijas, kādas automātiskās izvēles jāveic. |
| 407 |
Līdzīgi kā 401 atbilde, iztumšana, bet šoreiz klientam ir jāveic autentifikācija pie starpniekservera. Starpniekserveris atgriež Proxy-Authenticate informāciju par nepieciešamo autentifikāciju. Klients var atgriezt Proxy-Authorization informāciju, lai veiktu autorizāciju. Skatīt RFC 2617. |
| 408 |
Pieprasījums ir beidzies. Klients nesniedza pieprasījumu serverim gaidītajā laikā. Klients var atkārtoti nosūtīt pieprasījumu bez izmaiņām. |
| 409 |
Pieprasījums nevar tikt izpildīts, jo ir pretruna ar pašreizējo resursa stāvokli. Šis statuss ir atļauts izmantot tikai situācijās, kad lietotājs uzskatīts, ka viņš var atrisināt konflikta jautājumu un atkārtoti iesniegt liftu. Šai atbildei jāietver pietiekama informācija, kas palīdzētu lietotājam izprast konfliktiem. Konflikti parasti rodas PUT pieprasījumos. Piemēram, ja uz sūtīto PUT pieprasījumu, kas nosūta izmaiņas konkrētā resursā, ir pievienota versijas informācija, kas ir pretrunā ar iepriekšējiem pieprasījumiem; tad serverim jāatgriež 409 kļūda, informējot lietotāju, ka pieprasījums nav izpildāms. Šajā atbildē varētu iekļaut atšķiršanas numuru starp abām konfliktējošajām versijām, lai lietotājs varētu veikt korekcijas un atjaunot jauno versiju. |
| 410 |
Pieprasītais resurss serverī ir pilnīgi nepieejams, un nav zināmu pārsūtu adreses. Šādos gadījumos būtu jāuzskata, ka šī situācija ir pastāvīga. Ja iespējams, klientiem ar saites rediģēšanas funkciju vajadzētu pēc lietotāja apstiprināšanas izdzēst visus norādi uz šo adresi. Ja serveris nezina vai nevar pārliecināties, ka šī situācija ir pastāvīga, viņam būtu jāizmanto 404 statuss. Izņemot gadījumos, kad tā ir citādi norādīta, šī atbilde ir kešojama. 410 atbildes mērķis galvenokārt ir palīdzēt tīmekļa pārziņiem apkopot savu tīmekļa vietni, informējot lietotājus, ka resurss vairs nav pieejams un ka servera īpašnieki vēlas, lai visi attiecīgie ārējie savienojumi tiktu izdzēsti. Šādi pasākumi ir izplatīti ierobežotajās, pievienotajās, pakalpojumu pasākumos. 410 atbildes tiek izmantotas arī, lai informētu klientus par to, ka pašlaik serverī vairs nav pieejams, sākotnēji piederēja kādam personīgam resursam. Protams, atkarībā no servera īpašniekiem tiks noteikts, vai visus pastāvīgi nepieejamos resursus ir jāpazīme ar '410 Gone' un kāda perioda laikā ir jānotur šis rādītājs. |
| 411 |
Serveris atsakās pieņemt pieprasījumu bez definētā Content-Length galvēm. Pēc tam, kad ir atgriezta efektīva Content-Length galviene, klients var atkārtoti nosūtīt šo pieprasījumu. |
| 412 |
Serverim neizdevās izpildīt kādas priekšnoteikumu nosacījumus, ko noteikusi pieprasījuma galvenes. Šis statuss ļauj klientiem pieprasīt resursu, uzstādīt nosacījumus pieprasītās informācijas (pieprasījuma galvenes dati), lai izvairītos no pieprasījuma pielikšanas uz citu resursu. |
| 413 |
Serveris atsakās apstrādāt pašreizējo pieprasījumu, jo nosūtītā datu apjoma lielums pārsniedz serverī pieņemamo vai apstrādājamo robežu. Šādos gadījumos serveris var slēgt savienojumu, lai neatļautu klientam turpināt sūtīt šo pieprasījumu. Ja šī situācija ir pagaidu, serverī jāatgriež Retry-After atbildes galvene, lai paziņotu klientam, kad atkal var mēģināt. |
| 414 |
Pieprasītā URI garums pārsniedz garumu, ko serveris var interpretēt, tāpēc serveris atsakās veikt atbilstošu pieprasījumu. To parasti var atrast gadījumos, kad būtu bijusi jāsūta HTTP pieprasījuma POST metode, bet tas kļūst par GET pieprasījumu, radot pārāk ilgu vaicājuma virkni (Query String). URI "melnajā caurumā" ir iespējams noraidīt ar katru nākamo pāradresāciju, pievienojot veco URI kā jauno URI, radot pārmērīgu garumu. Klientis var mēģināt izmantot jebkuras servera drošības ievainojamības. Dažiem serveriem, kuriem nav šādu drošības ierobežojumu, var atgriezt 414 statusu. |
| 415 |
Attiecībā uz pašreizējā pieprasījuma metodi un pieprasīto resursu pieprasītais saturs nav serverī atbalstīts formātā, tāpēc pieprasījums ir noraidīts. |
| 416 |
Ja pieprasījums ietver Range pieprasījuma galveni, un jebkurš no attiecīgajiem datu diapazoniem nesakrīt ar pašreizējiem resursa pieejamajiem datiem, un pieprasījumā nav definēta If-Range pieprasījuma galvene, serverim jāatgriež 416 statusa kods. Ja Range izmanto baitiem, tad šajā gadījumā tas nozīmē, ka pieprasītais pirmais baitu pozīcijas pārsniedz pašreizējo resursa garumu. Serverim ir jānorāda 416 statusā un jāiekļauj Content-Range galvene, lai skaidri norādītu pašreizējo resursa garumu. Šai atbildei arī būtu aizliegts izmantot multipart/byteranges kā tās Content-Type. |
| 417 |
Pieprasījuma galvenē norādītā gaidāmā informācija nevar būt izpildīta serverī, vai arī šis serveris ir starpniekserveris, kas saskaras ar skaidru pierādījumu, ka nākamajā maršrutā gaidāmās saturu nevar izpildīt. |
| 421 |
Savienojumu skaits no pašreizējā klienta IP adreses uz serveri pārsniedz servera pieļauto maksimālo skaitu. Parasti šī IP adrese attiecībā uz serveri ir viedoklis par klienta adresi (piemēram, pārlūka vai starpniekservera adrese). Šajā gadījumā pieslēgumu skaitīšana var ietvert vairāk nekā vienu galīgu lietotāju. |
| 422 |
Pieprasījuma formāts ir pareizs, taču dēļ semantiskajām kļūdām nevar būt atbilde (RFC 4918 WebDAV). 423 Bloķēts pašreizējais resurss ir bloķēts (RFC 4918 WebDAV). |
| 424 |
Sakarā ar iepriekš izveidota pieprasījuma kļūdu pašreizējais pieprasījums neizdodas, piemēram, PROPPATCH (RFC 4918 WebDAV). |
| 425 |
Definēts WebDav Advanced Collections projektā, bet netika iekļauts "WebDAV secīgā kolekciju protokolā" (RFC 3658). |
| 426 |
Klientam jāveic pāreja uz TLS/1.0 (RFC 2817). |
| 449 |
Izveidoja Microsoft, kas nosaka, ka pieprasījumam ir jāveic atkārtoti pēc piemēru pabeigšanas. |
| 500 |
Serveris saskārās ar neparedzētu situāciju, kas liedza pabeigt pieprasījumu. Parasti šo problēmu izraisa servera programmas kļūda. |
| 501 |
Serveris atbalsta kādu funkciju, kas nepieciešama pašreizējam pieprasījumam. Kad serveris nespēj atzīt pieprasītā metodi un nevar atbalstīt to resursiem. |
| 502 |
Serveris, kas kalpo kā vārti vai starpnieks, mēģina izpildīt pieprasījumu, bet saņem nederīgu atbildi no augšējo serveriem. |
| 503 |
Pagaidu servera uzturēšanas vai pārslodzes dēļ serveris pašlaik nevar apstrādāt pieprasījumu. Šī situācija ir pagaidu, un drīz tiks atjaunota. Ja iespējams, atbildē var norādīt gaidīšanas laiku, izmantojot Retry-After galveni. Ja nav norādīta šī Retry-After informācija, klients to var apstrādāt kā 500 atbildi. Ņemiet vērā: 503 status ir pieejams, taču serveris var arī vēlēties atteikt klienta savienojumu. |
| 504 |
Serveris, kas kalpo kā vārti vai starpnieks mēģina veikt pieprasījumu, bet nevar saņemt atbildi no augstākā servera (URI norādīts serverī, piemēram, HTTP, FTP, LDAP) vai saderīga servera (piemēram, DNS). Ņemiet vērā: daži starpniekserveri var atgriezt 400 vai 500 kļūdas DNS jautājuma laikā. |
|
| 505 |
Serveris nav atbalsta un nepieņem pieprasījuma HTTP versiju, kas norādīta. Tas liecina par to, ka serveris nevēlas izmantot klienta izvēlēto versiju. Šai atbildei jāietver apraksts, kāpēc versija nav atbalstīta un kādas protokoli atbalsta serveris. |
| 506 |
Nosaka iekšēju konfigurācijas kļūdu servera dēļ (izveidots ar "Ca..." Protokolu (RFC 2295)), ka pieprasītā saskaņot resursa konfigurācija uz norādīto servera pielietojumu pārskaitījumiem, tādēļ nav piemērots uzdevums. |
| 507 |
Serveris nespēj saglabāt visus nepieciešamos datus, lai pabeigtu pieprasījumu. Šī situācija tiek uzskatīta par pagaidu. (WebDAV (RFC 4918)) |
| 509 |
Serveris sasniedzis joslas platuma ierobežojumu. Šis nav oficiāls statuss kods, bet tas tiek plaši izmantots. |
| 510 |
Politika, kas nepieciešama resursu saņemšanai, nav izpildīta (RFC 2774). |