Referencë Kodesh Statusi HTTP Falas

Përdoret për kërkesa me Expect: 100-continue. Serveri konfirmon që është gati të marrë trupin para se klienti ta dërgojë. Rrallë shihet në aplikacionet moderne web.

Përdoret më së shpeshti për përditësime WebSocket — klienti kërkon Upgrade: websocket dhe serveri përgjigjet me 101 për të ndërruar.

Një përgjigje e ndërmjetme WebDAV e dërguar për të parandaluar timeout-et e klientit gjatë operacioneve të gjata. E vjetëruar — serverët modernë nuk duhet ta dërgojnë.

U lejon serverëve të dërgojnë koka Link (preload/preconnect) ndërkohë që përgjigjja përfundimtare ende po përgatitet, kështu që shfletuesit mund të fillojnë të marrin burimet kritike më shpejt.

Përgjigjja standarde e suksesit. Kuptimi varet nga metoda HTTP: GET → burimi u kthye, POST/PUT → veprimi u krye.

E zakonshme pas një POST. Përgjigjja duhet të përfshijë një kokë Location që tregon URL-në e burimit të ri.

Për operacione asinkrone — serveri po e radhit punën. Klienti duhet të kontrollojë periodikisht një pikëfundim statusi ose të kthehet më vonë.

Kërkesa u përmbush, por një ndërmjetës (si një proxy caching ose transformues) e ndryshoi ngarkesën nga serveri origjinal — për shembull, duke ripakuar imazhet. E rrallë në praktikë.

Përdoret shpesh për operacione DELETE ose përditësime PUT që nuk kanë nevojë të kthejnë trup. Klienti nuk duhet të largohet nga faqja aktuale.

Njësoj si 204, nuk kthehet trup — por klienti udhëzohet gjithashtu të rivendosë formularin ose pamjen që prodhoi kërkesën (p.sh. të pastrojë fushat e formularit për hyrjen tjetër).

Përgjigje ndaj një kërkese Range. Përdoret nga player-at video dhe menaxherët e shkarkimeve për të vazhduar shkarkime të ndërprera ose transmetuar skedarë të mëdhenj.

WebDAV: një trup XML raporton rezultatin e disa nën-operacioneve në mënyrë të pavarur — p.sh. një zhvendosje në grup ku disa artikuj u kryen me sukses dhe të tjerë dështuan.

WebDAV: përdoret brenda përgjigjeve 207 Multi-Status për të shmangur listimin e përsëritur të anëtarëve të të njëjtit koleksion kur lidhjet (bindings) krijojnë sikle.

Kodim delta: serveri kthen një diferencë (diff) kundrejt një versioni të mëparshëm në vend të burimit të plotë, duke kursyer bandwidth. Zbatohet shumë rrallë.

Serveri ofron disa mundësi (p.sh. formate ose gjuhë të ndryshme) dhe klienti duhet të zgjedhë njërën. Përdoret rrallë, sepse negocimi automatik i përmbajtjes zakonisht e trajton këtë.

Përdoreni për ndryshime të përhershme të URL-së — motorët e kërkimit do ta përditësojnë indeksin e tyre. Autoriteti SEO kalon te URL-ja e re.

Tregon që ridrejtimi nuk është i përhershëm. Ruajtja në cache është më pak agresive se te 301. Përdoreni për raste si 'kërkohet hyrje, duke ridrejtuar te /login'.

Përdoret pas dërgimeve POST — përgjigjja thotë 'POST-i juaj funksionoi, shihni këtë URL GET për rezultatin'. Shfletuesit gjithmonë bëjnë GET te URL-ja e re.

Përgjigje ndaj një kërkese të kushtëzuar (me kokat If-None-Match ose If-Modified-Since). Kursen bandwidth — nuk kthehet asnjë trup përgjigjeje.

Nëse origjinali ishte POST, ridrejtimi përdor gjithashtu POST. Alternativë moderne ndaj 302 kur ruajtja e metodës ka rëndësi.

