| HTTP Status Code |
Kahalagahan ng Status Code |
| 100 |
Ang kliyente ay dapat ipagpatuloy ang pagpapadala ng mga kahilingan. Ang pansamantalang tugon na ito ay ginagamit upang ipaalam sa kliyente na ang bahagi ng kahilingan nito ay natanggap na ng server at hindi pa tinanggap. Dapat ipagpatuloy ng kliyente ang natitirang bahagi ng kahilingan, o kung natapos na ang kahilingan, balewalain ang tugon na ito. Dapat magpadala ang server ng isang pangwakas na tugon sa kliyente sa sandaling makumpleto ang request. |
| 101 |
Naiintindihan na ng server ang kahilingan ng kliyente at ipapaalam nito sa kliyente sa pamamagitan ng Upgrade na header na gamitin ang ibang protocol upang tapusin ang kahilingang ito. Pagkatapos ng huli nitong walang laman na linya, ang server ay lilipat sa mga protocol na tinukoy sa Upgrade na header. Tanging kapag ang pagbabago ng bagong protocol ay mas kapaki-pakinabang ay dapat magsagawa ng mga katulad na hakbang. Halimbawa, ang paglipat sa isang bagong bersyon ng HTTP ay mas kapaki-pakinabang kaysa sa lumang bersyon, o paglipat sa isang real-time at synchronous na protocol upang ihatid ang mga resource na gumagamit ng mga katangiang ito. |
| 102 |
Isang status code na pinalawak ng WebDAV (RFC 2518), na nangangahulugang ang proseso ay patuloy na isasagawa. |
| 200 |
Matagumpay ang kahilingan, ang inaasahang mga header ng tugon o nilalaman ay ibabalik sa tugunang ito. |
| 201 |
Ang kahilingan ay naisakatuparan, at isang bagong resource ang nilikha alinsunod sa mga pangangailangan ng kahilingan nito, ang URI nito ay ibabalik kasama ang header na Location. Kung ang kinakailangang resource ay hindi maitatag sa oras, dapat itong ibalik bilang '202 Accepted'. |
| 202 |
Tinanggap ng server ang kahilingan, ngunit hindi pa ito naiproseso. Kung paanong maaari rin itong tanggihan, ang kahilingang ito ay maaaring isuong at maaaring hindi rin maisakatuparan. Sa mga sitwasyon ng asynchronous na operasyon, walang mas madaling gawin kaysa sa pagpapadala ng status code na ito. Layunin ng tugon na bumalik sa status code 202 na pahintulutan ang server na tanggapin ang ibang mga nakabinbing kahilingan (halimbawa, isang batched na operasyon na isinasagawa isang beses lamang sa isang araw), nang hindi pinananatiling nakakabit ang kliyente sa server hanggang makumpleto ang mga batched na operasyon. Ang tugon na nagtanggap ng pagpapatuloy sa kahilingan ay dapat hasain ang nilalaman ng dami na tumuturo sa proseso ng estado o panghuhula ng estado upang matiyak na ang gumagamit ay makakapaghusga kung ang operasyon ay natapos na. |
| 203 |
Matagumpay na pinroseso ng server ang kahilingan, ngunit ang nilalaman ng entity header ay hindi isang tiyak na set ng impormasyon mula sa orihinal na server kundi isang kopya mula sa lokal o third-party. Ang kasalukuyang impormasyon ay maaaring isang subset o superset ng orihinal na bersyon. Halimbawa, ang metadata ng resource ay maaaring humantong sa orihinal na server na malaman ang impormasyon sa supersete. Ang paggamit ng status code na ito ay hindi sapilitan, at naaangkop lamang kung ang tugon na hindi gagamit ng status code na ito ay ibabalik bilang 200 OK. |
| 204 |
Matagumpay na pinroseso ng server ang kahilingan, ngunit hindi na kailangang bumalik sa anumang nilalaman ng entidad at umaasa ng mga bagong impormasyon. Ang tugon ay maaaring maghatid ng mga bagong o na-update na impormasyon pamamagitan ng mga entity header. Kung ang mga header na ito ay naroroon, dapat itong tumugma sa mga hiniling na variable. Kung ang kliyente ay isang browser, dapat i-maintain ng browser ang pahinang nagpadala ng kahilingang iyon nang hindi nagdudulot ng anumang pagbabago sa view ng dokumento, kahit na ayon sa mga pamantayan ang mga bagong o na-update na metadata ay dapat ilapat sa dokumento sa view ng aktibidad ng user browser. Dahil ang tugon na 204 ay pinagbawalan na maglaman ng anumang message body, palaging natatapos ito sa unang walang laman na linya pagkatapos ng message header. |
| 205 |
Matagumpay na pinroseso ng server ang kahilingan at walang nilalaman na ibinalik. Ngunit, sa pagkakaiba sa tugon na 204, ang tugon na nagbibigay ng status code na ito ay humihiling sa requestor na i-reset ang view ng dokumento. Ang tugon na ito ay pangunahing ginagamit upang agad na i-reset ang form pagkatapos tumanggap ng input mula sa user, upang madaling makapagsimula ang user sa isa pang input. Katulad ng tugon na 204, ang tugon na ito ay pinagbawalan din na maglaman ng anumang message body at nagtatapos sa unang walang laman na linya pagkatapos ng message header. |
| 206 |
Matagumpay na pinroseso ng server ang bahagi ng GET request. Ang mga HTTP download tool tulad ng FlashGet o Xunlei ay gumagamit ng ganitong tugon upang posible ang pag-download ng breakpoint o pag-parse ng isang malaking dokumento sa maramihang bahagi na sabay-sabay na nadadownload. Ang request na ito ay dapat na kasama ang Range na header upang ipakita ang saklaw ng nilalaman na nais ng kliyente, at posibleng kasama ang If-Range bilang kondisyon ng request. Dapat kasama sa tugon ang mga domain ng mga header tulad ng Content-Range upang ipahiwatig ang saklaw ng nilalaman na ibinalik sa tugon; kung ito ay multipart/byteranges, bawat bahagi ng multipart ay dapat maglaman ng Content-Range na header upang ipahiwatig ang saklaw ng nilalaman ng piraso. Kung ang tugon ay naglalaman ng Content-Length, ang halaga nito ay dapat tumugma sa tunay na bilang ng bytes ng saklaw ng nilalaman na ibinalik. Ang mga header na petsa, ETag at/o Content-Location, kung ang parehong request ay dapat ibalik ang 200 na tugon. Expires, Cache-Control, at/o Vary, kung ang kanilang halaga ay maaaring iba sa ibang mga tugon na nauna sa katulad na variable. Kung ang tugon na ito ay ginamit ang If-Range strong caching validation, ang tugon na ito ay hindi dapat maglaman ng ibang uri ng entity headers; kung ginamit ang If-Range weak caching validation, ang tugon na ito ay pinagbabawalan na maglaman ng ibang entity headers; upang maiwasan ang hindi pagkakatugma ng nilalaman ng cached entity at na-update na entity headers. Kung hindi, ang tugon na ito ay dapat maglaman ng lahat ng header na dapat ibalik mula sa 200 na tugon. Kung hindi ang mga header ng ETag o Last-Modified ay tumutugma nang tumpak, ang cache ng kliyente ay pinagbabawalan na pagsamahin ang nilalaman ng tugon na 206 sa anumang cache na nilalaman na nauna na. |
| 207 |
Isang status code na pinalawak ng WebDAV(RFC 2518), na naglalarawan na ang mga sunod na message body ay magiging isang XML message, at maaaring maglaman ng isang pagkakasunod-sunod ng mga independent response codes depende sa dami ng mga naunang sub-request. |
| 300 |
May isang serye ng mga available na feedback ang hiniling na resource, bawat isa ay may kanya-kanyang tiyak na address at impormasyon ng komersyo na pinapatakbo ng browser. Maaaring pumili ang gumagamit o browser ng isang nais na address para sa redirection. Maliban kung ito ay isang HEAD request, ang tugon na ito ay dapat isama ang entity ng isang listahan ng mga katangian at address ng resource upang maipili ng gumagamit o browser ang pinaka-angkop na redirect address. Ang format ng entity ay tinutukoy ng format na tinukoy ng Content-Type. Pinapayagan ng browser na awtomatikong gumawa ng pinakamahusay na pagpili batay sa format ng tugon at kakayahan ng browser. Gayunpaman, ang RFC 2616 standard ay hindi nagbigay ng mga alituntunin kung paano dapat isagawa ang ganitong uri ng awtomatikong pagpili. Kung ang server mismo ay may preferensyal na feedback selection, dapat ipahiwatig ng Location ang URI ng feedback na iyon; ang browser ay maaaring gumamit ng value ng Location bilang auto-redirect address. Bukod dito, maliban kung walang ibang nakasaad, ang tugon na ito ay maaaring cached. |
| 301 |
Ang hiniling na resource ay permanenteng inilipat sa bagong lokasyon, at ang anumang sanggunian sa resource na ito sa hinaharap ay dapat gumamit ng isa sa mga URI na ibinalik sa tugon na ito. Kung posible, dapat awtomatikong baguhin ng kliyenteng mayroong mga link-editing capability ang hiniling na address sa address na ibinalik mula sa server. Maliban kung walang ibang nakasaad, ang tugon na ito ay maaari ring i-cache. Ang bagong permanenteng URI ay dapat ibalik sa Location domain ng tugon. Maliban kung ito ay isang HEAD request, ang entity ng tugon ay dapat maglaman ng hyperlink sa bagong URI na may maikling paglalarawan. Kung ito ay hindi isang GET o HEAD request, pinagbawalan ng browser na awtomatikong i-redirect, maliban kung makuha ng kumpirmasyon mula sa user, dahil maaaring magbago ang mga kondisyon ng request. Tandaan: Para sa ilang browser na gumagamit ng HTTP/1.0 protocol, kapag ang mga POST request ay nakatanggap ng 301 na tugon, ang susunod na redirection request ay magiging GET method. |
| 302 |
Ang hiniling na resource ay kasalukuyang pansamantalang tumugon mula sa ibang URI. Dahil ang ganitong redirection ay pansamantala, dapat ipagpatuloy ng kliyente ang pagpapadala ng mga susunod na kahilingan sa orihinal na address. Ang tugon na ito ay maaaring i-cache lamang kung ito ay ipinahayag sa Cache-Control o Expires. Ang bagong pansamantalang URI ay dapat ibalik sa Location domain ng tugon. Maliban kung ito ay isang HEAD request, dapat maglaman ang entity ng tugon ng hyperlink sa bagong URI na may maikling paglalarawan. Kung hindi ito isang GET o HEAD request, ang browser ay pinagbabawalan na awtomatikong i-redirect, maliban kung makuha ng kumpirmasyon mula sa user, dahil maaaring magbago ang mga kondisyon ng request. Tandaan: Bagaman ang mga pamantayan ng RFC 1945 at RFC 2068 ay hindi pinapayagan ang mga kliyente na baguhin ang request method sa tuwing nagre-redirect, maraming umiiral na mga browser ang humahawak sa 302 na tugon bilang isang 303 na tugon at ginagamit ang GET method sa nilalaman ng URI sa Location, na hindi pinapansin ang orihinal na request method. Idinagdag ang mga status code na 303 at 307 upang malinaw na ipahayag kung ano ang inaasahan ng server na sagot ng kliyente. |
| 303 |
Ang tugon sa kasalukuyang kahilingan ay maaaring matagpuan sa ibang URI, at dapat gamitin ng kliyente ang GET method upang ma-access ang resource. Ang pagkakaroon ng metodong ito ay pangunahing upang pahintulutan ang mga script-activated na POST requests na i-redirect ang output sa isang bagong resource. Ang bagong URI na ito ay hindi kapalit na sanggunian ng orihinal na resource. Samakatuwid, ang 303 na tugon ay pinagbawalan na i-cache. Siyempre, ang pangalawang request (redirection) ay maaaring i-cache. Dapat ibalik ang bagong URI sa Location domain ng tugon. Maliban kung ito ay isang HEAD request, dapat maglaman ang entity ng tugon ng hyperlink sa bagong URI na may maikling paglalarawan. Tandaan: Maraming mga browser bago ang HTTP/1.1 version ang hindi ganap na nauunawaan ang 303 status. Kung kailangan isaalang-alang ang interaksyon sa mga browser na ito, ang 302 status code ay dapat pagsilbihan, dahil ang karamihan sa mga browser kapag humahawak sa 302 na tugon ay tumpak na tugma sa mga alituntunin na inatasan ang mga kliyente kung paano dapat hawakan ang 303 na tugon. |
| 304 |
Kung ang kliyente ay nagpadala ng isang kondisyonal na GET request at pinahintulutan ang request, at hindi nagbago ang nilalaman ng dokumento (mula sa huling pagbisita o ayon sa mga kondisyon ng kahilingan), dapat ibalik ng server ang status code na ito. Bawal na isama ang message body sa 304 na tugon, kaya lagi itong nagtatapos sa unang walang laman na linya pagkatapos ng message header. Ang tugon ay dapat maglaman ng mga sumusunod na header: Date, maliban kung walang orasan ang server. Kung ang server na walang orasan ay sumusunod sa mga alituntuning ito, ang proxy server at kliyente ay maaaring awtomatikong magdagdag ng Date field sa natanggap na mga header ng tugon (tulad ng itinatadhana sa RFC 2068), at ang caching mechanism ay gagana tulad ng dati. Dapat isama rin ang ETag at/o Content-Location, kung ang katulad na request ay dapat ibalik ang 200 na tugon. Dapat isama rin ang Expires, Cache-Control, at/o Vary, kung ang mga halaga nito ay maaaring magkaiba mula sa mga nakaraang katulad na variable sa iba pang mga tugon. Kung ang request na ito ay gumagamit ng strong caching validation, ang tugon na ito ay hindi dapat maglaman ng ibang entity headers; kung ang request na ito ay gumagamit ng weak caching validation, ang tugon na ito ay ipinagbabawal na maglaman ng ibang entity headers; upang maiwasan ang hindi pagkakatugma sa pagitan ng cached entity content at na-update na entity headers. Kung tumutukoy ang isang 304 na tugon na kasalukuyang wala nang cached, ang caching system ay dapat balewalain ang tugon na ito, at muling ipadala ang request na walang conditioning. Kung ang isang 304 na tugon ay nagpapahiwatig ng pag-update ng isang cached entry, dapat ayusin ng caching system ang buong entry upang ipakita ang lahat ng mga field values na na-update sa tugon. |
| 305 |
Ang hiniling na resource ay dapat i-access sa pamamagitan ng tinukoy na proxy. Ang Location domain ay magbibigay ng impormasyon tungkol sa lokasyon ng tinukoy na proxy, kailangan ng tumanggap na muling ipadala ang hiwalay na request, gamit ang proxy upang ma-access ang nauugnay na resource. Tanging ang orihinal na server lamang ang maaaring bumuo ng 305 na tugon. Tandaan: Ang RFC 2068 ay hindi tahasang nagsasaad na ang 305 na tugon ay para sa pag-redirect ng isang hiwalay na request at tanging ang orihinal na server lamang ang maaaring bumuo nito. Ang pagwawalang-bahala sa mga limitasyong ito ay maaaring magdulot ng malubhang mga kahihinatnan sa seguridad. |
| 306 |
Sa pinakabagong mga pamantayan, ang 306 status code ay hindi na ginagamit. |
| 307 |
Ang hiniling na resource ay kasalukuyang pansamantalang tumugon mula sa ibang URI. Dahil ang ganitong pag-redirect ay pansamantala, dapat ipagpatuloy ng kliyente ang pagpapadala ng mga kahilingan sa orihinal na address. Ang tugon na ito ay maaari lamang mai-cache kung ipinahayag ito sa Cache-Control o Expires. Ang bagong pansamantalang URI ay dapat ibalik sa Location domain ng tugon. Maliban kung ito ay isang HEAD request, ang entity ng tugon ay dapat maglaman ng hyperlink sa bagong URI na may maikling paglalarawan. Dahil ang ilang mga browser ay hindi kinikilala ang 307 na tugon, kinakailangan ang mga kinakailangang impormasyon upang maunawaan at magbigay-daan ang mga user sa pag-access ng bagong URI. Kung ito ay hindi isang GET o HEAD request, ang browser ay pinagbabawalan na awtomatikong i-redirect, maliban kung makuha ng kumpirmasyon mula sa user, dahil maaaring magbago ang mga kondisyon ng request. |
| 400 |
1. Maling semantika, hindi maunawaan ng server ang kasalukuyang request. Maliban kung maayos ito, hindi dapat muling isumite ng kliyente ang kahilingang ito. 2. Maling mga parameter ng request. |
| 401 |
Nangangailangan ang kasalukuyang request ng pagkakakilanlan ng user. Ang tugon ay dapat maglaman ng angkop na WWW-Authenticate na header para humingi ng impormasyon ng user. Maaaring muling isumite ng kliyente ang request na naglalaman ng wastong Authorization na header. Kung ang kasalukuyang request ay naglalaman na ng mga pagbibigay ng Authorization, ang 401 na tugon ay nagpapahiwatig na tinanggihan ng server ang mga pagbibigay na iyon. Kung ang 401 na tugon ay naglalaman ng parehong authentication query tulad ng naunang tugon, at ang browser ay sinubukan na ang authentication isang beses o higit pa, dapat ipakita ng browser ang entity information na nakapaloob sa tugon, dahil ang entity information na ito ay maaaring naglalaman ng nauugnay na impormasyon sa diagnosis. Tingnan ang RFC 2617. |
| 402 |
Ang status code na ito ay nakalaan para sa mga posibleng hinaharap na pangangailangan. |
| 403 |
Naiintindihan ng server ang kahilingan ngunit tinatanggihan ang pagganap nito. Sa pagkakaiba mula sa 401, ang authentication ay hindi makatutulong, at ang kahilingang ito ay hindi dapat muling isumite. Kung hindi ito isang HEAD request, at nais ng server na ipaliwanag kung bakit hindi maipatupad ang request, dapat ipahiwatig ang dahilan ng pagtanggi sa entity. Siyempre, maaari din na ibalik ng server ang 404 na tugon kung ayaw nitong ipaalam sa kliyente ang anumang impormasyon. |
| 404 |
Ang kahilingan ay nabigo, at ang inaasahang resource ay hindi natagpuan sa server. Walang impormasyon na makapagbibigay sa gumagamit tungkol sa kung ang sitwasyong ito ay pansamantala o permanente. Kung alam ng server ang sitwasyon, dapat gamitin ang status code na 410 upang ipaalam na ang luma resource ay permanente nang hindi magagamit dahil sa ilang mga internal na mekanismo ng configuration, at walang anumang address na maaaring i-redirect. Ang 404 na status code ay malawakang ginagamit kapag ayaw ipakita ng server kung bakit tinanggihan ang request o walang ibang wastong tugon na maaaring ibigay. |
| 405 |
Ang request method na tinukoy sa request line ay hindi maaaring gamitin upang humiling ng kaukulang resource. Dapat ibalik ng tugon ang isang Allow na header upang ipakita ang listahan ng mga request method na tinatanggap ng kasalukuyang resource. Dahil ang PUT at DELETE na method ay gagawa ng mga operasyon sa pagsusulat sa resource sa server, halos lahat ng web server ang hindi sumusuporta o hindi pinapayagan ang mga nabanggit na request method sa default na configuration, kaya ang mga request na ito ay bumabalik ng 405 na error. |
| 406 |
Ang nilalaman ng resource na hiniling ay hindi maaaring matugunan ang mga kondisyon sa header ng request, kaya't hindi maibigay ang entity ng tugon. Maliban kung ito ay isang HEAD request, dapat ibalik ng tugon na ito ang isang entity na may listahan ng mga entity feature at address na maaaring piliin ng gumagamit o browser. Ang format ng entity ay itinakda ng media type na tinukoy sa Content-Type header. Maaaring awtomatikong gumawa ng pinakamahusay na pagpili ang browser batay sa format at kakayahan nito. Gayunpaman, hindi nagbigay ang pamantayan ng anumang pamantayan upang magsagawa ng ganitong uri ng awtomatikong pagpili. |
| 407 |
Katulad ng 401 na tugon, ang pagkakaiba ay ang kliyente ay dapat patunayan sa proxy server. Dapat magbigay ang proxy server ng Proxy-Authenticate upang humiling ng authentication. Maaaring ibalik ng kliyente ang Proxy-Authorization na header para sa pagkilala. Tingnan ang RFC 2617. |
| 408 |
Ang request ay nag-timeout. Ang kliyente ay hindi nakapagpadala ng request sa loob ng itinatakdang oras ng paghihintay ng server. Maaaring muling isumite ng kliyente ang kahilingang ito anumang oras nang hindi kinakailangan ng anumang pagbabago. |
| 409 |
Ang kahilingan ay hindi maaaring maisagawa dahil mayroong salungatan sa kasalukuyang estado ng resource na hiniling. Pinapayagan lamang ang status code na ito kapag ang gumagamit ay itinuturing na kayang solusyunan ang salungatan at muling isumite ang isang bagong kahilingan. Dapat kasama sa tugon ang sapat na impormasyon upang matukoy ng gumagamit ang pinagmulan ng salungatan. Karaniwan ang salungatan ay nangyayari sa pagproseso ng PUT requests. Halimbawa, sa kapaligiran ng versioning checks, kapag ang version information ng isang PUT submission para sa partikular na resource ay naglalaman ng salungatan sa naunang (third-party) request, dapat ibalik ng server ang 409 na error upang ipaalam na hindi natapos ang request. Sa pagkakataong iyon, malamang na maglaman ang entity ng tugon ng mga pagkakaiba sa pagitan ng dalawang salungatan na bersyon upang magkaroon ng pagkakataon ang user na muling isumite ang pinagsama-samang bersyon. |
| 410 |
Ang hiniling na resource ay hindi na magagamit sa server, at walang kilalang forwarding address. Ang ganitong sitwasyon ay dapat ituring na permanente. Kung posible, dapat awtomatikong tanggalin ng kliyente ang lahat ng message reference sa address na ito pagkatapos humingi ng pahintulot ng gumagamit. Kung hindi alam ng server o hindi maayos na matukoy ang sitwasyon, dapat gamitin ang status code na 404. Maliban na lamang kung may karagdagang pahayag, ang tugon na ito ay maaaring i-cache. Ang layunin ng 410 na tugon ay upang matulungan ang mga site administrator na mapanatili ang website, ipaalam sa mga gumagamit na ang resource ay hindi na magagamit, at hiniling ng server na alisin ang lahat ng remote connection na tumutukoy sa resource na ito. Karaniwan ang mga ganitong pangyayari sa mga limitadong oras at mga premium service. Gayundin, ginagamit ang 410 na tugon upang ipaalam sa kliyente na ang resource na dati ay nasa kasalukuyang site ng server at hindi na magagamit. Siyempre, ang pagpapasya kung kailangan bang markahan ang lahat ng permanenteng hindi magagamit na resources ng '410 Gone', at kung gaano katagal dapat mapanatili ang markang ito, ay ganap na nakasalalay sa may-ari ng server. |
| 411 |
Tinanggihan ng server na tanggapin ang request kung walang nalikhang Content-Length na header. Matapos idagdag ang wastong Content-Length na header na nagtatakda ng haba ng request message body, maaaring muling isumite ng kliyente ang kahilingang ito. |
| 412 |
Ang server ay hindi nakatitiyak na natutugunan ang isa o higit pa sa mga prerequisite na nakasaad sa head field ng request. Ang status code na ito ay nagpapahintulot sa kliyente na magtakda ng mga prerequisite sa metainformation (request header field data) kapag bumibili ng resource, upang maiwasan ang request method na mailapat sa resource na gusto nito ngunit hindi pangkaraniwan. |
| 413 |
Tinanggihan ng server ang pagproseso ng kasalukuyang request dahil ang entity data na isinumiteng bahagi ng request ay lumampas sa saklaw na handang iproseso ng server o kaya ay nahihirapan ang server na iproseso ito. Sa mga ganitong sitwasyon, maaaring isara ang server ang koneksyon upang maiwasan ang patuloy na pagpapadala ng client sa request na ito. Kung ang sitwasyong ito ay pansamantala, dapat magbalik ang server ng isang Retry-After na response header upang ipaalam sa kliyente kung kailan maari nitong subukang muli. |
| 414 |
Ang haba ng hiniling na URI ay lumampas sa bisa ng server sa pag-unawa, at dahil dito ay tinatanggihan ng server ang request na ito. Labis itong bihira, ang karaniwang mga kaso ay kinabibilangan ng: isang form submission na dapat ay POST method ay naging GET method, sanhi upang masyadong mahaba ang query string. URI "black hole" sa pag-redirect, halimbawa, ang bawat redirection ay gumagamit ng dating URI bilang bahagi ng bagong URI, causing ang URI ay pagmamalapit na lumampas pagkatapos ng maraming redirection. Ang kliyente ay nagtatangkang atakehin ang server gamit ang ilang mga vulnerability na umiiral, ang server na walang mga nasabing vulnerabilities ay dapat magbalik ng status code na 414. |
| 415 |
Para sa kasalukuyang request method at hiniling na resource, ang nilalaman ng entity na isinumit ay hindi sa suportadong format ng server, kaya't tinanggihan ang request. |
| 416 |
Kung ang request ay may kasamang Range request header at anumang partikular na saklaw na tinukoy sa Range ay hindi tumutugma sa kasalukuyang saklaw ng resource, at ang request ay walang Itakdang If-Range, ang server ay dapat magbalik ng status code na 416. Kung ang saklaw ay gumagamit ng byte range, ang ganitong sitwasyon ay kumakatawan sa mga sitwasyong kung saan ang mga first byte position ng lahat ng data range ay lumampas sa haba ng kasalukuyang resource. Dapat ring magsama ng Content-Range entity header ang server na naglalaman ng impormasyon tungkol sa kasalukuyang haba ng resource kapag nagbalik ng status code na 416. Bawal ding gamitin ang multipart/byteranges bilang Content-Type ng response. |
| 417 |
Ang inaasahang nilalaman na tinutukoy sa request header Expect ay hindi natutugunan ng server o ang server ay isang proxy server na tila may sapat na katibayan na ang nilalaman na Expect ay hindi matutugunan sa susunod na node sa kasalukuyang routing. |
| 421 |
Ang bilang ng koneksyon mula sa kasalukuyang IP address ng kliyente patungo sa server ay lumampas sa maximum na pinapahintulutan ng server. Kadalasan, ang IP address na ito ay kumakatawan sa address ng client na nakikita mula sa server (halimbawa, ang gateway o proxy server address ng user). Sa ganitong kaso, ang bilang ng koneksyon na ito ay maaaring sumasaklaw sa higit sa isang solitaryong end-user. |
| 422 |
Ang format ng request ay tama, ngunit dahil sa mga semantikal na error, hindi maaaring tugunan. (RFC 4918 WebDAV) 423 Locked - ang kasalukuyang resource ay na-lock. (RFC 4918 WebDAV) |
| 424 |
Ang kasalukuyang request ay nabigo dahil sa isang error mula sa isang naunang request, tulad ng PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Itinakda sa WebDav Advanced Collections draft ngunit hindi lumitaw sa WebDAV Ordered Collection Protocol (RFC 3658). |
| 426 |
Ang kliyente ay dapat lumipat sa TLS/1.0. (RFC 2817) |
| 449 |
Pinalawig ng Microsoft, nangangahulugang dapat muling subukan ang request matapos ang naaangkop na aksyon ay naisagawa. |
| 500 |
Nakatagpo ang server ng isang hindi inaasahang sitwasyon na nagresulta sa kakulangan upang matapos ang request. Sa pangkalahatan, ang problemang ito ay lumitaw kapag may mga error sa program na tumatakbo sa server. |
| 501 |
Hindi sinusuportahan ng server ang isang tiyak na functionality na kinakailangan para sa kasalukuyang request. Kapag ang server ay hindi makakilala ng method sa request, at hindi makatulong sa anumang request sa anumang resource. |
| 502 |
Ang server na gumaganap bilang gateway o proxy ay nakatanggap ng invalid response mula sa upstream server habang sinusubukang iproseso ang request. |
| 503 |
Dahil sa pansamantalang maintenance ng server o sobrang load, ang server ay kasalukuyang hindi makaproseso ng request. Ang sitwasyong ito ay pansamantala, at maibabalik sa isang tiyak na oras. Kung malalaman ang inaasahang oras ng pagkaantala, maaaring isama ng tugon ang Retry-After na header upang ipahayag ang pagkaantala. Kung walang impormasyong ito, dapat ihandog ng client ang 500 na tugon. Tandaan: Ang pagkakaroon ng status code 503 ay hindi nangangahulugan na dapat gamitin ito ng server kapag overload. Ang ilang mga server ay nais lamang tanggihan ang koneksyon mula sa kliyente. |
| 504 |
Ang server na gumaganap bilang gateway o proxy ay hindi nakatanggap ng response mula sa upstream server (URI na tinutukoy na server, halimbawa HTTP, FTP, LDAP) o auxiliary server (halimbawa DNS) sa tamang oras habang sinusubukang iproseso ang request. Tandaan: Ang ilang mga proxy servers ay nagbalik ng 400 o 500 errors habang ang DNS lookup ay nag-timeout. |
| 505 |
Ang server ay hindi sumusuporta, o tinatanggihan ang suporta para sa HTTP version na ginagamit sa request. Ipinapahiwatig nito na ang server ay hindi makakagamit o ayaw gumamit ng parehong bersyon sa client. Dapat isama sa tugon ang isang entity na naglalarawan kung bakit hindi suportado ang bersyon at aling mga protocol ang sinusuportahan ng server. |
| 506 |
Pinalawig ng Transparent Content Negotiation Protocol (RFC 2295), na nangangahulugang may internal configuration error ang server: ang hiniling na negotiated variant resource ay naka-configure upang gamitin ang sarili sa transparent content negotiation, kaya hindi akma ito sa isang negotiation process. |
| 507 |
Hindi matagumpay na masustento ng server ang nilalaman na kinakailangan upang makumpleto ang request. Ang sitwasyong ito ay itinuturing na pansamantala. WebDAV (RFC 4918) |
| 509 |
Umabot ang server sa bandwidth limit. Ito ay hindi isang opisyal na status code, ngunit malawak na ginagamit. |
| 510 |
Ang kinakailangang patakaran upang makuha ang resource ay hindi natugunan. (RFC 2774) |