Tiešsaistes rīki
Http statusa kodi Stāvokļa kods Nozīme
100 Klientam jāturpina sūtīt pieprasījumus. Šo pagaidu atbildi izmanto, lai informētu klientu, ka serveris ir saņēmis daļu tā pieprasījuma un nav noraidījis. Klientam jāturpina sūtīt atlikušo pieprasījuma daļu vai jāignorē šī atbilde, ja pieprasījums ir pabeigts. Kad pieprasījums ir pabeigts, serverim jānosūta klientam galīgā atbilde.
101 Serveris ir sapratis klienta pieprasījumu un, izmantojot Upgrade galveni, paziņos klientam, ka pieprasījuma pabeigšanai tika izmantots cits protokols. Pēc atbildes pēdējās tukšās rindas nosūtīšanas serveris pārslēgsies uz Upgrade galvenē definētajiem protokoliem. Tas jādara tikai tad, ja pāreja uz jauno protokolu ir izdevīgāka. Piemēram, pārslēgšanās uz jaunu HTTP versiju var būt izdevīgāka nekā uz vecāku versiju vai pārslēgšanās uz reāllaika sinhrono protokolu, lai piegādātu resursus, kas izmanto šādas funkcijas.
102 Statusa kodi, kas paplašināti ar WebDAV (RFC 2518), norāda, ka apstrāde tiks turpināta.
200 Pieprasījums ir bijis veiksmīgs, un kopā ar atbildi tiks nosūtītas pieprasījumā pieprasītās atbildes galvenes vai datu kopums.
201 Pieprasījums ir izpildīts, un, atbildot uz pieprasījumu, ir izveidots jauns resurss, un tā URI ir atgriezts kopā ar atrašanās vietas galveni. Ja pieprasīto resursu nav iespējams izveidot laikus, jāatgriež šāda informācija'202 Accepted'。
202 Serveris ir pieņēmis pieprasījumu, bet vēl nav to apstrādājis. Tāpat kā tas var tikt noraidīts, pieprasījums galu galā var tikt vai netikt izpildīts. Asinhrono darbību gadījumā nav nekā ērtāka par šī statusa koda nosūtīšanu. Atbilde 202 tiek atgriezta ar mērķi ļaut serverim pieņemt pieprasījumus no citiem procesiem (piemēram, sērijveida operācijas, kas tiek izpildītas tikai reizi dienā), klientam neuzturot savienojumu ar serveri, līdz sērijveida operācija tiek pabeigta. Atbildē, kas pieņem pieprasījumu apstrādei un atdod 202 statusa kodu, atpakaļ atdotajā vienībā jāiekļauj informācija, kas norāda procesa pašreizējo statusu, kā arī norāde uz apstrādes statusa monitoru vai statusa prognozi, lai lietotājs varētu novērtēt, vai darbība ir pabeigta.
203 Serveris ir sekmīgi apstrādājis pieprasījumu, bet atgrieztā entītijas galvenes metainformācija nav galīgais komplekts, kas derīgs sākotnējā serverī, bet gan kopija no vietējās vai trešās puses. Pašreizējā informācija var būt oriģināla apakškopa vai virskopums. Piemēram, metadati, kas satur resursus, var likt izcelsmes serverim zināt metainformācijas superinformāciju. Šī statusa koda izmantošana nav obligāta un ir piemērota tikai tad, ja atbilde bez tā būtu atgriezusi 200 OK.
204 Serveris veiksmīgi apstrādāja pieprasījumu, bet tam nav jāatgriež fizisks saturs, bet tas vēlas atgriezt atjauninātu metainformāciju. Atbilde var atgriezt jaunu vai atjauninātu metainformāciju vienību galvenes veidā. Ja šīs galvenes pastāv, tām jāatbilst pieprasītajiem mainīgajiem lielumiem. Ja klients ir pārlūkprogramma, lietotāja pārlūkprogrammai BŪT jāsaglabā lapa, no kuras tika nosūtīts pieprasījums, nemainot dokumenta skatījumu, lai gan jaunā vai atjauninātā metainformācija saskaņā ar specifikāciju BŪT jāpiemēro dokumentam lietotāja pārlūkprogrammas aktīvajā skatā. Tā kā 204. atbilde nedrīkst saturēt nekādu ziņojuma tekstu, tā vienmēr beidzas ar pirmo tukšo rindu pēc ziņojuma galvenes.
205 Serveris veiksmīgi apstrādā pieprasījumu un neko neatgriež. Tomēr atšķirībā no 204. atbildes atbilde, kas atgriež šo statusa kodu, pieprasa pieprasītājam atjaunot dokumenta skatījumu. Šo atbildi galvenokārt izmanto, lai atiestatītu veidlapu uzreiz pēc lietotāja ievades pieņemšanas, lai lietotājs varētu viegli sākt citu ievades darbību. Tāpat kā 204. atbildei, arī šai atbildei ir aizliegts ietvert jebkādu ziņojuma tekstu, un tā beidzas ar pirmo tukšo rindu pēc ziņojuma galvenes.
206 Serveris ir veiksmīgi apstrādājis daļu no GET pieprasījuma. HTTP lejupielādes rīki, piemēram, FlashGet vai Thunderbolt, izmanto šo atbildes veidu, lai veiktu periodisku lejupielādi vai sadalītu lielu failu vairākās lejupielādēs vienlaicīgi. Pieprasījumā jāietver Range galvene, lai norādītu satura diapazonu, ko klients vēlas saņemt, un kā pieprasījuma nosacījumu var ietvert If-Range. Atbildē jāietver šādi galvenes lauki: Content-Range, lai norādītu šajā atbildē atgrieztā satura darbības jomu, vai, ja tiek lejupielādētas vairākas daļas ar Content-Type of multipart/byteranges, katrā vairāku daļu segmentā jāietver Content-Range lauks, lai norādītu šajā segmentā esošā satura darbības jomu. Ja atbildē ir Content-Length, tā vērtībai ir jāatbilst patiesajam baitu skaitam atgrieztajā satura diapazonā. Expires, Cache-Control un/vai Vary, ja to vērtības var atšķirties no citu iepriekšējo atbilžu vērtībām ar tiem pašiem mainīgajiem. Šajā atbildē nedrīkst būt citu vienību galvenes, ja pieprasījumā izmantota spēcīga If-Range kešatmiņas validācija, un nedrīkst būt citu vienību galvenes, ja pieprasījumā izmantota vāja If-Range kešatmiņas validācija; tas ļauj izvairīties no neatbilstībām starp kešatmiņā saglabātā vienības satura un atjauninātās vienības galvenes informācijas. Pretējā gadījumā šajā atbildē BŪTENS jāietver visi entītijas galvenes lauki, kas būtu jāatgriež 200 atbildē. Ja ETag vai Last-Modified galvenes precīzi nesakrīt, klienta puses kešatmiņai jāaizliedz 206. atbildē atdotā satura apvienošana ar iepriekš kešatmiņā saglabātu saturu. Jebkurai kešatmiņai, kas neatbalsta Range un Content-Range galvenes, ir aizliegts kešēt saturu, kas atgriezts ar 206. atbildi.
207 WebDAV paplašinātie statusa kodi(RFC 2518) WebDAV paplašinātais statusa kods nozīmē, ka nākamā ziņojuma ķermenis būs XML ziņojums un var saturēt virkni atsevišķu atbildes kodu atkarībā no iepriekšējo pakārtoto pieprasījumu skaita.
300 Pieprasītajam resursam ir virkne alternatīvu atbilžu, no kurām katrai ir sava īpaša adrese un pārlūkprogrammas vadīta pārrunu informācija. Lietotājam vai pārlūkprogrammai ir jāizvēlas vēlamā pāradresācijas adrese. Ja vien šis nav HEAD pieprasījums, atbildē jāiekļauj vienība, kas ir resursu raksturlielumu un adrešu saraksts, no kura lietotājs vai pārlūkprogramma var izvēlēties piemērotāko pāradresēšanas adresi. Šīs vienības formātu nosaka Content-Type definīcijas formāts. Pārlūkprogramma var automātiski veikt vispiemērotāko izvēli, pamatojoties uz atbildes formātu un pārlūkprogrammas iespējām. Protams, RFC 2616 specifikācijā nav norādīts, kā jāveic šī automātiskā atlase. Ja pats serveris jau ir izvēlējies vēlamo atgriešanas iespēju, atgriešanas URI jānorāda atrašanās vietā; pārlūkprogrammas var izmantot šo atrašanās vietas vērtību kā adresi automātiskai pāradresācijai. Turklāt atbilde ir kešējama, ja vien nav norādīts citādi.
301 Pieprasītais resurss ir neatgriezeniski pārvietots uz jauno atrašanās vietu, un turpmākajās atsaucēs uz to jāizmanto viens no vairākiem URI, kas atgriezti šajā atbildē. Ja iespējams, klientiem ar saites rediģēšanas iespējām automātiski jāmaina pieprasītā adrese uz servera atdoto adresi. Šo atbildi var arī kešēt, ja vien nav norādīts citādi. Jaunais pastāvīgais URI jāatgriež atbildes laukā Location. Ja vien šis nav HEAD pieprasījums, atbildes vienībā jāietver hipersaite uz jauno URI un īss apraksts. Ja tas nav GET vai HEAD pieprasījums, pārlūkprogrammai ir aizliegts automātiski novirzīt, ja vien lietotājs to nav apstiprinājis, jo tā rezultātā var mainīties pieprasījuma nosacījumi. Piezīme: Dažām pārlūkprogrammām, kas izmanto HTTP/1.0 protokolu, nosūtot POST pieprasījumu un saņemot 301 atbildi, nākamais pāradresēšanas pieprasījums būs GET.
302 Pieprasītais resurss tagad uz laiku atbild uz pieprasījumu no cita URI. Tā kā šī pāradresācija ir īslaicīga, klientam arī turpmāk pieprasījumi jāsūta uz sākotnējo adresi. Atbilde ir kešējama tikai tad, ja ir norādīts Cache-Control vai Expires. Atbildes laukā Location jāatgriež jaunais pagaidu URI. Ja vien šis nav HEAD pieprasījums, atbildes vienībā jāietver hipersaite uz jauno URI un īss apraksts. Ja tas nav GET vai HEAD pieprasījums, pārlūkprogrammai ir aizliegts automātiski veikt pāradresēšanu, ja vien to neapstiprina lietotājs, jo tā rezultātā var mainīties pieprasījuma nosacījumi. Piezīme: Lai gan RFC 1945 un RFC 2068 specifikācijas neļauj klientam mainīt pieprasījuma metodi novirzīšanas laikā, daudzas esošās pārlūkprogrammas 302 atbildi uzskata par 303 atbildi un izmanto GET, lai piekļūtu atrašanās vietā norādītajam URI, ignorējot sākotnējā pieprasījuma metodi. Ir pievienoti 303. un 307. statusa kodi, lai precizētu, kādu atbildi serveris sagaida no klienta.
303 Atbilde uz pašreizējo pieprasījumu ir atrodama citā URI, un klientam jāpieiet šim resursam, izmantojot GET. Šī metode galvenokārt pastāv, lai ļautu ar skriptu aktivizētu POST pieprasījumu izvades rezultātus novirzīt uz jaunu resursu. Šis jaunais URI nav sākotnējā resursa aizstājēja atsauce. Turklāt 303 atbildi nav atļauts kešēt. Protams, otro pieprasījumu (pāradresāciju) var kešēt. Jaunais URI jāatgriež atbildes laukā Location (atrašanās vieta). Ja vien tas nav HEAD pieprasījums, atbildes vienībā jāietver hipersaite uz jauno URI un īss apraksts. Piezīme: Daudzas pārlūkprogrammas pirms HTTP/1.1 versijas pareizi nesaprot 303 stāvokli. Ja ir jāapsver mijiedarbība ar šīm pārlūkprogrammām, 302 statusa kodam vajadzētu darboties, jo vairums pārlūkprogrammu apstrādā 302 atbildi tieši tā, kā iepriekš minētajā specifikācijā noteikts, ka klientam jāapstrādā 303 atbilde.
304 Šis statusa kods serverim jāatgriež, ja klients nosūta nosacītu GET pieprasījumu un pieprasījums ir atļauts, un dokumenta saturs nav mainījies (vai nu kopš pēdējā apmeklējuma, vai atbilstoši pieprasījuma nosacījumiem). 304 atbildei ir aizliegts ietvert ziņojuma ķermeni, tāpēc tā vienmēr beidzas ar pirmo tukšo rindu pēc ziņojuma galvenes. Atbildē jāietver šāda galvenes informācija: Datums, ja vien serverim nav pulksteņa. Ja serveris bez pulksteņa ievēro šos noteikumus, tad starpniekserveris un klients var paši pievienot Date lauku ienākošās atbildes galvenei (kā norādīts RFC 2068), un kešēšanas mehānisms darbosies pareizi. ETag un/vai Content-Location, ja tas pats pieprasījums būtu atbildējis ar 200 atbildi. Expires, Cache-Control un/vai Vary, ja to vērtības var atšķirties no citu iepriekšējo atbilžu vērtībām ar tiem pašiem mainīgajiem. Ja atbildes pieprasījumā tiek izmantota spēcīga kešatmiņas validācija, tad atbildē nedrīkst būt papildu entītijas galvenes; pretējā gadījumā (piemēram, nosacītā GET pieprasījumā tiek izmantota vāja kešatmiņas validācija) atbildē aizliegts iekļaut papildu entītijas galvenes; tādējādi tiek novērsta neatbilstība starp kešatmiņā saglabāto entītijas saturu un atjaunināto entītijas galvenes informāciju. Ja 304 atbilde norāda, ka vienība pašlaik nav kešatmiņā, kešēšanas sistēmai atbilde jāignorē un pieprasījums jāatkārto bez ierobežojuma. Ja tiek saņemta 304 atbilde, kurā pieprasīts atjaunināt kešatmiņas ierakstu, kešēšanas sistēmai JĀatjaunina viss ieraksts, lai atspoguļotu visu atbildē atjaunināto lauku vērtības.
305 Pieprasītajam resursam jāpieiet, izmantojot norādīto starpniekserveri. Lauks Location (Atrašanās vieta) sniegs informāciju par norādītā starpniekservera URI, un saņēmējam būs atkārtoti jānosūta atsevišķs pieprasījums, lai piekļūtu resursam, izmantojot šo starpnieku. Tikai sākotnējais serveris var izveidot 305 atbildi. Piezīme. No RFC 2068 nav skaidrs, ka 305 atbilde ir paredzēta viena pieprasījuma novirzīšanai un to var izveidot tikai izcelsmes serveris. Šo ierobežojumu neievērošana var radīt nopietnas drošības sekas.
306 Jaunākajā specifikācijas versijā 306 statusa kods vairs netiek izmantots.
307 Pieprasītie resursi tagad uz laiku atbild uz pieprasījumiem no dažādiem URI. Tā kā šī pāradresācija ir īslaicīga, klientiem arī turpmāk pieprasījumi jāsūta uz sākotnējo adresi. Šī atbilde ir kešējama tikai tad, ja ir norādīts Cache-Control vai Expires. Atbildes laukā Location jāatgriež jaunais pagaidu URI. Ja vien šis nav HEAD pieprasījums, atbildes vienībā jāietver hipersaite uz jauno URI un īss apraksts. Tā kā dažas pārlūkprogrammas neatpazīst 307 atbildi, ir nepieciešams pievienot iepriekš minēto informāciju, lai lietotājs varētu saprast un pieprasīt piekļuvi jaunajam URI. Ja tas nav GET vai HEAD pieprasījums, pārlūkprogramma aizliedz automātisku pāradresāciju, ja vien to neapstiprina lietotājs, jo pieprasījuma nosacījumi var mainīties.
400 1, semantiska kļūda, serveris nesaprot pašreizējo pieprasījumu. Ja vien tas nav mainīts, klientam nevajadzētu atkārtot pieprasījumu. 2, pieprasījuma parametri ir nepareizi.
401 Pašreizējam pieprasījumam nepieciešama lietotāja autentifikācija. Atbildē jāietver pieprasītā resursa WWW-Authenticate galvene, lai pieprasītu lietotāja informāciju. Klients var atkārtoti nosūtīt pieprasījumu ar atbilstošu Autorizācijas galvenes informāciju. Ja pašreizējais pieprasījums jau satur Autorizācijas akreditācijas datus, tad 401 atbilde nozīmē, ka serveris pārbauda, vai šie akreditācijas dati ir noraidīti. Ja 401. atbilde satur tādu pašu autentifikācijas pieprasījumu kā iepriekšējā atbilde un pārlūkprogramma jau ir veikusi vismaz vienu autentifikācijas mēģinājumu, tad pārlūkprogrammai ir jāparāda lietotājam atbildē ietvertā informācija par vienību, jo šī informācija par vienību var saturēt attiecīgu diagnostikas informāciju. Skatīt RFC 2617.
402 Šis statusa kods ir rezervēts iespējamām nākotnes prasībām.
403 Serveris ir sapratis pieprasījumu, bet atsakās to izpildīt. Atšķirībā no 401 atbildes autentifikācija nesniedz nekādu palīdzību, un pieprasījumu nevajadzētu nosūtīt atkārtoti. Ja šis nav HEAD pieprasījums un serveris vēlas, lai varētu pateikt, kāpēc pieprasījumu nevar izpildīt, tad atteikuma iemesls jāapraksta vienībā. Protams, serveris var arī atgriezt 404 atbildi, ja tas nevēlas, lai klients saņemtu jebkādu informāciju.
404 Pieprasījums neizdevās, pieprasītais resurss serverī nav atrasts. Lietotājam nav informācijas, kas norādītu, vai situācija ir īslaicīga vai pastāvīga. Ja serveris zina par šo situāciju, tam jāizmanto 410 statusa kods, lai informētu serveri, ka vecais resurss ir pastāvīgi nepieejams kāda iekšējās konfigurācijas mehānisma dēļ un ka nav pieejama pāradresācija. 404 plaši izmanto, ja serveris nevēlas atklāt, kāpēc pieprasījums tika noraidīts, vai ja nav pieejama cita piemērota atbilde.
405 Pieprasījuma rindā norādīto pieprasījuma metodi nevar izmantot, lai pieprasītu attiecīgo resursu. Atbildē jāatgriež Allow galvene, kurā norādīts to pieprasījuma metožu saraksts, kas ir pieņemamas attiecīgajam resursam. Tā kā PUT un DELETE metodes ieraksta resursā serverī, lielākā daļa tīmekļa serveru pēc noklusējuma tās neatbalsta vai neatļauj un šādu pieprasījumu gadījumā atgriež 405 kļūdu.
406 Pieprasītā resursa satura raksturlielumi neatbilst pieprasījuma galvenes nosacījumiem, un atbildes vienību nevar ģenerēt. Ja vien šis nav HEAD pieprasījums, atbildei jāatgriež vienība, kas satur vispiemērotākās vienības raksturlielumus un adrešu sarakstu, no kura lietotājs vai pārlūkprogramma var izvēlēties. Entitātes formātu nosaka medija tips, kas definēts Content-Type galvenē. Pārlūkprogramma var izdarīt vislabāko izvēli, pamatojoties uz formātu un savām iespējām. Tomēr specifikācijā nav definēti nekādi kritēriji šādas automātiskas izvēles veikšanai.
407 Līdzīgi 401 atbildei, izņemot to, ka klientam ir jāveic autentifikācija ar starpniekserveri. Proxy serverim ir jāatgriež Proxy-Authenticate identitātes pieprasīšanai. Klients var atgriezt Proxy-Authorisation galveni autentifikācijai. Skatīt RFC 2617.
408 Pieprasījuma laika ierobežojums. Klients nav pabeidzis pieprasījumu laikā, ko serveris bija gatavs gaidīt. Klients jebkurā laikā var atkārtoti nosūtīt pieprasījumu, neveicot nekādas izmaiņas.
409 Pieprasījumu nevarēja izpildīt konflikta dēļ ar pieprasītā resursa pašreizējo stāvokli. Šo kodu atļauts izmantot tikai tad, ja lietotājs uzskata, ka var atrisināt konfliktu un atkārtoti iesniegt jaunu pieprasījumu. Atbildē jāietver pietiekami daudz informācijas, lai lietotājs varētu atklāt konflikta avotu. Konflikti bieži rodas, apstrādājot PUT pieprasījumus. Piemēram, versiju pārbaudes vidē PUT pieprasījumam, kas iesniegts, lai modificētu konkrētu resursu ar versijas informāciju, kura ir pretrunā ar iepriekšējo (trešās puses) pieprasījumu, jāatgriež 409 kļūda, informējot lietotāju, ka pieprasījumu nav iespējams izpildīt. Šādā gadījumā atbildes vienība, visticamāk, saturēs abu konfliktējošo versiju atšķirību salīdzinājumu, lai lietotājs varētu atkārtoti iesniegt jauno, apvienoto versiju.
410 Pieprasītais resurss vairs nav pieejams serverī, un nav zināma pārsūtīšanas adrese. Šāda situācija jāuzskata par pastāvīgu. Ja iespējams, klientiem ar saites rediģēšanas iespējām ar lietotāja atļauju jādzēš visas atsauces uz šo adresi. Ja serveris nezina vai nevar noteikt, vai stāvoklis ir pastāvīgs, tad jāizmanto 404 statusa kods. Ja nav norādīts citādi, šī atbilde ir kešējama. 410 atbildes mērķis galvenokārt ir palīdzēt tīmekļa administratoram uzturēt vietni, informējot lietotāju, ka resurss vairs nav pieejams un ka servera īpašnieks vēlas, lai tiktu dzēsti arī visi attālinātie savienojumi ar resursu. Šāda veida notikums ir izplatīts laika ierobežojuma pakalpojumos ar pievienoto vērtību. Līdzīgi 410 atbilde tiek izmantota, lai paziņotu klientam, ka resurss, kas pieder kādai personai, pašreizējā servera vietnē vairs nav pieejams. Protams, svarīgs ir arī jautājums par to, vai visi pastāvīgi nepieejamie resursi ir jāmarķē kā tādi un cik ilgi tie šādi jāglabā.'410 Gone'， un cik ilgi tas būtu jāuztur, ir atkarīgs tikai no servera īpašnieka.
411 Serveris atsakās pieņemt pieprasījumus bez definētas Content-Length galvenes. Klients var atkārtoti nosūtīt pieprasījumu pēc tam, kad ir pievienota derīga Content-Length galvene, kurā norādīts pieprasījuma ziņojuma ķermeņa garums.
412 Serveris, pārbaudot pieprasījumu, nav izpildījis vienu vai vairākus pieprasījuma galvenes laukā norādītos priekšnoteikumus. Šis statusa kods ļauj klientam noteikt priekšnosacījumus pieprasījuma metainformācijā (pieprasījuma galvenes lauka dati), iegūstot resursu, tādējādi novēršot pieprasījuma metodes piemērošanu citiem resursiem, nevis vēlamajam saturam.
413 Serveris atsakās apstrādāt pašreizējo pieprasījumu, jo tajā ir iesniegts vairāk fizisko datu, nekā serveris vēlas vai spēj apstrādāt. Šādā gadījumā serveris var slēgt savienojumu, lai neļautu klientam turpināt sūtīt pieprasījumu. Ja situācija ir īslaicīga, serverim jāatgriež Retry-After galvene, lai informētu klientu, cik daudz laika tam ir nepieciešams atkārtot pieprasījumu.
414 Pieprasījuma URI ir garāks, nekā serveris spēj interpretēt, tāpēc serveris atsakās apstrādāt pieprasījumu. Tas notiek reti, un parasti tas notiek tad, kad veidlapas iesniegšana, kurai bija jāizmanto POST metode, kļūst par GET metodi, kā rezultātā veidojas gara vaicājuma virkne. Pārvirzīšanas URI "melnie caurumi", piemēram, vecā URI izmantošana kā daļa no jaunā URI katram pāradresējumam, kā rezultātā pēc vairākiem pāradresējumiem veidojas garš URI. Klienti mēģina uzbrukt serveriem, izmantojot dažos serveros esošās drošības nepilnības. Šādi serveri pieprasītā URI nolasīšanai vai manipulēšanai ar to izmanto fiksēta garuma buferi, kas var izraisīt bufera pārpildi, ja GET parametrs pārsniedz noteiktu vērtību, kā rezultātā var tikt izpildīts patvaļīgs kods.[1]。 Serveriem bez šādām ievainojamībām jāatgriež 414 statusa kods.
415 Pašlaik pieprasītajai metodei un pieprasītajam resursam pieprasījumā iesniegtā vienība nav servera atbalstītajā formātā, un pieprasījums tiek noraidīts.
416 Ja pieprasījumā ir Range pieprasījuma galvene un visi Range norādītie datu diapazoni nesakrīt ar pašreizējam resursam pieejamajiem diapazoniem, un pieprasījumā nav definēta If-Range pieprasījuma galvene, tad serverim jāatgriež 416 statusa kods. Ja Range izmanto baitu diapazonus, tas nozīmē, ka visu pieprasījumā norādīto datu diapazonu pirmais baits pārsniedz pašreizējā resursa garumu. Serverim kopā ar 416 statusa kodu jāiekļauj arī Content-Range vienības galvene, kurā norādīts pašreizējā resursa garums. Šajā atbildē kā Content-Type aizliegts izmantot arī multipart/byteranges.
417 Pieprasījuma galvenē Expect norādīto gaidāmo saturu serveris nevar izpildīt vai arī serveris ir starpniekserveris, kam ir skaidri pierādījumi, ka Expect saturu nevar izpildīt nākamajā pašreizējā maršruta mezglā.
421 Savienojumu skaits ar serveri no pašreizējā klienta IP adreses pārsniedz servera atļauto maksimālo skaitu. Parasti IP adrese šeit attiecas uz klienta adresi, kas redzama no servera (piemēram, lietotāja vārteja vai proxy servera adrese). Šajā gadījumā savienojumu skaitā var būt iesaistīts vairāk nekā viens galalietotājs.
422 Savienojumu skaits no pašreizējā klienta IP adreses uz serveri pārsniedz servera atļauto maksimālo skaitu. Parasti IP adrese šeit attiecas uz klienta adresi, kas redzama no servera (piemēram, lietotāja vārteja vai starpniekserveru adrese). Šajā gadījumā savienojumu skaitā var būt iesaistīts vairāk nekā viens galalietotājs.
422 Pieprasījums tika formatēts pareizi, bet uz to nevarēja atbildēt, jo tajā bija semantiskas kļūdas. (RFC 4918 WebDAV) 423 Bloķēts Pašreizējais resurss ir bloķēts. (RFC 4918 WebDAV) 423 Bloķēts
424 Pašreizējais pieprasījums neizdevās iepriekšējā pieprasījumā, piemēram, PROPPATCH, kļūdas dēļ. (RFC 4918 WebDAV)
425 Definēts WebDav Advanced Collections projektā, bet nav iekļauts WebDAV secīgo kolekciju protokolā (RFC 3658).
426 Klientiem jāpāriet uz TLS/1.0. (RFC 2817).
449 Microsoft paplašināts, lai norādītu, ka pieprasījumi būtu jāizmēģina atkārtoti pēc attiecīgas darbības veikšanas.
500 Serveris saskārās ar neparedzētiem apstākļiem, kas neļāva pabeigt pieprasījuma apstrādi. Parasti šāda problēma rodas, ja servera programmas kodā ir kļūda.
501 Serveris neatbalsta funkciju, kas nepieciešama pašreizējam pieprasījumam. Ja serveris neatpazīst pieprasīto metodi un nevar atbalstīt tās pieprasījumu attiecībā uz kādu resursu.
502 Serveris, kas darbojas kā vārtejas vai starpniekserveris, saņem nederīgu atbildi no augšupējā servera, kad tas mēģina izpildīt pieprasījumu.
503 Serveris pašlaik nespēj apstrādāt pieprasījumu servera īslaicīgas uzturēšanas vai pārslodzes dēļ. Šis stāvoklis ir īslaicīgs un pēc kāda laika tiks atjaunots. Ja ir sagaidāma aizkavēšanās, atbildē var iekļaut Retry-After galveni, lai norādītu aizkavēšanos. Ja šī Retry-After informācija nav norādīta, klientam ar to jārīkojas tāpat kā ar 500 atbildi. Piezīme. 503 statusa koda esamība nenozīmē, ka serverim tas ir jāizmanto, ja tas ir pārslogots. Daži serveri vienkārši vēlas liegt klientam izveidot savienojumu.
504 Serveris, kas darbojas kā vārteja vai starpniekserveris un mēģina izpildīt pieprasījumu, nesaņem savlaicīgu atbildi no augšupēja servera (servera, kas identificēts ar URI, piemēram, HTTP, FTP, LDAP) vai sekundārā servera (piemēram, DNS). Piezīme: daži starpniekserveri atgriež 400 vai 500 kļūdu, kad DNS meklēšana beidzas.
505 Serveris neatbalsta vai atsakās atbalstīt pieprasījumā izmantoto HTTP versiju. Tas nozīmē, ka serveris nespēj vai nevēlas izmantot to pašu versiju, ko klients. Atbildē jāietver vienība, kurā aprakstīts, kāpēc versija netiek atbalstīta un kādus protokolus serveris atbalsta.
506 Paplašināts ar Pārredzamu satura pārrunu protokolu (RFC 2295), lai atspoguļotu servera iekšējo nepareizu konfigurāciju: pieprasītais pārrunu varianta resurss ir konfigurēts tā, lai pats sevi izmantotu pārredzamās satura pārrunās, un tāpēc nav piemērots pārrunu procesa mērķis.
507 Serveris nespēj saglabāt pieprasījumu izpildei nepieciešamo saturu. Šis nosacījums tiek uzskatīts par īslaicīgu.WebDAV(RFC 4918)
509 Serveris ir sasniedzis joslas platuma ierobežojumu. Tas nav oficiāls statusa kods, bet to joprojām plaši izmanto.
510 Nav izpildīta resursa iegūšanai nepieciešamā politika. (RFC 2774)
Piekļuve dokumentiem: