Libreng Sanggunian ng HTTP Status Codes

Ginagamit para sa mga request na may Expect: 100-continue. Kinikilala ng server na handang makatanggap ng body bago ipadala ito ng client. Bihira makita sa modernong web apps.

Pinakakaraniwang ginagamit para sa WebSocket upgrades — hinihiling ng client ang Upgrade: websocket at sumasagot ang server ng 101 upang lumipat.

Isang WebDAV interim response na ipinapadala upang maiwasan ang client timeouts sa mahabang operasyon. Deprecated — hindi dapat ipadala ng modernong servers.

Nagpapahintulot sa mga server na magpadala ng Link headers (preload/preconnect) habang ang final response ay patuloy na inihahanda, upang magsimulang mag-fetch ang browsers ng critical assets nang mas maaga.

Ang standard success response. Ang kahulugan ay depende sa HTTP method: GET → resource returned, POST/PUT → action completed.

Karaniwan pagkatapos ng POST. Dapat kasama ng response ang Location header na tumuturo sa URL ng bagong resource.

Para sa async operations — nag-queue ang server ng trabaho. Dapat mag-poll ang client ng status endpoint o bumalik mamaya.

Matagumpay ang request, pero binago ng intermediary (tulad ng caching o transforming proxy) ang payload mula sa origin server — halimbawa, pag-compress ng mga larawan. Bihira sa pagsasagawa.

Kadalasan ginagamit para sa DELETE operations o PUT updates na hindi kailangang magbalik ng body. Hindi dapat lumipat ang client sa ibang pahina.

Tulad ng 204, walang body na bumabalik — ngunit sinasabihan din ang client na i-reset ang form o view na nagdulot ng request (hal. i-clear ang form fields para sa susunod na entry).

Response sa isang Range request. Ginagamit ng video players at download managers upang muling simulan ang interrupted downloads o mag-stream ng malalaking files.

WebDAV: ang XML body ay nag-uulat ng resulta ng maraming sub-operations nang hiwalay — hal. batch move kung saan ang ilan ay matagumpay at iba ay nabigo.

WebDAV: ginagamit sa loob ng 207 Multi-Status responses upang maiwasan ang paulit-ulit na paglalista ng mga miyembro ng parehong koleksyon kapag ang bindings ay lumilikha ng loops.

Delta encoding: bumabalik ang server ng diff laban sa nakaraang bersyon sa halip na ang buong resource, nakakatipid ng bandwidth. Napakabihira ng implementation.

