| HTTP Status Kod |
Značenje Status Koda |
| 100 |
Klijent bi trebao nastaviti slati zahtjev. Ova privremena reakcija obavještava klijenta da je njegov dio zahtjeva primljen od strane servera i da još nije odbijen. Klijent bi trebao nastaviti slati preostali dio zahtjeva, ili, ako je zahtjev završen, ignorirati ovu reakciju. Server mora poslati konačnu reakciju klijentu nakon završetka zahtjeva. |
| 101 |
Server je razumio zahtjev klijenta i obavijestit će klijenta putem Upgrade zaglavlja da koristi drugačiji protokol za dovršetak ovog zahtjeva. Nakon slanja posljednjeg praznog reda za ovu reakciju, server će preći na protokole definirane u Upgrade zaglavlju. Slične mjere bi trebale biti poduzete samo kada je prelazak na novi protokol korisniji. Na primjer, prelazak na novu verziju HTTP-a koja je bolja od starije, ili prelazak na protokol koji podržava stvarne i sinkronizirane resurse. |
| 102 |
Status kod proširen od strane WebDAV (RFC 2518), koji predstavlja da će obrada biti nastavljena. |
| 200 |
Zahtjev je uspješan, a očekivana odgovarajuća zaglavlja ili tijelo podataka vratit će se s ovom reakcijom. |
| 201 |
Zahtjev je uspješno realiziran, a novi resurs je stvoren prema potrebama zahtjeva, a njegov URI je vraćen uz Location zaglavlje. Ako se potrebni resurs ne može odmah stvoriti, treba vratiti '202 Accepted'. |
| 202 |
Server je prihvatio zahtjev, ali ga još nije obradio. Kao što je moguće da bude odbijen, konačni zahtjev možda će se obraditi ili neće. U slučajevima gdje se radi asinkrono, nije lakšeg načina nego slati ovu status kod. Račun je namijenjen dopuštanju serveru da prihvati druge zahtjeve u vezi s obradom bez održavanja veze klijenta dok se obrada ne završi. Reakcija koja prihvaća obrađeni zahtjev i vraća 202 status kod trebala bi sadržavati informacije o trenutnom statusu obrade i pokazivač ka monitoru ili procjeni statusa kako bi korisnik mogao procijeniti je li operacija završena. |
| 203 |
Server je uspješno obradio zahtjev, ali povratni metapodaci tijela nisu u potpunosti određena na izvornom serveru, već su kopije iz lokalne ili treće strane. Trenutne informacije mogu biti podskup ili nadskup izvornog metapodatka. Na primjer, metapodaci koji sadrže resurs mogu učiniti originalnom serveru svjesnom viših informacija. Korisno je koristiti ovaj status kod samo u slučajevima gdje bi povratni kod bio 200 OK bez njega. |
| 204 |
Server je uspješno obradio zahtjev, ali ne treba vratiti nikakav sadržaj entiteta, te želi vratiti ažurirane metapodatke. Odgovor može sadržavati nove ili ažurirane metapodatke putem entitetskog zaglavlja. Ako postoje ovi metapodaci, trebali bi odgovarati traženim varijablama. Ako je klijent preglednik, preglednik bi trebao zadržati stranicu s koje je poslao zahtjev, bez promjene prikaza dokumenta, čak i ako prema specifikaciji nove ili ažurirane informacije trebaju biti primijenjene na dokument u aktivnom prikazu preglednika. Budući da 204 odgovor zabranjuje uključivanje tijela poruke, uvijek završava s prvim praznim redom nakon poruke. |
| 205 |
Server je uspješno obradio zahtjev i nije vratio nikakav sadržaj. Međutim, za razliku od 204 odgovora, odgovor sa ovim status kodom zahtijeva od zahtjeva da resetira prikaz dokumenta. Ova reakcija se obično koristi nakon prihvaćanja korisničkog unosa, odmah resetirajući obrazac kako bi korisniku olakšala započinjanje novog unosa. Kao i odgovor 204, ova reakcija također ima zabranjeno uključivanje tijela poruke i završava s prvim praznim redom nakon poruke. |
| 206 |
Server je već uspješno obradio dio GET zahtjeva. Ove reakcije se koriste u HTTP preuzimanju alata kao što su FlashGet ili Thunder, koji implementiraju pauzirano preuzimanje ili razdvajaju veliki dokument na više segmenata za istovremeno preuzimanje. Ovaj zahtjev mora sadržavati Range zaglavlje za označavanje raspona sadržaja koji klijent želi primiti, a može sadržavati i If-Range kao uvjet zahtjeva. Odgovor mora sadržavati sljedeće zaglavlje: Content-Range da označi raspon vraćenog sadržaja u ovoj reakciji; ako je Content-Type multipart/byteranges, svaka multipart sekcija mora sadržavati Content-Range za označavanje svog raspona sadržaja. Ako odgovor sadrži Content-Length, njegova vrijednost mora odgovarati stvarnom broju bajtova vraćenog sadržaja. Date, ETag i/ili Content-Location, ako isti zahtjev bi trebao vratiti 200 odgovor. Expires, Cache-Control, i/ili Vary, ako njihova vrijednost može biti drugačija od vrijednosti za druge odgovore sa istim varijablama. Ako je ovaj odgovor koristio If-Range snažnu provjeru predmemorije, onda ovaj odgovor ne bi trebao sadržavati druga entitetska zaglavlja; ako je zahtjev koristio If-Range slabu provjeru predmemorije, ovaj odgovor bi trebao zabraniti dodatna entitetska zaglavlja; to će spriječiti neslaganje između sadržaja predmemorije i ažuriranih entitetskih zaglavlja. U suprotnom, ovaj odgovor bi trebao sadržavati sva entitetska zaglavlja koja bi trebala biti vraćena s 200 odgovorm. |
| 207 |
Prošireni status kod od strane WebDAV (RFC 2518), koji predstavlja da će slijedeće tijelo poruke biti XML poruka i može sadržavati niz neovisnih kodova odgovora ovisno o prethodnim zahtjevima. |
| 300 |
Zahtjevani resurs ima niz opcija za povrat, svaki sa svojom specifičnom adresom i trgovinskim informacijama. Korisnik ili preglednik mogu odabrati preferiranu adresu za preusmjeravanje. Osim ako je ovo HEAD zahtjev, ovaj odgovor trebao bi uključivati entitet s popisom atributa i adresa resursa, kako bi korisnik ili preglednik mogli odabrati najprikladniju adresu za preusmjeravanje. Format ovog entiteta određuje format definiran sadržajem tipa. Preglednik može automatski odabrati najbolju opciju na temelju formata odgovora i sposobnosti preglednika. Naravno, RFC 2616 specifikacija ne definira kako bi takvo automatsko odabiranje trebalo funkcionirati. Ako server već ima preferirani povratni odabir, taj URI bi trebao biti naveden u Location; preglednik može uzeti ovu vrijednost kao adresu za automatsko preusmjeravanje. Osim ako nije dodatno specificirano, ovaj odgovor također je cache-iran. |
| 301 |
Zahtjevani resurs trajno je premješten na novu lokaciju, a buduće reference na ovaj resurs trebale bi koristiti jedan od URI-eva koji su vraćeni s ovim odgovorom. Ako je moguće, klijent s mogućnošću uređivanja poveznica trebao bi automatski promijeniti adresu zahtjeva na adresu pogodne iz odgovora servera. Osim ako nije dodatno specificirano, ovaj odgovor također je cache-iran. Nova trajna URI trebala bi biti vraćena u Location domeni odgovora. Osim ako je ovo HEAD zahtjev, entitet odgovora trebao bi sadržavati poveznicu na novu URI i sažeto objašnjenje. Ako to nije GET ili HEAD zahtjev, preglednik ne bi trebao automatski provoditi preusmjeravanje bez korisničke potvrde, jer bi uvjeti zahtjeva mogli promijeniti. Napomena: Za neke preglednike koji koriste HTTP/1.0 protokol, kad pošalju POST zahtjev i dobiju 301 odgovor, sljedeći preusmjereni zahtjev će postati GET način. |
| 302 |
Zahtjevani resurs sada privremeno odgovara zahtjevu s drugog URI. Budući da je ovo preusmjeravanje privremeno, klijent bi trebao nastaviti slati daljnje zahtjeve na izvorni URL. Ovaj odgovor može biti keširan samo ako je to eksplicitno navedeno u Cache-Control ili Expires. Novi privremeni URI trebali bi biti vraćeni u Location domeni odgovora. Osim ako je ovo HEAD zahtjev, entitet odgovora trebao bi sadržavati poveznicu na novu URI s kratkim objašnjenjem. Ako to nije GET ili HEAD zahtjev, preglednik ne bi trebao automatski provoditi preusmjeravanje bez korisničke potvrde, jer bi uvjeti zahtjeva mogli promijeniti. Napomena: Iako RFC 1945 i RFC 2068 specifikacija ne dopuštaju klijentima promjenu metode zahtjeva tijekom preusmjeravanja, mnoge postojeće preglednike tumače 302 odgovor kao 303 odgovor i koriste GET način da bi pristupili URI-ju navedenom u Location, ignorirajući izvorni metodu zahtjeva. Status kodovi 303 i 307 su dodani kako bi jasno definirali kakvu reakciju server očekuje od klijenta. |
| 303 |
Odgovor za trenutni zahtjev može se pronaći na drugom URI-ju, a klijent bi trebao pristupiti tom resursu koristeći GET. Ova metoda postoji prvenstveno kako bi se omogućila preusmjeravanja POST zahtjeva aktiviranih skriptom na novi resurs. Ovaj novi URI nije alternativna referenca na izvorni resurs. Osim toga, 303 odgovor je zabranjeno predmemorirati. Naravno, drugi zahtjev (preusmjeravanje) može biti keširan. Novi URI bi trebao biti vraćen u Location domeni odgovora. Osim ako je ovo HEAD zahtjev, entitet odgovora trebao bi sadržavati poveznicu na novu URI i kratko objašnjenje. Napomena: Mnogi preglednici prije verzije HTTP/1.1 ne mogu ispravno interpretirati 303 status. Ako je interakcija s ovim preglednicima bitna, 302 status kod bi trebao poslužiti, jer većina preglednika postupa s 302 odgovorom onako kako specifikacija zahtijeva od klijenta da postupa s 303 odgovorom. |
| 304 |
Ako klijent pošalje uvjetovani GET zahtjev koji je izdan i sadržaj dokumenta (od posljednjeg pristupa ili prema uvjetima zahtjeva) se nije promijenio, server bi trebao vratiti ovaj status kod. 304 odgovor zabranjuje uključivanje tijela poruke, pa stoga uvijek završava prvim praznim redom nakon zaglavlja poruke. Ovaj odgovor mora uključivati sljedeće zaglavlje: Date, osim ako server nema sat. Ako server bez sata također poštuje ova pravila, tada posrednički server i klijent mogu dodati polje Date na primljena zaglavlja odgovora (kao što je navedeno u RFC 2068), a mehanizam predmemorije će raditi normalno. ETag i/ili Content-Location, ako je isti zahtjev trebao vratiti 200 odgovor. Expires, Cache-Control, i/ili Vary, ako njihova vrijednost može biti različita od vrijednosti drugih, prethodnih odgovora za iste varijable. Ako je ovaj odgovor koristio snažnu provjeru predmemorije, ovaj odgovor ne bi trebao imati drugih entitetskih zaglavlja; inače (na primjer, ako je uvjetovani GET zahtjev koristio slabu provjeru predmemorije), ovaj odgovor ne bi trebao imati drugih entitetskih zaglavlja; to će spriječiti neslaganje između sadržaja predmemorije i ažuriranih entitetskih zaglavlja. Ako 304 odgovor označava da neka entitet nije u predmemoriji, tada sustav predmemorije mora ignorirati ovu reakciju i ponoviti zahtjev bez ograničenja. Ako se primi 304 odgovor koji zahtijeva ažuriranje nekog predmemoriranog zapisa, sustav predmemorije mora ažurirati cijeli unos kako bi odražavao sve vrijednosti ažuriranih polja u odgovoru. |
| 305 |
Zahtijevani resurs mora se pristupiti kroz određeni posrednički server. URI informacije za navedeni posrednički server će biti dane u Location domeni, a primatelj mora ponovo poslati pojedinačni zahtjev kroz taj posrednički server kako bi pristupio odgovarajućem resursu. Samo izvorni server može stvoriti 305 odgovor. Napomena: RFC 2068 ne specificira jasno da se 305 odgovor koristi za preusmjerenje pojedinačnog zahtjeva, i da ga može stvoriti samo izvorni server. Ignoriranje ovih ograničenja može rezultirati ozbiljnim sigurnosnim nedostacima. |
| 306 |
U najnovijoj specifikaciji, 306 status kod više nije u upotrebi. |
| 307 |
Zahtijevani resurs sada privremeno odgovara zahtjevu s različitog URI. Budući da je ovo preusmjeravanje privremeno, klijent bi trebao nastaviti slati daljnje zahtjeve na izvorni URL. Ovaj odgovor može biti keširan samo ako je to eksplicitno navedeno u Cache-Control ili Expires. Novi privremeni URI trebali bi biti vraćeni u Location domeni odgovora. Osim ako je ovo HEAD zahtjev, entitet odgovora trebao bi sadržavati poveznicu na novu URI s kratkim objašnjenjem. Budući da neki preglednici ne prepoznaju 307 odgovor, potrebno je dodati potrebne informacije kako bi korisnik razumio i poslao zahtjev na novu URI. Ako to nije GET ili HEAD zahtjev, preglednik ne bi trebao automatski provoditi preusmjeravanje bez korisničke potvrde, jer bi uvjeti zahtjeva mogli promijeniti. |
| 400 |
1. Semantička greška, trenutni zahtjev server ne može razumjeti. Klijent ne bi trebao ponovo poslati ovaj zahtjev bez izmjena. 2. Greška u parametrima zahtjeva. |
| 401 |
Trenutni zahtjev zahtijeva korisničku autentifikaciju. Ovaj odgovor mora sadržavati WWW-Authenticate zaglavlje za pitati korisničke informacije o zatraženom resursu. Klijent može ponovo poslati zahtjev s odgovarajućom Authorization informacijom. Ako trenutni zahtjev već uključuje autorizacijski certifikat, 401 odgovor predstavlja da server odbija te certifikate. Ako 401 odgovor sadrži isti upit za autentifikaciju kao prethodni odgovor, a preglednik je pokušao barem jednom autentifikaciju, preglednik bi trebao prikazati sadržaj entiteta koji se nalaze u odgovoru, jer može sadržavati korisne dijagnostičke informacije. Pogledajte RFC 2617. |
| 402 |
Ovaj status kod je rezerviran za moguću buduću potrebu. |
| 403 |
Server je razumio zahtjev, ali je odbio njegovo izvršenje. Za razliku od 401 odgovora, autentifikacija ne može pomoći, i ovaj zahtjev ne bi trebao biti ponovo poslan. Ako to nije HEAD zahtjev, a server želi objasniti zašto zahtjev nije moguća izvršiti, onda to treba biti opisano u entitetu. Naravno, server može vratiti 404 odgovor ako ne želi da klijent dobije bilo kakve informacije. |
| 404 |
Zahtjev nije uspio, zatraženi resurs nije pronađen na serveru. Nema informacija koje bi rekle korisniku je ovaj status privremen ili trajno. Ako je server svjestan situacije, trebao bi koristiti 410 status kod da obavijesti o tome da je stari resurs trajno neaktivan zbog nekih internih konfiguracijskih problema, i da nema adrese na koju može preusmjeriti. Status kod 404 je široko korišten kada server ne želi otkriti zašto je zahtjev odbijen ili kada nema alternativnih odgovora. |
| 405 |
Metoda zahtjeva koja je navedena u zahtjevnoj liniji nije dozvoljena za iste resurse. Ovaj odgovor mora sadržavati Allow zaglavlje kako bi prikazao popis metoda koje se mogu koristiti za trenutne resurse. Budući da metode PUT i DELETE uključuju pisanje na resurse na serveru, većina web servera ne podržava ili ne dopušta te metode u zadanoj konfiguraciji, pa će takvi zahtjevi završiti s 405 greškom. |
| 406 |
Osobine sadržaja traženog resursa ne mogu zadovoljiti uvjete navedene u zahtjevnom zaglavlju, zbog čega nije moguće generiranje entitetskog odgovora. Osim ako to nije HEAD zahtjev, ovaj odgovor bi trebao vratiti entitet koji sadrži alternativne entitete i adrese koje korisnik ili preglednik mogu odabrati. Format ovog entiteta određuje vrsta sadržaja definirana zaglavljem Content-Type. Preglednik može automatski odabrati najbolju opciju na temelju formata i vlastitih mogućnosti. Međutim, specifikacije ne definiraju standard za takvo automatsko odabiranje. |
| 407 |
Slično 401 odgovoru, osim što klijent mora potvrditi na posredničkom serveru. Posrednički server mora vratiti Proxy-Authenticate da zatraži potvrdu. Klijent može poslati Proxy-Authorization zaglavlje za autentifikaciju. Pogledajte RFC 2617. |
| 408 |
Zahtjev je istekao. Klijent nije uspio poslati zahtjev u vremenu koje je server bio spreman čekati. Klijent može ponovo poslati ovaj zahtjev u bilo kojem trenutku bez ikakvih izmjena. |
| 409 |
Zahtjev nije mogao biti dovršen zbog sukoba sa trenutnim stanjem resursa. Ovaj kod se može koristiti samo kada se smatra da korisnik može riješiti sukob, i ponovo poslat novu zahtjev. Ovaj odgovor treba sadržavati dovoljno informacija kako bi korisnik mogao utvrditi izvor sukoba. Sukobi obično nastaju u obradi PUT zahtjeva. Na primjer, u okruženju koje koristi provjeru verzije, promjena koja se pokušava izvršiti na određenom resursu može se sukobiti sa verzijom koja se dodaje u prethodni zahtjev; u tom slučaju server bi trebao poslati 409 grešku kako bi obavijestio korisnika da zahtjev nije mogao biti realiziran. U tom slučaju, entitet odgovora bi vjerojatno sadržavao usporedbe između dviju sukobljenih verzija kako bi korisnik mogao ponovo poslati novi, pomireni verziju. |
| 410 |
Zatraženi resurs više nije dostupan na serveru, a nije poznata nijedna poznata referenca za preusmjeravanje. Ova situacija bi trebala biti smatrana trajnom. Ako je moguće, posjednici poveznica bi trebali, uz dopuštenje korisnika, izbrisati sve reference na ovu adresu. Ako server nije siguran ili ne može odrediti je li ova situacija trajna, tada bi trebao koristiti 404 status kod. Osim ako nije dodatno objašnjeno, ovaj odgovor je keširan. Cilj 410 odgovora je pomoći administratorima web stranica, obavijestiti korisnike da resurs više nije dostupan, i da vlasnici servera žele da sve daljinske veze na ovaj resurs također budu uklonjene. Ove se situacije često događaju u vremenskim ili unaprijeđenim uslugama. Također, 410 odgovor se također koristi da obavijestite klijente da resurs koji je nekada pripadao fizičkoj osobi više nije dostupan. Naravno, hoće li svi trajno neaktivan resursi biti označeni kao '410 Gone', i koliko dugo će se ova oznaka održati, ovisi isključivo o vlasniku servera. |
| 411 |
Server odbija primiti zahtjev bez definiranja Content-Length zaglavlja. Nakon dodavanja valjanog Content-Length zaglavlja koje označava dužinu tijela zahtjeva, klijent može ponovo poslati taj zahtjev. |
| 412 |
Server nije uspio zadovoljiti jedan ili više preduvjeta koja su postavljena u zaglavljima zahtjeva. Ovaj status kod omogućava klijentima da postave preduvjete u metainformacijama zahtjeva (podaci zaglavlja) pri dobivanju resursa, kako bi izbjegli da se ta metoda zahtjeva primjenjuje na resurse izvan onih koje žele obraditi. |
| 413 |
Server odbija procesuirati trenutni zahtjev jer je veličina entitetskih podataka koji je poslan premašila raspon koji server želi ili može obraditi. U ovoj situaciji, server može zatvoriti vezu kako bi spriječio klijenta da nastavi slati ovaj zahtjev. Ako je ova situacija privremena, server bi trebao vratiti Retry-After zaglavlje kako bi obavijestio klijenta kada može pokušati ponovno. |
| 414 |
Dužina URI-ja za zahtjev premašuje dužinu koju server može obraditi, stoga server odbija poslužiti taj zahtjev. Ovo je rijetko, obično se događa kada se POST metoda zahtjeva ne koristi u skladu s njenom prirodnom ulogom, tako da postane GET metoda, uzrokujući prenapučen upit. Na primjer, redirekcijski URI “crna rupa”, gdje svaki redirekcijski URI uključuje stari URI kao dio novog URI, uzrokuje produženo izvršenje redirekcije. Klijent može pokušati iskoristiti određene sigurnosne propuste na serveru. Takvi serveri koriste fiksne dužine za spremanje URI-ja, premda neki od njih moga privremeno doseći višak, što može rezultirati prekoračenjem podataka i pokretanjem proizvoljnog koda. Serveri bez ovog tipa propusta trebaju vratiti 414 status kod. |
| 415 |
Za trenutnu metodu zahtjeva i zatraženi resurs, entitet poslan u zahtjevu nije u formatu koji server podržava, stoga je zahtjev odbijen. |
| 416 |
Ako zahtjev uključuje Range zahtjev zaglavlje, i bilo koji od navedenih podataka u rasponu ne odgovara dostupnom rasponu trenutnog resursa, a u zahtjevu nije definirano If-Range zaglavlje, server bi trebao vratiti 416 status kod. Ako Range koristi byte raspon, to će značiti da je početna pozicija raspona svih zatraženih bajtova iznad dužine trenutnog resursa. Server bi također trebao uključivati Content-Range entitetsko zaglavlje uz 416 status kod kako bi naznačio trenutnu dužinu resursa. Ova reakcija također zabranjuje korištenje multipart/byteranges kao svoj Content-Type. |
| 417 |
Sadržaj naveden u zahtjeva Expect zaglavlju ne može se zadovoljiti od strane servera, ili je server posrednik i ima očite dokaze da se Expect sadržaj ne može zadovoljiti na sljedećem čvoru na putu. |
| 421 |
Broj veza s trenutnog IP adrese klijenta premašuje maksimalan broj koji server dopušta. Uobičajeno, ovaj IP adresu označava onu koju server vidi kao adresu klijenta (npr. adresa korisničkog gatewaya ili proxy servera). U ovoj situaciji, broj veza može uključivati više od jednog krajnjeg korisnika. |
| 422 |
Zahtjev odgovara ispravnom formatu, ali ne može biti obraditi zbog semantičke greške. (RFC 4918 WebDAV) 423 Lock trenutni resurs je zaključan. (RFC 4918 WebDAV) |
| 424 |
Trenutni zahtjev neuspješno zbog greške u prethodnom zahtjevu, na primjer, PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definira se u WebDav Advanced Collections nacrtu, ali se ne pojavljuje u "WebDAV Sequencing Protocol" (RFC 3658). |
| 426 |
Klijent bi trebao preći na TLS/1.0. (RFC 2817) |
| 449 |
Proširen od strane Microsofta, predstavlja da bi zahtjev trebao biti ponovo poslan nakon što se primjereni operacija izvrši. |
| 500 |
Server je naišao na neočekivanu situaciju koja ga je spriječila da obradi zahtjev. Općenito, ovaj problem se pojavljuje kada je došlo do greške u kodu servera. |
| 501 |
Server ne podržava neku funkcionalnost potrebnu za trenutni zahtjev. Kada server ne prepoznaje metodu zahtjeva, i ne može provesti njezin zahtjev na bilo koji resurs. |
| 502 |
Server, koji funkcionira kao posrednik ili proxy, dobio je neispravno odgovor od uzlaznog servera tijekom pokušaja izvršenja zahtjeva. |
| 503 |
Server trenutačno ne može obraditi zahtjev zbog privremene održavanja servera ili preopterećenja. Ova situacija je privremena i trebala bi se obnoviti nakon nekog vremena. Ako se vrijeme odgađanja može predvidjeti, odgovor može sadržavati Retry-After zaglavlje da navedete taj vremenski period. Ako nema informacija o Retry-After, klijent bi trebao obraditi to na način koji se koristi za obradu 500 odgovora. Napomena: Postojanje 503 status koda ne znači da server mora koristiti ga kada je preopterećen. Neki serveri jednostavno žele odbiti vezu klijenta. |
| 504 |
Kao posrednik ili proxy server, pokušava izvršiti zahtjev, a nije mogao pravovremeno primiti odgovor od uzlaznog servera (servera označenog URI-jem, kao što su HTTP, FTP, LDAP) ili pomoćnog servera (npr. DNS). Napomena: Neki proxy serveri vraćaju 400 ili 500 greške kada dođe do vremenskog ograničenja DNS upita. |
| 505 |
Server ne podržava, ili odbija podržati verziju HTTP-a korištenu u zahtjevu. Ovo ukazuje 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širen od strane "Transparent Content Negotiation Protocol" (RFC 2295), predstavlja internu konfiguracijsku grešku na serveru: zatraženi izvor za pregovaranje je konfiguriran za korištenje sebe unutar transparentnog pregovaranja, te nije prikladan fokus za jednu pregovaranje. |
| 507 |
Server ne može pohraniti sadržaj potreban za dovršavanje zahtjeva. Ova situacija se smatra privremenom. WebDAV (RFC 4918) |
| 509 |
Server je dosegao ograničenje propusnosti. Ovo nije službeni status kod, ali se i dalje široko koristi. |
| 510 |
Politika potrebna za dobivanje resursa nije ispunjena. (RFC 2774) |