Zëvendësues modern i 301 kur dëshironi që kërkesat POST të mbeten POST pas ridrejtimit.

Shkaqe të zakonshme: JSON i keqformuar në trup, parametra kërkimi të pavlefshëm, ose fusha të domosdoshme që mungojnë. Kontrolloni trupin e kërkesës dhe kokat.

Klienti duhet të përfshijë kredenciale vërtetimi (kokë Authorization, cookie, token). 'I paautorizuar' është term jo i saktë — në fakt do të thotë 'i pavërtetuar'.

Fillimisht ishte menduar për pagesa dixhitale. Përdorim modern: API-të ndonjëherë kthejnë 402 kur një përdorues ka tejkaluar kuotën e tij me pagesë.

Ndryshe nga 401 — përdoruesi ËSHTË i kyçur, por llogaria e tij nuk ka leje për këtë burim. Kontrolloni logjikën e roleve/lejeve.

Ose URL-ja është e gabuar, burimi është fshirë, ose nuk ka ekzistuar kurrë. Serverët ndonjëherë kthejnë 404 për të fshehur faktin që 403 do të ishte më i saktë.

Për shembull, një kërkesë GET drejtuar një pikë fundore (endpoint) që pranon vetëm POST. Përgjigjja duhet të përfshijë një kokë Allow me metodat e vlefshme.

Klienti kërkoi një lloj përmbajtjeje, gjuhë ose kodim (përmes Accept, Accept-Language, Accept-Encoding) që serveri nuk mund t'i sigurojë. Shumë servera anashkalojnë negocimin strikt dhe kthejnë një vlerë të parazgjedhur.

Ngjashëm me 401, por lëshuar nga një proksi: klienti duhet të dërgojë kredenciale Proxy-Authorization. Haset në rrjete korporative me prokse vërtetuese.

Klientit iu deshën shumë kohë për të dërguar trupin e kërkesës ose e mbajti lidhjen joaktive. Provojeni kërkesën përsëri.

Zakonisht kthehet për konflikte redaktimi njëkohshëm ose krijim burimesh të dyfishta (p.sh. krijimi i një përdoruesi me një email që ekziston tashmë).

Më i fortë se 404 — serveri e di në mënyrë të qartë që burimi KA EKZISTUAR më parë, por është hequr përgjithmonë. Motorët e kërkimit do ta heqin nga indeksi.

Kërkesa u refuzua sepse i mungonte koka Content-Length dhe serveri refuzon trupa me madhësi të panjohur. Shtoni kokën dhe provoni përsëri.

Kthehet kur kokat e kushtëzuara si If-Match ose If-Unmodified-Since dështojnë — zakonisht bllokim optimist (optimistic locking): dikush tjetër ka ndryshuar burimin që nga versioni juaj. Rimerreni burimin dhe provoni përsëri.

E zakonshme gjatë ngarkimit të skedarëve të mëdhenj. Konfigurimi i serverit (nginx, apache) cakton një madhësi maksimale trupi. Kontrolloni konfigurimin e serverit.

Zakonisht shkaktohet nga vargje kërkimi shumë të gjata (p.sh. kodimi i të dhënave në një GET). Kaloni te një trup POST, ose rrisni kufirin e serverit nëse e kontrolloni atë.

Për shembull, dërgimi i application/xml te një server që pranon vetëm application/json. Vendosni saktë kokën Content-Type.

Koka Range kërkon një pjesë që skedari nuk e ka — p.sh. rifillimi i një shkarkimi përtej fundit të skedarit. Përgjigjja duhet të përfshijë Content-Range me madhësinë aktuale.

Dërgohet kur serveri nuk mbështet Expect: 100-continue. Disa klientë e dërgojnë këtë kokë si parazgjedhje në POST të mëdha; çaktivizimi i saj zakonisht zgjidh gabimin.

Një shaka e datës 1 prill nga viti 1998 (RFC 2324). Disa API reale e përdorin për shaka ose për të shënuar pikë fundore të vjetruara. Jo për përdorim në prodhim.