Nag-alok ang server ng maraming opsyon (hal. iba't ibang format o wika) at dapat piliin ng client ang isa. Bihira gamitin, dahil karaniwang hinahawakan ito ng awtomatikong content negotiation.

Gamitin para sa permanent URL changes — ita-update ng mga search engines ang kanilang index. Nalilipat sa bagong URL ang SEO authority.

Ipinapahiwatig na hindi permanent ang redirect. Hindi kasing-agresibo ng 301 ang caching. Gamitin para sa mga bagay tulad ng 'kailangan ng login, naglilipat sa /login'.

Ginagamit pagkatapos ng POST submissions — ang response ay nagsasabi na 'gumana ang iyong POST, tingnan ang URL na ito para sa resulta'. Laging GET ang mga browser sa bagong URL.

Response sa isang conditional request (na may If-None-Match o If-Modified-Since headers). Nakakatipid ng bandwidth — walang body na bumabalik.

Kung ang orihinal ay POST, gumagamit din ng POST ang redirect. Modernong alternatibo sa 302 kung importante ang method preservation.

Modernong pagpapalit ng 301 kung gusto mong manatiling POST ang mga POST requests pagkatapos ng redirect.

Karaniwang dahilan: malformed JSON sa body, invalid query parameters, o nawawalang required fields. Suriin ang request body at headers.

Dapat kasama ng client ang authentication credentials (Authorization header, cookie, token). Ang 'Unauthorized' ay misnomer — talagang nangangahulugang 'unauthenticated'.

Orihinal na inilaan para sa digital payments. Modernong paggamit: kung minsan ang mga APIs ay nagbabalik ng 402 kapag lumampas ang user sa kanilang paid quota.

Iba sa 401 — logged in ang user, ngunit ang account ay walang permission para sa resource na ito. Suriin ang role/permissions logic.

Alinman ang URL ay mali, ang resource ay nabura, o hindi ito kailanman umiiral. Kung minsan ang mga server ay nagbabalik ng 404 upang itago na ang 403 ay mas tumpak.

Halimbawa, isang GET request sa endpoint na tumatanggap lang ng POST. Dapat kasama ng response ang Allow header na naglalista ng valid methods.

Hiniling ng client ang content type, wika, o encoding (via Accept, Accept-Language, Accept-Encoding) na hindi mabibigay ng server. Maraming server ang lumalaktaw sa mahigpit na negotiation at nagbabalik na lang ng default.

Tulad ng 401, ngunit inisyu ng proxy: dapat magpadala ng Proxy-Authorization credentials ang client. Nakikita sa corporate networks na may authenticating proxies.

Tumagal ng mahabang oras ang kliyente upang magpadala ng body ng kahilingan o pinanatili ang koneksyon na idle. Subukan ang kahilingan muli.

Karaniwang ibinabalik para sa mga conflict ng sabay-sabay na pagbabago o paglikha ng duplicate na resource (hal., paglikha ng user na may email na umiiral na).

Mas malakas kaysa 404 — ang server ay malinaw na alam na ang resource NOON ay umiiral ngunit permanenteng tinanggal. Ang mga search engine ay magsasagawa ng deindex.

Ang kahilingan ay na-reject dahil wala itong Content-Length header at ang server ay tumutanggi sa mga body na may hindi kilalang sukat. Idagdag ang header at subukan muli.

Ibinabalik kapag ang mga conditional header tulad ng If-Match o If-Unmodified-Since ay nabigo — karaniwang optimistic locking: may nagbago ng resource mula sa iyong bersyon. Muling kunin at subukan muli.

Karaniwan kapag nag-upload ng malalaking file. Ang server config (nginx, apache) ay nagtakda ng max body size. Suriin ang configuration ng server.

Karaniwang sanhi ng napakahaba ng query string (hal. pag-encode ng data sa GET). Lumipat sa POST body, o itaas ang limit ng server kung kontrolado mo ito.

Halimbawa, nagpadala ng application/xml sa server na tumatanggap lamang ng application/json. Itakda nang tama ang Content-Type header.

Ang Range header ay humihingi ng bahagi na wala sa file — hal. pagpapatuloy ng download pagkatapos ng dulo ng file. Ang response ay dapat magsama ng Content-Range na may aktwal na sukat.

Ipinapadala kapag hindi sinusuportahan ng server ang Expect: 100-continue. Ang ilang client ay ipinapadala ang header na ito bilang default sa malalaking POST; karaniwang nalulutas ng pag-disable nito ang error.

Isang biro tuwing April Fool's mula 1998 (RFC 2324). Ang ilang tunay na API ay gumagamit nito bilang biro o para markahan ang mga deprecated endpoint. Hindi para sa production use.

Karaniwan sa HTTP/2 connection reuse: umabot ang request sa isang server na hindi configured para sa target hostname. Dapat sumubok muli ang client sa bagong koneksyon.

Halimbawa, tama ang pag-parse ng JSON ngunit may nawawalang required field, o wala sa range ang value ng field. Karaniwan sa REST API validation responses.

WebDAV: ang source o destination resource ay naka-lock ng ibang kliyente, kaya ang operasyon ay hindi maaaring magpatuloy. Maghintay para sa lock na mailabas o sirain ito gamit ang naaangkop na token.

WebDAV: sa isang serye ng dependent operations, ang mas naunang aksyon ay nabigo, kaya ito ay hindi isinagawa. Tingnan ang mas naunang failure para sa root cause.

May kaugnayan sa TLS 1.3 0-RTT (early data): ayaw ng server na ipagsapalaran ang pagproseso ng posibleng na-replay na request. Dapat sumubok muli ang client pagkatapos makumpleto ang handshake.

Ang server ay tumutanggi na maglingkod sa kahilingan sa pamamagitan ng kasalukuyang protocol ngunit magagawa pagkatapos ng upgrade — ang response ay nagsasama ng Upgrade header na nagpapangalan ng kinakailangang protocol.

Ang server ay humihiling ng conditional headers (tulad ng If-Match) upang maiwasan ang lost-update conflicts. Kunin ang resource, kunin ang ETag nito, at ipadala muli gamit ang If-Match.

Bagalan ang pagpapadala. Dapat kasama sa response ang Retry-After header na nagsasabi kung kailan susubok muli. Karaniwan sa mga API na may request quota.

Alinman ang isang header o ang kabuuang laki ng header ay lumampas sa limit — kadalasang sanhi ng oversized na cookies. I-clear ang cookies o bawasan ang iniimbak ng iyong app sa mga ito.

Hinarang ang resource dahil sa mga legal na dahilan — censorship, utos ng korte, o regional na regulasyon. Pagpupugay sa nobelang Fahrenheit 451 ang numero.

Isang generic catch-all para sa server-side errors. Suriin ang server logs para sa aktwal na sanhi: unhandled exception, database error, atbp.

Halimbawa, ang server ay hindi kinikilala ang HTTP method. Bihira sa practice — mas madalas makikita mo ang 405.

Karaniwan sa microservice architectures. Ang iyong load balancer o reverse proxy ay nakakuha ng malformed response mula sa backend service.

Alinman ay down para sa maintenance o overloaded. Ang response ay dapat magsama ng Retry-After header. Madalas na ibinabalik sa panahon ng deployments.

Hindi tumugon nang sapat na bilis ang backend service. Suriin ang health ng upstream service at ang mga configuration ng timeout.

Ang pangunahing HTTP version ng kahilingan ay hindi sinusuportahan ng server. Halos hindi kailanman nakita sa modernong mga kliyente.

Nauwi sa loop ang transparent content negotiation: ang piniling variant mismo ay naka-configure na mag-negotiate. Nagpapahiwatig ng server configuration error.

Orihinal na partikular sa WebDAV ngunit minsan ginagamit ng mga pangkalahatang server. Ibig sabihin, hindi ma-save ng server ang request dahil sa limitasyon sa storage.

WebDAV: pumasok sa loop ang pagproseso ng Depth: infinity request (hal. circular bindings). Winakasan ang operasyon.

Mula sa obsolete na HTTP Extension Framework: kailangan ng server ng karagdagang impormasyon bago matupad ang request. Halos hindi na ginagamit sa modernong web.

Ginagamit ng mga captive portals (hotel/airport WiFi) upang ipahiwatig na ang user ay dapat mag-log in sa network bago mag-access sa external sites.