| Http statusa kods | Statusa 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 ar Upgrade ziņojuma galvenes starpniecību paziņos klientam, lai tas pieprasījuma pabeigšanai izmantotu citu protokolu. Pēc šīs atbildes pēdējās tukšās rindas nosūtīšanas serveris pārslēgsies uz tiem protokoliem, kas definēti Upgrade ziņojuma galvenē. Tas jādara tikai tad, ja ir izdevīgāk pārslēgties uz jaunu protokolu. Piemēram, pāreja uz jaunu HTTP versiju ir izdevīgāka nekā uz vecāku versiju vai pāreja uz reāllaika un 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 šo atbildi tiks nosūtīta pieprasījumā pieprasītā atbildes galvene vai datu kopums. |
| 201 | Pieprasījums ir izpildīts, un ir izveidots jauns resurss, kā prasīts pieprasījumā, un tā URI ir atgriezts kopā ar atrašanās vietas galveni. Ja pieprasīto resursu nav iespējams izveidot laikus, jāatgriež "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, galu galā pieprasījums var tikt vai netikt izpildīts. Asinhrono darbību kontekstā nav nekā ērtāka par šī statusa koda nosūtīšanu. Atbilde ar 202 statusa kodu tiek atgriezta ar mērķi ļaut serverim pieņemt pieprasījumus no citiem procesiem (piemēram, sērijveida operāciju, kas tiek izpildīta tikai reizi dienā), klientam neturēt savienojumu ar serveri, līdz sērijveida operācija ir pilnībā pabeigta. Atbildē, kas pieņem pieprasījumu apstrādei un atgriež 202 statusa kodu, atgrieztajā vienībā JĀIEKĻAUJAS iekļaut informāciju, kas norāda procesa pašreizējo stāvokli, kā arī norādi 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ālās versijas apakškopa vai virskopums. Piemēram, metadati, kas satur resursus, var izraisīt to, ka sākotnējam serverim ir zināma metainformācijas superinformācija. Šī 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 un tas vēlas atgriezt atjauninātu metainformāciju. Atbilde var atgriezt jaunu vai atjauninātu metainformāciju būtnes galvenes veidā. Ja šādas galvenes pastāv, tām jāatbilst pieprasītajiem mainīgajiem. Ja klients ir pārlūkprogramma, tad lietotāja pārlūkprogrammai BŪT jāsaglabā lapa, uz kuru tika nosūtīts pieprasījums, nemainot dokumenta skatījumu, lai gan saskaņā ar specifikāciju jaunā vai atjauninātā metainformācija 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āja pieprasījumu un neatdeva neko. Tomēr atšķirībā no 204. atbildes atbilde, kas atgriež šo statusa kodu, pieprasa pieprasītājam atjaunot dokumenta skatījumu. Šī atbilde galvenokārt tiek izmantota, 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 dokumentu vairākos lejupielādes segmentos 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; vairāku segmentu lejupielādes gadījumā ar Content-Type of multipart/byteranges katram vairāku daļu segmentam jāietver Content-Range lauks, kas norāda attiecīgā segmenta satura darbības jomu. Ja atbildē ir Content-Length, tā vērtībai jāatbilst patiesajam baitu skaitam satura diapazonā, ko tā atgriež. datums ETag un/vai Content-Location, ja tas pats pieprasījums būtu atbildējis ar 200. Expires, Cache-Control un/vai Vary, ja to vērtības var atšķirties no citām atbildēm ar tiem pašiem mainīgajiem. 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ē NAV jāietver citas būtnes galvenes, ja pieprasījumā tiek izmantota If-Range spēcīga kešatmiņas validācija, un NAV jāietver citas būtnes galvenes, ja pieprasījumā tiek izmantota If-Range vāja kešatmiņas validācija; tādējādi tiek novērstas neatbilstības starp kešatmiņā saglabāto būtnes saturu un atjaunināto būtnes galvenes informāciju. Pretējā gadījumā šajā atbildē BŪTENS jāietver visi entītijas galvenes lauki, kurus vajadzēja saņemt visās 200 atbildēs, kuras vajadzēja saņemt. Ja ETag vai Last-Modified galvenes precīzi nesakrīt, klienta puses kešatmiņā BŪTENS aizliedz 206. atbildē atdoto saturu apvienot ar jebkuru 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 (RFC 2518) 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 atbildes ziņojumu, katram no tiem ir sava īpaša adrese un pārlūkprogrammas vadīta pārrunu informācija. Lietotājs vai pārlūkprogramma var pats izvēlēties vēlamo adresi novirzīšanai. 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 vispiemē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 šāda automātiska izvēle. Ja pats serveris jau ir izvēlējies vēlamo atgrieztās atbildes variantu, tad šīs atbildes URI jānorāda atrašanās vietā; pārlūkprogramma var izmantot šo atrašanās vietas vērtību kā adresi automātiskai pāradresācijai. Turklāt šī atbilde ir arī 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 veikt pāradresēšanu, ja vien to neapstiprina lietotājs, 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ācijās nav atļauts klientam mainīt pieprasījuma metodi pēc novirzīšanas, 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 | Atbildi uz pašreizējo pieprasījumu var atrast 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 alternatīva atsauce uz sākotnējo resursu. Turklāt 303 atbildi ir aizliegts 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 pienācīgi nesaprot 303 stāvokli. Ja ir jāapsver mijiedarbība ar šīm pārlūkprogrammām, jāizmanto 302 statusa kods, jo lielākā daļa pārlūkprogrammu apstrādā 302 atbildi tieši tāpat, kā iepriekšminētajā specifikācijā klientam ir jāapstrādā 303 atbilde. |
| 304 | Serverim BŪT jāatgriež šis statusa kods, ja klients nosūta nosacītu GET pieprasījumu, kas ir atļauts, un dokumenta saturs (kopš pēdējā apmeklējuma vai saskaņā ar pieprasījuma nosacījumiem) nav mainījies. 304 Atbildes nedrīkst saturēt ziņojuma ķermeni, tāpēc tās vienmēr beidzas ar pirmo tukšo rindu pēc ziņojuma galvenes. Atbildē JĀIEVIENO ietvert šādas galvenes: 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. Expires, Cache-Control un/vai Vary, ja vērtība var atšķirties no vērtības, kas atbilst citām iepriekšējām atbildēm attiecībā uz to pašu mainīgo. Ja šajā atbildes pieprasījumā tiek izmantota spēcīga kešatmiņas validācija, tad šajā atbildē nedrīkst būt citu vienību galvenes; pretējā gadījumā (piemēram, nosacītā GET pieprasījumā tiek izmantota vāja kešatmiņas validācija) šajā atbildē nedrīkst būt citu vienību galvenes; tādējādi tiek novērsta neatbilstība starp kešatmiņā glabātu vienības saturu un atjauninātu vienības 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. laukā Atrašanās vieta tiks sniegta informācija par URI, kurā atrodas norādītais starpniekserveris. saņēmējam būtu 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 pāradresēšanai un to var izveidot tikai sākotnējais 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ītais resurss tagad uz laiku atbild uz pieprasījumu no cita URI. Tā kā šādi pāradresējumi ir īslaicīgi, klientiem jāturpina sūtīt turpmākos pieprasījumus 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, iepriekš minētā informācija jāpievieno, 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. Ir semantiska kļūda, un serveris nesaprot pašreizējo pieprasījumu. Ja vien tas nav mainīts, klientam nevajadzētu atkārtoti iesniegt šo pieprasījumu. 2. Pieprasījuma parametri ir nepareizi. |
| 401 | Pašreizējam pieprasījumam ir 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 iesniegt pieprasījumu, kas satur 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. atbildē ir tas pats autentifikācijas pieprasījums, kas iepriekšējā atbildē, un pārlūkprogramma jau vismaz vienu reizi ir mēģinājusi veikt autentifikāciju, tad pārlūkprogramma PIENĀCĪGI sniedz lietotājam atbildē ietverto informāciju par entītiju, jo šī informācija par entītiju 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 šo pieprasījumu nevajadzētu nosūtīt atkārtoti. Ja tas nav HEAD pieprasījums un serveris vēlas, lai varētu skaidri 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 sniegt klientam nekādu informāciju. |
| 404 | Pieprasījums neizdevās, pieprasītais resurss serverī nav atrasts. Nav informācijas, kas lietotājam norādītu, vai situācija ir īslaicīga vai pastāvīga. Ja serverim ir zināma situācija, tam jāizmanto 410 statusa kods, lai informētu lietotāju, ka vecais resurss ir pastāvīgi nepieejams kāda iekšējās konfigurācijas mehānisma dēļ un ka nav pieejams novirzīšanas veids. 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. Ņemot vērā, ka PUT un DELETE metodes ieraksta resursā serverī, vairums tīmekļa serveru neatbalsta šīs pieprasījuma metodes vai pēc noklusējuma tās neatļauj, un šādu pieprasījumu gadījumā tiek atgriezta 405 kļūda. |
| 406 | Pieprasītā resursa satura raksturlielumi neatbilst pieprasījuma galvenes nosacījumiem, un atbildes vienību nevar izveidot. Ja vien šis nav HEAD pieprasījums, atbildei jāatgriež vienība, kas satur vienību īpašību un adrešu sarakstu, no kura lietotājs vai pārlūkprogramma var izvēlēties piemērotāko. Entitātes formātu nosaka multivides tips, kas definēts Content-Type galvenē. Pārlūkprogrammas var veikt savu labā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 JĀautentificējas starpniekserverī. Starpniekserverim ir jāatgriež Proxy-Authenticate identitātes pieprasīšanai. Klients VAR atdot Proxy-Authorization galveni autentifikācijai. Skatīt RFC 2617. |
| 408 | Pieprasījuma laika ierobežojums. Klients nav pabeidzis sūtīt 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 pabeigt 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 nosūtīt jaunu pieprasījumu. Atbildē jāietver pietiekami daudz informācijas, lai lietotājs varētu atklāt konflikta avotu. Konflikti parasti rodas, apstrādājot PUT pieprasījumus. Piemēram, versiju pārbaudes vidē, ja PUT pieprasījumam, kas iesniegts, lai modificētu konkrētu resursu, pievienotā informācija par versiju ir pretrunā ar iepriekšējo (trešās puses) pieprasījumu, serverim jāatgriež 409 kļūda, informējot lietotāju, ka pieprasījumu nevar izpildīt. Šādā gadījumā atbildes vienībā, visticamāk, tiks sniegts abu konfliktējošo versiju atšķirību salīdzinājums, lai lietotājs pēc apvienošanas varētu atkārtoti iesniegt jauno versiju. |
| 410 | Pieprasītais resurss vairs nav pieejams serverī, un nav zināma neviena pārsūtīšanas adrese. Šāds stāvoklis 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 šis nosacījums ir pastāvīgs, tad jāizmanto 404 statusa kods. Ja vien nav norādīts citādi, šī atbilde ir kešējama. 410 Atbildes mērķis galvenokārt ir palīdzēt tīmekļa pārzinim 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 šo 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 klientiem, ka resurss, kas sākotnēji piederēja kādai personai pašreizējā servera vietnē, vairs nav pieejams. Protams, tas, vai visi pastāvīgi nepieejamie resursi ir jāmarķē kā "410 Gone" un cik ilgi šis marķējums ir jāuztur, ir tikai servera īpašnieka ziņā. |
| 411 | Serveris atsakās pieņemt pieprasījumus bez definētas Content-Length galvenes. Pēc derīgas Content-Length galvenes pievienošanas, kas norāda pieprasījuma ziņojuma ķermeņa garumu, klients var atkārtoti iesniegt pieprasījumu. |
| 412 | Serveris nav izpildījis vienu vai vairākus priekšnosacījumus, pārbaudot, vai tie ir norādīti pieprasījuma galvenes laukā. Šis statusa kods ļauj klientam, iegūstot resursu, iestatīt priekšnosacījumus pieprasījuma metaziņojumā (pieprasījuma galvenes lauka dati), tādējādi novēršot pieprasījuma metodes piemērošanu citiem resursiem, nevis tā vēlamajam saturam. |
| 413 | Serveris atsakās apstrādāt pašreizējo pieprasījumu, jo tajā ir iesniegti būtnes dati, kuru lielums ir lielāks, 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 šo pieprasījumu. Ja šis nosacījums ir īslaicīgs, serverim jāatgriež atbildes galvene Retry-After, lai informētu klientu, pēc cik ilga laika tas var atkārtot pieprasījumu. |
| 414 | Pieprasījuma URI garums pārsniedz garumu, ko var interpretēt serveris, tāpēc serveris atsakās apstrādāt pieprasījumu. Tas notiek reti, un bieži vien tas ir gadījums, kad veidlapas iesniegšana, kurai vajadzēja izmantot POST metodi, 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 ar katru novirzīšanu, kā rezultātā pēc vairākām novirzīšanām veidojas garš URI. Klienti mēģina uzbrukt serveriem, izmantojot dažos serveros esošās drošības nepilnības. Šādi serveri izmanto fiksēta garuma buferi, lai nolasītu vai manipulētu ar pieprasījuma URI, un, ja parametri pēc GET pārsniedz noteiktu vērtību, var rasties bufera pārpildīšanās, kas noved pie patvaļīgas koda izpildes [1]. Serveriem bez šādām ievainojamībām būtu jāatgriež 414 statusa kods. |
| 415 | Pašlaik pieprasītajai metodei un pieprasītajam resursam pieprasījumā iesniegtā vienība nav serverī atbalstītajā formātā, tāpēc pieprasījums tiek noraidīts. |
| 416 | Ja pieprasījums satur Range pieprasījuma galveni un visi Range norādītie datu diapazoni nepārklājas 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 pieprasījumā Range izmanto baitu diapazonus, tad tas notiek tad, ja visu pieprasījumā norādīto datu diapazonu pirmā baita pozīcija 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ī šis 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 IP adreses, kurā atrodas pašreizējais klients, 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 skaits var attiekties uz vairāk nekā vienu galalietotāju. |
| 422 | 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 starpniekserveru adrese). Šajā gadījumā savienojumu skaits var attiekties uz vairāk nekā vienu galalietotāju. |
| 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) |
| 424 | Pašreizējais pieprasījums neizdevās kļūdas dēļ, kas radusies iepriekšējā pieprasījumā, piemēram, PROPPATCH (RFC 4918 WebDAV) (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ētu nosacījumu, kas neļāva pabeigt pieprasījuma apstrādi. Parasti šāda problēma rodas, ja servera programmas kodā ir kļūda. |
| 501 | Serveris neatbalsta konkrētu funkciju, kas ir nepieciešama pašreizējam pieprasījumam. Ja serveris nespēj atpazīt pieprasīto metodi un nespēj atbalstīt tās pieprasījumu kādam resursam. |
| 502 | Serveris, kas darbojas kā vārteja vai starpniekserveris, saņem nepareizu 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 pagaidu uzturēšanas vai pārslodzes dēļ. Šis stāvoklis ir īslaicīgs un pēc kāda laika tiks atjaunots. Ja var sagaidīt kavēšanos, atbildē var iekļaut Retry-After galveni, lai norādītu kavēš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ārredzama satura pārrunu protokolu (RFC 2295), lai atspoguļotu servera iekšējo nepareizu konfigurāciju: pieprasītais sarunu varianta resurss ir konfigurēts tā, lai pats sevi izmantotu pārredzama satura pārrunās, un tāpēc nav piemērots sarunu procesa mērķis. |
| 507 | Serveris nespēj saglabāt saturu, kas nepieciešams, lai izpildītu pieprasījumu. Šis nosacījums tiek uzskatīts par pagaidu stāvokli.WebDAV (RFC 4918) |
| 509 | Serveris ir sasniedzis joslas platuma ierobežojumu. Šis nav oficiāls statusa kods, bet to joprojām plaši izmanto. |
| 510 | Resursa iegūšanai nepieciešamā politika nav izpildīta. (RFC 2774) |