E zakonshme me ripërdorimin e lidhjeve HTTP/2: kërkesa arriti te një server që nuk është konfiguruar për host-in e synuar. Klienti duhet ta provojë përsëri në një lidhje të re.

Për shembull, JSON-i u analizua saktë, por një fushë e domosdoshme mungonte, ose vlera e një fushe ishte jashtë intervalit. E zakonshme në përgjigjet e validimit të API-ve REST.

WebDAV: burimi burim ose destinacion është i bllokuar nga një klient tjetër, kështu që operacioni nuk mund të vazhdojë. Prisni derisa të lirohet blloku ose thyeni atë me tokenin e duhur.

WebDAV: në një zinxhir operacionesh të varura, një veprim i mëparshëm dështoi, prandaj ky nuk u krye. Shikoni dështimin e mëparshëm për shkakun rrënjësor.

Lidhet me TLS 1.3 0-RTT (të dhëna të hershme): serveri nuk do të rrezikojë përpunimin e një kërkese potencialisht të riluajtur. Klienti duhet ta provojë përsëri pas përfundimit të handshake-ut.

Serveri refuzon të shërbejë kërkesën me protokollin aktual, por do ta bëjë pas një përditësimi — përgjigjja përfshin një kokë Upgrade që emërton protokollin e kërkuar.

Serveri kërkon kokat e kushtëzuara (si If-Match) për të parandaluar humbjen e përditësimeve. Merrni burimin, kapni ETag-un e tij dhe ridërgojeni me If-Match.

Ngadalësoni. Përgjigjja duhet të përfshijë një kokë Retry-After që tregon kur të provoni përsëri. E zakonshme me API-të që kanë kuota kërkesash.

Ose një kokë e vetme ose madhësia totale e kokave tejkalon kufirin — shkaktohet më së shpeshti nga cookie-t e mëdha. Fshini cookie-t ose zvogëloni atë që aplikacioni juaj ruan në to.

Burimi është i bllokuar për arsye ligjore — censurë, urdhra gjyqësorë ose rregullore rajonale. Numri i referohet romanit Fahrenheit 451.

Një kategori e përgjithshme për gabime anash serveri. Kontrolloni regjistrat (logs) e serverit për shkakun e vërtetë: përjashtim i patrajtuar, gabim baze të dhënash, etj.

Për shembull, serveri nuk e njeh metodën HTTP. E rrallë në praktikë — më shpesh do të shihni 405.

E zakonshme në arkitekturat me mikroshërbime. Balancuesi juaj i ngarkesës ose proksi i kundërt mori një përgjigje të keqformuar nga shërbimi prapa.

Ose është në mirëmbajtje, ose i mbingarkuar. Përgjigjja duhet të përfshijë një kokë Retry-After. Shpesh kthehet gjatë vendosjeve (deployments).

Shërbimi prapa nuk u përgjigj mjaft shpejt. Kontrolloni shëndetin e shërbimit prapa dhe konfigurimet e kohës së pritjes.

Versioni kryesor HTTP i kërkesës nuk mbështetet nga serveri. Pothuajse asnjëherë nuk shihet me klientë modernë.

Negocimi transparent i përmbajtjes përfundoi në një sikël: varianti i zgjedhur është vetë i konfiguruar për të negociuar. Tregon një gabim konfigurimi në server.

Me origjinë nga WebDAV, por ndonjëherë përdoret edhe nga serverë të përgjithshëm. Do të thotë që serveri nuk mund ta ruajë kërkesën për shkak kufizimesh ruajtjeje.

WebDAV: përpunimi i një kërkese Depth: infinity hyri në një sikël (p.sh. lidhje qarkore). Operacioni u ndërpre.

Nga struktura e vjetëruar HTTP Extension Framework: serveri ka nevojë për më shumë informacion para se ta plotësojë kërkesën. Praktikisht e papërdorur në ueb-in modern.

Përdoret nga portalet e rrethuara (captive portals — WiFi hoteli/aeroporti) për të treguar që përdoruesi duhet të kyçet në rrjet para se të qaset në sajte të jashtme.