| HTTP status kod |
Značenje status koda |
| 100 |
Klijent treba da nastavi sa slanjem zahteva. Ova privremena reakcija služi da obavesti klijenta da je deo njegovog zahteva primljen i da nije odbijen. Klijent treba da nastavi sa slanjem preostalog dela zahteva, ili, ako je zahtev već završen, da ignorira ovu reakciju. Server mora poslati konačnu reakciju klijentu kada se zahtev završi. |
| 101 |
Server je razumeo zahtev klijenta i obavestava klijenta da će koristiti različiti protokol da završi taj zahtev preko Upgrade header-a. Nakon slanja poslednjeg praznog reda ovog odgovora, server će preći na protokole definisane u Upgrade header-u. Ovakvo ponašanje se treba primeniti samo kada je prelazak na novi protokol korisniji. Na primer, prelazak na novu verziju HTTP je bolji od starije, ili prelazak na real-time i sinhroni protokol za prenos resursa. |
| 102 |
Status kod proširen od WebDAV (RFC 2518), koji označava da se obrada nastavlja. |
| 200 |
Zahtev je uspešno izvršen, a željeni odgovor ili sadržaj će biti vraćen sa ovim odgovorom. |
| 201 |
Zahtev je uspešno izvršen, a novi resurs je kreiran na osnovu zahteva, a njegova URI je vraćena u Location header-u. Ukoliko resurs ne može biti brzo kreiran, trebalo bi da se vrati '202 Accepted'. |
| 202 |
Server je prihvatio zahtev, ali ga još nije obradio. Kao što može biti odbijen, na kraju, zahtev može ili ne mora biti izvršen. U slučaju asinkronih operacija, nema lakšeg načina nego vraćanje ovog status koda. Cilj vraćanja odgovora sa status kodom 202 je omogućiti serveru da prihvati druge zahteve procesa (na primer, operacije koje se izvršavaju svakodnevno), bez potrebe da klijent drži vezu sa serverom dok se sve operacije ne završe. Odgovor koji vraća status kod 202 trebalo bi da sadrži neki indikator trenutnog statusa obrade, kao i pokazivač ka praćenju statusa obrade, kako bi korisnik mogao proceniti da li je operacija završena. |
| 203 |
Server je uspešno obradio zahtev, ali meta informacije u vraćenom entitetu nisu iz izvorneg servera, već su iz kopije iz lokalnog ili treće strane. Te informacije mogu biti podskup ili nadskup izvorne verzije. Korišćenje ovog status koda nije obavezno, a prikladno je samo kada ne bi bilo vraceno 200 OK bez njega. |
| 204 |
Server je uspešno obradio zahtev, ali ne treba vraćati nikakav sadržaj, a želi vratiti ažurirane meta informacije. Odgovor može da vrati nove ili ažurirane informacije kroz entitet header. Ako postoje informacije u tim header-ima, trebale bi da odgovaraju traženim varijablama. Ako je klijent pretraživač, korisnički pretraživač trebalo bi da zadrži stranicu koja je poslala taj zahtev, bez promena u prikazu dokumenata, čak i ako dobijene informacije treba da se primene na aktivnosti korisnika u pretraživaču. Budući da 204 odgovori ne smeju sadržavati telo poruke, oni uvek završavaju prvim praznim redom posle header-a. |
| 205 |
Server je uspešno obradio zahtev, ali nije vratio sadržaj. Međutim, za razliku od 204 odgovora, ovaj status kod zahteva od klijenta da resetuje prikaz dokumenata. Ovaj odgovor se najčešće koristi nakon što se prihvati korisnički unos da odmah resetuje formu i omogući korisniku da lako započne novi unos. Kao i 204, ovaj odgovor također nije dozvoljeno da sadrži telo poruke, i završava se prvim praznim redom posle header-a. |
| 206 |
Server je uspešno obradio deo GET zahteva. HTTP preuzimanje alati kao što su FlashGet ili Thunder koriste ovaj odgovor za omogućavanje nastavka preuzimanja ili deljenje velikog dokumenta na više delova. Taj zahtev mora sadržavati Range header kako bi označio sadržinski opseg koji klijent želi, i može sadržati If-Range kao uslov zahteva. Odgovor mora sadržavati sledeće header polje: Content-Range da označi opseg sadržaja vraćenog sa ovim odgovorom; ako je Content-Type multipart/byteranges, svaka multipart sekcija treba da ima Content-Range polje koje označava opseg sadržaja u toj sekciji. Ako odgovara sadrži Content-Length, njegov broj mora odgovarati stvarnom broju bajtova u opsegu sadržaja. Datum ETag i/ili Content-Location, ako je takođe zahtevano 200. Expires,Cache-Control, i/ili Vary, neki od kojih se možda ne podudara sa drugim odgovorima za iste varijable. Ako je ova reakcija uključila If-Range čvrsti keš verifikaciju, ova reakcija ne bi trebala da sadrži druge entitet header-e; ako su THIS reakcija zahtevali If-Range slabi keš verifikaciju, tada OVDE reakcija ne bi trebala da sadrži druge header-e; kako bi se sprečila nekonzistencija između keširanih sadržaja i ažuriranih entitet header-a. Inače, ova reakcija bi trebala da sadrži sve entitete header-a koji bi trebali biti uključeni u zahtev koji bi trebalo da se vrate sa 200 odgovorima. Ako ETag ili Last-Modified header ne podudaraju, klijentski keš ne bi trebao da kombinuje sadržaj vraćen u 206 odgovoru sa bilo kojim prethodno keširanim sadržajem. Svi keševi koji ne podržavaju Range ili Content-Range header su zabranjeni da keširaju 206 vraćene sadržaje. |
| 207 |
Status kod proširen od WebDAV (RFC 2518), koji označava da će naredni entitet biti XML poruka, i možda sadrži niz nezavisnih kodova odgovora u zavisnosti od broja prethodnih podzahteva. |
| 300 |
Zahtevali resurs ima niz mogućih povratnih informacija, od kojih svaka ima svoj poseban URI i informacije zahteva od pretraživača. Korisnik ili pretraživač može sami izabrati omiljeni URI za preusmeravanje. Osim ako nije naloženo HEAD zahtevu, ovaj odgovor bi trebao da sadrži entitet liste resursa i adresa, tako da korisnik ili pretraživač može da izabere najprikladniju adresu za preusmeravanje. Format ovog entiteta određuje format definisan Content-Type. Pretraživači mogu automatski doneti najbolji izbor na osnovu formata odgovora i svojih sposobnosti. Naravno, RFC 2616 ne postavlja pravila kako bi se obavio ovakav automatski izbor. Ako server ima preferirani povratni izbor, taj URI bi trebao biti označen u Location; pretraživač može koristiti ovu hodnotu kao adresu za automatsko preusmeravanje. Osim ako nije dodatno određeno, ovaj odgovor takođe može biti keširan. |
| 301 |
Zahtevani resurs je trajno premješten na novu lokaciju, i bilo koji budući zahtev za taj resurs bi trebao da koristi jedan od URI adresa vraćenih ovim odgovorom. Ako je moguće, klijentski sistem koji može menjati linkove treba automatski da menja adresu sa koje se zahteva na adresu feedback u sa servera. Osim ako nije dodatno navedeno, ovaj odgovor takođe može biti keširan. Nove trajne URI treba da budu vraćene u Location domain. Osim ako nije naloženo HEAD zahtevu, entitet tog odgovora treba da sadrži hyperlink na novu URI i kratak opis. Ako ovo nije GET ili HEAD zahtev, zatim, pretraživač zabranjuje automatsko preusmeravanje, osim uz korisničku potvrdu, jer bi to moglo promeniti uslove zahteva. Napomena: za neke pretraživače koji koriste HTTP/1.0, kada se POST zahtev vrati sa 301, sledeći preusmereni zahtev biće korišćen kao GET. |
| 302 |
Zahtevani resurs trenutno odgovara sa drugom URI. Budući da je ovo preusmeravnje privremeno, klijent treba da nastavi sa slanjem narednih zahteva na originalnu adresu. Ovaj odgovor može biti keširan samo ako je to naloženo Cache-Control ili Expires. Privremeni novi URI trebao bi biti vraćen u Location header. Osim ako nije naloženo HEAD, entitet odgovora trebao bi sadržati hyperlink na novu URI i kratak opis. Ako ovo nije GET ili HEAD zahtev, klijent pretraživača će zabraniti automatsko preusmeravanje, osim uz korisničku potvrdu, jer bi to moglo promeniti uslove zahteva. Napomena: iako RFC 1945 i RFC 2068 ne dopuštaju klijentima da menjaju zahtev ka novoj URI dok preusmeravaju, mnogi postojani pretraživači interpretiraju 302 kao 303 i koriste GET na URI definisanoj u Location, ignorirajući metod koji je prvobitno korišćen. Status kodovi 303 i 307 su dodatno dodani da jasno definišu kakvu reakciju server očekuje od klijenta. |
| 303 |
Odgovor na trenutni zahtev može se naći na drugoj URI, a klijent treba koristiti GET metod za pristup tom resursu. Ova metoda postoji prvenstveno da bi omogućila da rezultati POST zahteva preusmere na novi resurs. Ova nova URI nije alternativna referenca za originalni resurs. Pored toga, odgovor 303 ne može biti keširan, naravno, drugi zahtevi (preusmeravanje) mogu biti keširani. Nova URI treba da bude vraćena u Location header. Osim ako nije navođeno kao HEAD zahtev, entitet odgovora treba da sadrži hyperlink na novu URI i kratak opis. Napomena: mnogi pretraživači pre verzije HTTP/1.1 ne mogu pravilno razumeti stanje 303. Ako razmišljate o interakciji sa tim pretraživačima, onda status kod 302 bi trebao biti odgovarajući, jer većina pretraživača tretira 302 ka postupku koji pravilno tretira 303. |
| 304 |
Ako klijent šalje uslovni GET zahtev i taj zahtev je dozvoljen, i sadržaj dokumenta (od poslednjeg pristupa ili na osnovu uslova zahteva) nije promenjen, server bi trebao da vrati ovaj status kod. Odgovor 304 ne sadrži telo poruke, te se uvek zaključuje prvim praznim redom posle header-a. Ovaj odgovor mora sadržavati sledeće header informacije: Datum, osim ako server ne može održati vreme. Ako server ne može pratiti ovo pravilo, proxy serveri i klijenti mogu dodati Datum na dobijeni odgovor header u skladu sa propisima RFC 2068. Keš mehanizam će raditi normalno. ETag i/ili Content-Location, ako bi ponudili 200 odgovore. Expires, Cache-Control, i/ili Vary, ako njihova vrednost može biti različita od drugih odgovora s istim varijablama. Ako je ovaj odgovor koristio čvrstu keš verifikaciju, ne bi trebao uključiti druge entitet header-e; osim ako (na primer, neki uslovni GET zahtev koristi slab keš verifikaciju), ne bi trebao sadržavati druge entitet header-e; kako se izbegne nekonzistentnost između keširanog sadržaja i ažuriranih entitet header-a. Ako neki 304 odgovor označava da trenutni entitet nije keširan, sistem za keširanje ga mora ignorisati i ponovo poslati zahtev bez uslovnih provere. Ako primite 304 odgovor koji zahteva ažuriranje određenog keš zapisa, tada sistem za keširanje mora ažurirati celu stavku kako bi odražavao sve promene u odgovorima koji su ažurirani. |
| 305 |
Zahtevani resurs mora se pristupiti preko specificiranog posrednika. Informacije o lokaciji specificiranog posrednika treba da budu date u Location headeru, primaoc mora ponovo poslati poseban zahtev da bi pristupio resursu kroz ovaj posrednik. Samo izvorni server može postaviti 305 odgovor. Napomena: RFC 2068 nije jasno izjavila da se 305 odgovor koristi da preusmeri poseban zahtev, i da se samo može postaviti od izvornih servera. Ignorisanje ovih ograničenja može izazvati ozbiljne sigurnosne posledice. |
| 306 |
U najnovijim specifikacijama, status kod 306 se više ne koristi. |
| 307 |
Zahtevani resurs trenutno odgovara sa drugom URI. Budući da je ovo preusmeravnje privremeno, klijent treba da nastavi sa slanjem narednih zahteva na originalnu adresu. Ovaj odgovor može biti keširan samo ako je to naloženo Cache-Control ili Expires. Privremeni novi URI trebalo bi biti vraćen u Location header. Osim ako nije naloženo HEAD, entitet odgovora treba da sadrži hyperlink na novu URI i kratak opis. Zbog činjenice da neki pretraživači ne prepoznaju 307 odgovor, potrebno je dodati potrebne informacije kako bi korisnici mogli da razumeju i obrate se novom URI. Ako ovo nije GET ili HEAD zahtev, klijenti pretraživača će zabraniti automatsko preusmeravanje, osim uz korisničku potvrdu, jer bi to moglo promeniti uslove zahteva. |
| 400 |
1. Semantička greška, trenutni zahtev ne može biti shvaćen od strane servera. Osim ako se izmeni, klijent ne bi trebao ponovo podnositi ovaj zahtev. 2. Greška u parametrima zahteva. |
| 401 |
Trenutni zahtev zahteva korisničku verifikaciju. Ovaj odgovor mora sadržavati WWW-Authenticate informacije koje odgovaraju zahtevu resursa. Klijent može ponovo poslati zahtev koji sadrži validne Authorization header-e. Ako trenutni zahtev već uključuje Authorization akreditiv, tada 401 odgovor ukazuje da je server odbio proveru tih akreditiva. Ako 401 odgovor sadrži isti zahtev za verifikaciju kao u prethodnom odgovoru, a pretraživač je barem jednom pokušao verifikaciju, pretraživač treba prikazati entitet informacija sadržan u odgovoru, jer te informacije mogu sadržavati dijagnostičke informacije. Pogledajte RFC 2617. |
| 402 |
Ovaj status kod je rezervisan za moguće buduće zahteve. |
| 403 |
Server razume zahtev, ali ga odbija izvršiti. Za razliku od 401 odgovora, ovde verifikacija ne može pomoći i ovaj zahtev ne treba ponovo slati. Ako ovo nije HEAD zahtev, a server želi pojasniti zašto zahtev ne može biti izvršen, trebalo bi da opiše razlog odbijanja unutar entiteta. Naravno, server može da vrati 404 odgovor ako ne želi klijentu otkrivati bilo kakve informacije. |
| 404 |
Zahtev nije uspeo, željeni resurs nije pronađen na serveru. Nema informacija koje bi rekle korisniku da li je ovo stanje privremeno ili trajno. Ako server zna situaciju, trebao bi koristiti 410 status kod da obavesti korisnika da je stari resurs trajno nedostupan zbog nekih internih konfiguracijskih problema i da ne postoji mogućnost preusmeravanja. Status kod 404 se široko koristi kada server ne želi otkriti zašto je zahtev odbijen ili kada ne postoje drugi adekvatni odgovori dostupni. |
| 405 |
Metoda zahteva specificirana u zahtevu ne može biti korišćena za traženi resurs. Ovaj odgovor mora vratiti Allow header da označi listu metoda koje resurs može prihvatiti. S obzirom da PUT i DELETE metode vrše upisivanje operacija na resursima na serveru, većina web servera ne podržava ili po zadatom podešavanju ne dozvoljava te metode i vraća grešku 405. |
| 406 |
Sadržinski karakteristike zahtevanog resursa ne može zadovoljiti uslove u header-u zahteva, tako da se ne može generisati odgovor entiteta. Osim ako nije HEAD zahtev, ovaj odgovor bi trebao da vrati entitet koji sadrži listu svojstava entiteta koje korisnik ili pretraživač mogu da izaberu zajedno sa odgovarajućim adresama. Format entiteta se određuje tipom medija koji je definisan u Content-Type header. Pretraživači mogu automatski doneti najbolji izbor prema formatu i sopstvenim sposobnostima, ali, specifikacija ne definiše nijedan standard za ovakvo automatsko biranje. |
| 407 |
Slično 401 odgovoru, ali klijent mora verifikovati na proxy serveru. Proxy server mora vratiti Proxy-Authenticate za postavljanje verifikacije. Klijent može vratiti Proxy-Authorization header za verifikaciju. Pogledajte RFC 2617. |
| 408 |
Zahtev je istekao. Klijent nije završio slanje zahteva u okviru vremena koje je server spreman da čeka. Klijent može ponovo poslati zahtev u bilo kojem trenutku bez izmene. |
| 409 |
Zahtev ne može biti kompletiran zbog sukoba sa trenutnim stanjem resursa. Ovaj kod se može upotrebiti samo pod okolnostima da se smatra da korisnik može rešiti sukob i ponovo podneti novi zahtev. Ovaj odgovor treba sadržavati dovoljno informacija kako bi korisnik pronašao izvor sukoba. Sukobi obično nastaju tokom obrade PUT zahteva. Na primer, kada se u okruženju gde se koristi kontrola verzija, verzija informacija o PUT zahtevima koja su priložena sa izmenama određenog resursa sukobljavaju se sa prethodnim (trećim) zahtevom, tada server bi trebao vratiti 409 grešku da obavesti korisnika da zahtev ne može biti završen. Odgovor entiteta bi mogao sadržavati razlike između sukobljenih verzija, kako bi korisnik mogao ponovo poslati pregledni novi pregled nakon spajanja. |
| 410 |
Traženi resurs više nije dostupan na serveru i nema nikakvih poznatih adresا za preusmeravanje. To stanje se treba smatrati trajnim. Ako je to moguće, klijenti koji imaju mogućnost uređivanja linkova trebalo bi da obrišu sve reference ka toj adresi uz odobrenje korisnika. Ako server ne zna ili ne može da potvrdi da li je ova situacija trajna, onda bi trebao koristiti 404 status kod. Osim ako nije dodatno objašnjeno, ovaj odgovor se može keširati. Svrha 410 odgovora je primarno pomoći administratorima sajta u održavanju sajta obaveštavanjem korisnika da resurs više nije dostupan i da vlasnik servera želi da se uklone sve daleke konekcije koje vode ka resursu. Ovakvi događaji su veoma česti u ograničenim, vrednim uslugama. Takođe, 410 odgovor se koristi da obavesti klijenta da resurs koji pripada određenom korisniku više nije dostupan na trenutnom serveru. Naravno, da li da se označe svi trajno nedostupni resursi kao '410 Gone', i koliko dugo treba održavati ovu oznaku, u potpunosti zavisi od vlasnika servera. |
| 411 |
Server odbija da prihvati zahtev bez definisanog Content-Length header-a. Klijent može ponovo poslati zahtev nakon dodavanja validnog Content-Length header-a koji pokazuje dužinu poruke zahteva. |
| 412 |
Server nije zadovoljio jedno ili više preduvjeta koje su date u header-u zahteva prilikom verifikacije. Ovaj status kod omogućava klijentima da postave preduvjete u meta informacijama (podacima iz header-a) kako bi izbegli primenu ovog zahteva na resurs van njegovih željenih sadržanja. |
| 413 |
Server odbija obradu trenutnog zahteva jer je veličina entitetskih podataka koju je zahtev poslao veća od granica koje server može ili želi obraditi. U ovakvim slučajevima, server može zatvoriti vezu da bi sprečio klijenta da nastavi slati ovaj zahtev. Ako je stanje privremeno, server bi trebao vratiti Retry-After header, kako bi obavestio klijenta za koliko vremena bi mogao ponovo probati. |
| 414 |
Dužina URI zahteva premašuje dužinu koju server može interpretirati, te server odbija da pruži uslugu ovom zahtevu. Ovo je retko, a obično se dešava kada se formu koja bi trebala koristiti POST metod pretvori u GET, uzrokujući predugo upitno string (Query String). URI ''crna rupa'', na primer, kad god preusmeravanje koristi staru URI kao deo nove URI, što vodi do predugog URI nakon više preusmeravanja. Klijent pokušava iskoristiti određene sigurnosne ranjivosti servera. Takvi serveri koriste fiksnu dužinu međuspremnika za čitanje ili operisanje zahteva URI; kada parametri nakon GET premaše određenu vrednost, može doći do prelivanja međuspremnika i izvršavanjем proizvoljnog koda. Serveri bez takvih ranjivosti trebali bi vratiti 414 status kod. |
| 415 |
Za trenutni metod zahteva i traženi resurs, entitet poslat u zahtevu nije u formatu koji server podržava, te je zahtev odbijen. |
| 416 |
Ako zahtev uključuje Range header, a bilo koji od navedenih podataka u Range ne poklapa se sa trenutnim raspoloživim opsegom resursa, a zahtev ne definiše If-Range header, server bi trebao vratiti 416 status kod. Ako Range koristi byte opseg, onda se ovo stanje odnosi na situaciju kada početna tačka kaoštarch of the requested data range premašuje dužinu trenutnog resursa. Server bi takođe trebao uključivati Content-Range header uz 416 status kod kako bi pokazao trenutnu dužinu resursa. Ovaj odgovor ne može koristiti multipart/byteranges kao svoj Content-Type. |
| 417 |
Data sadržana u Expect headeru ne može biti ispunjena od strane servera, ili server je proxy koji ima očigledne dokaze da očekivanja ne mogu biti ispunjena na sledećem čvoru na ruti. |
| 421 |
Broj veza iz trenutne IP adrese klijenta do servera prelazi maksimalni broj dopuštenih veza na serveru. Obično, ovde se IP adresa odnosi na adresu klijenta koju server vidi (kao što je adresa korisnikovog prolaza ili proxy servera). U ovom slučaju, proračun broja veza može uključivati više od jednog krajnjeg korisnika. |
| 422 |
Forma zahteva je korektna, ali zbog semantičkih grešaka ne može se odgovoriti. (RFC 4918 WebDAV) 423 Locked, trenutni resurs je zaključan. (RFC 4918 WebDAV) |
| 424 |
Zahtev je neuspeo zbog greške prilikom prethodnog zahteva, kao što je PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definisano u WebDav Advanced Collections draft-u, ali se ne pojavljuje u "WebDAV Sequential Collection Protocol" (RFC 3658). |
| 426 |
Klijent treba preći na TLS/1.0. (RFC 2817) |
| 449 |
Proširen od strane Microsoft-a, označava da zahtev treba da se ponovo izvrši nakon uspešnog završetka odgovarajuće akcije. |
| 500 |
Server je naišao na neočekivanu situaciju koja mu onemogućava izvršavanje zahteva. Obično, ovaj problem se desi kada se dogodi greška u kodu servera. |
| 501 |
Server ne podržava neku funkcionalnost koja je potrebna za trenutni zahtev. Kada server ne prepoznaje zahtev kao validnu metodu ili nije u mogućnosti da podrži zahtev za bilo koji resurs. |
| 502 |
Server koji radi kao gateway ili proxy je dobio nevalidan odgovor od uzlaznog servera dok je pokušavao da izvrši zahtev. |
| 503 |
Server trenutno ne može obraditi zahtev zbog privremenih problema sa održavanjem ili preopterećenja. Ova situacija je privremena i očekuje se da se usluga vrati posle nekog vremena. Ako se predviđa vreme zastoja, odgovor može sadržati Retry-After header da označi ovo vreme. Ako nije dato Retry-After obaveštenje, klijent bi trebao obraditi kao 500 odgovor. Napomena: postojanje status koda 503 ne implicira da server mora koristiti ga kada je preopterećen. Neki serveri jednostavno žele odbiti vezu sa klijentima. |
| 504 |
Server koji radi kao gateway ili proxy pokušava izvršiti zahtev, ali nije primao odgovor od uzlaznog servera (URI identifikovanog serverom, kao što su HTTP, FTP, LDAP) ili pomoćnog servera (kao što je DNS) na vreme. Napomena: neki proxy serveri mogu vratiti 400 ili 500 greške na vreme prekida DNS upita. |
| 505 |
Server ne podržava ili odbija podršku za verziju HTTP koja se koristi u zahtevu. Ovo implicira da server ne može ili ne želi koristiti istu verziju kao klijent. Odgovor bi trebao sadržavati entitet koji opisuje zašto verzija nije podržana i koje protokole server podržava. |
| 506 |
Prošireno od strane "Transparent Content Negotiation Protocol" (RFC 2295), označava da postoji unutrašnja greška u konfiguraciji servera: traženi resurs za pregovaranje je postavljen da koristi samoga sebe u transparentnom pregovaranju, što ga čini neodgovarajućim fokusom u jednoj pregovarajućoj transakciji. |
| 507 |
Server ne može pohraniti sadržaj koji je potreban da završi zahtev. Ovo se smatra privremenim stanjem. WebDAV (RFC 4918) |
| 509 |
Server je dostigao ograničenje propusnosti. Ovo nije zvanični status kod, ali se široko koristi. |
| 510 |
Politika koja je potrebna za pristup resursu nije ispunjena. (RFC 2774) |