| Codul de stare HTTP |
Semnificația codului de stare |
| 100 |
Clientul ar trebui să continue să trimite cererea. Acest răspuns temporar este folosit pentru a informa clientul că o parte din cererea sa a fost primită de server și nu a fost încă refuzată. Clientul ar trebui să continue să trimită restul cererii sale, sau dacă cererea a fost finalizată, să ignore acest răspuns. Serverul trebuie să trimită un răspuns final clientului după finalizarea cererii. |
| 101 |
Serverul a înțeles cererea clientului și va informa clientul prin antetul Upgrade pentru a utiliza un protocol diferit pentru a finaliza această cerere. După ce a trimis această ultimă linie goală, serverul va schimba la protocolele definite în antetul Upgrade. Aceasta ar trebui să fie făcută doar atunci când schimbarea la un protocol nou oferă beneficii clare. De exemplu, trecerea la o nouă versiune HTTP poate fi mai avantajoasă decât versiunea veche, sau trecerea la un protocol în timp real și sincronizat pentru a transmite resurse care utilizează astfel de caracteristici. |
| 102 |
Codul de stare extins de WebDAV (RFC 2518) care semnifică că procesarea va continua. |
| 200 |
Cererea a fost finalizată cu succes, anteturile sau corpul de date așteptat vor fi returnate împreună cu acest răspuns. |
| 201 |
Cererea a fost implementată și a fost creat un nou resource conform cerințelor cererii, iar URI-ul său a fost trimis în antetul Location. În cazul în care resursa necesară nu poate fi creată imediat, ar trebui să se returneze '202 Accepted'. |
| 202 |
Serverul a acceptat cererea, dar nu a procesat-o încă. Deși poate fi refuzată, cererea finală poate sau nu să fie executată. În cazul operațiunilor asincrone, nu există o modalitate mai convenabilă decât trimiterea acestui cod de stare. Scopul răspunsului care returnează codul de stare 202 este de a permite serverului să accepte cererile pentru alte procese (de exemplu, o operațiune bazată pe loturi care se execută o dată pe zi), fără a necesita ca clientul să mențină o conexiune deschisă cu serverul până când toate operațiunile sunt complet finalizate. Răspunsul care acceptă procesarea cererii și returnează codul de stare 202 ar trebui să includă în entitatea returnată informații care indică starea curentă a procesării și indicii către un monitor sau previzualizarea stării procesării, astfel încât utilizatorul să poată evalua dacă operația a fost finalizată. |
| 203 |
Serverul a procesat cu succes cererea, dar metainformațiile din entitatea returnată nu sunt un set de date valid de la serverul original, ci sunt o copie locală sau de la un terț. Informațiile actuale ar putea fi un subset sau un superset al versiunii originale. De exemplu, metadatele resursei ar putea determina serverul original să recunoască metainformațiile superioare. Utilizarea acestui cod de stare nu este obligatorie și ar trebui să fie utilizată doar atunci când răspunsul ar returna 200 OK fără acest cod de stare. |
| 204 |
Serverul a procesat cu succes cererea, dar nu este necesar să returneze conținut de entitate și își propune să returneze metainformații actualizate. Răspunsul poate returna noi sau actualizate metainformații prin intermediul antetelor entității. Dacă aceste antete există, ar trebui să fie corelate cu variabilele solicitate. Dacă clientul este un browser, browserul utilizatorului ar trebui să mențină pagina care a trimis cererea, fără a provoca modificări în vizibilitatea documentului, chiar dacă în conformitate cu specificațiile noile sau actualizările metainformațiilor ar trebui aplicate în documentul vizibil al browserului utilizatorului. Deoarece răspunsul 204 este interzis să conțină un corp de mesaj, acesta se încheie întotdeauna cu prima linie goală după anteturile de mesaj. |
| 205 |
Serverul a procesat cu succes cererea și nu a returnat niciun conținut. Dar spre deosebire de răspunsul 204, răspunsul cu acest cod de stare cere solicitantului să reseteze vizualizarea documentului. Acest răspuns este de regulă folosit pentru a restitui un formular imediat după acceptarea input-ului utilizatorului, astfel încât utilizatorul să poată începe o nouă introducere. Similar cu răspunsul 204, acest răspuns este interzis să conțină un corp de mesaj și se termină cu prima linie goală după anteturile de mesaj. |
| 206 |
Serverul a procesat cu succes o parte din cererea GET. Instrumente HTTP de descărcare cum ar fi FlashGet sau Thunder folosesc acest tip de răspuns pentru a realiza descărcări continue sau pentru a descompune un document mare în segmente mai mici pentru descărcare simultană. Cererea trebuie să conțină antetul Range pentru a indica intervalul de conținut dorit de client și poate conține If-Range ca condiție pentru solicitare. Răspunsul trebuie să conțină următoarele domenii de antet: Content-Range pentru a indica intervalul de conținut returnat în acest răspuns; dacă este Content-Type de tip multipart/byteranges pentru descărcări multiple, fiecare multipart trebuie să conțină domeniul Content-Range pentru a indica intervalul de conținut. Dacă răspunsul include Content-Length, atunci valoarea sa trebuie să corespundă numărului real de octeți corespunzători intervalului de conținut returnat. Datele, ETag și/sau Content-Location, dacă aceeași cerere ar trebui să returneze un răspuns 200. Expires, Cache-Control și/sau Vary, dacă valorile lor ar putea diferi de cele ale altor răspunsuri corespunzătoare variabilelor anterioare. Dacă această cerere a fost făcută folosind validarea cache-ului If-Range puternic, atunci acest răspuns nu ar trebui să conțină alte antete de entitate; dacă această cerere a fost făcută folosind validarea cache-ului If-Range ușor, atunci acest răspuns este interzis să conțină alte antete de entitate; acest lucru evită inconsistențele între conținuturile de entitate din cache și antetele de entitate actualizate. Altfel, acest răspuns ar trebui să includă toate domeniile de antete de entitate care ar trebui să fie returnate de un răspuns 200. Dacă antetele ETag sau Last-Modified nu se potrivesc exact, atunci cache-ul clientului ar trebui interzis să combine conținutul răspunsului 206 cu orice conținut cache-uit anterior. Orice cache care nu suportă anteturile Range și Content-Range este interzis să cache-uiească conținutul returnat pentru 206. |
| 207 |
Codul de stare extins de WebDAV (RFC 2518) care semnifică că mesajul de răspuns va fi un mesaj XML și poate include o serie de coduri de răspuns independente, în funcție de numărul de subcereri anterioare. |
| 300 |
Resursa solicitată are o serie de informații de opțiune, fiecare cu propria adresă și informații comerciale controlate de browser. Utilizatorul sau browserul poate alege un adresa preferată către care să se redirecționeze. Cu excepția cazului în care acesta este o cerere HEAD, răspunsul ar trebui să includă o entitate care conține o listă de caracteristici ale resursei și adresele pentru utilizator sau browser de a alege cea mai adecvată adresă de redirecționare. Formatul acestei entități este determinat de formatul definit de Content-Type. Browserul ar putea să facă o alegere automată bazată pe formatul răspunsului și capabilitățile sale. Desigur, standardul RFC 2616 nu specifică cum să se efectueze o selecție automată. Dacă serverul are o alegere preferată pentru răspuns, acea URI preferată ar trebui să fie indicată în Location; browserul poate utiliza această valoare Location ca adresă de redirecționare automată. De asemenea, cu excepția cazului în care este specificat în mod explicit, acest răspuns este și cache-uibil. |
| 301 |
Resursa solicitată a fost mutată permanent la o nouă locație și orice referință viitoare la această resursă ar trebui să utilizeze unul din mai multe URI-uri returnate în acest răspuns. Dacă este posibil, clienții care au funcții de modificare a linkurilor ar trebui să-și actualizeze automat adresă cerută la adresa returnată de server. Cu excepția cazului în care este specificat în mod explicit, acest răspuns este și cache-uibil. Noua URI permanentă ar trebui să fie returnată în domeniul Location al răspunsului. Cu excepția cazului în care aceasta este o cerere HEAD, răspunsul ar trebui să conțină un hyperlink către noua URI și o descriere scurtă în entitate. Dacă aceasta nu este o cerere GET sau HEAD, atunci browserul interzice redirecționarea automată, cu excepția cazului în care obține confirmarea utilizatorului, deoarece condițiile cererii ar putea fi modificate. Atenție: pentru unele browsere care folosesc protocolul HTTP/1.0, atunci când trimite o cerere POST și primește un răspuns 301, cererea de redirecționare care urmează va deveni cerere GET. |
| 302 |
Resursa solicitată răspunde acum temporar la o cerere de URI diferit. Deoarece această redirecționare este temporară, clientul ar trebui să continue să trimită cereri către adresa originală în viitor. Acest răspuns este cache-uibil doar dacă este specificat în Cache-Control sau Expires. Noua URI temporară ar trebui să fie returnată în domeniul Location al răspunsului. Cu excepția cazului în care aceasta este o cerere HEAD, răspunsul ar trebui să conțină un hyperlink către noua URI și o descriere scurtă în entitate. Dacă aceasta nu este o cerere GET sau HEAD, atunci browserul interzice redirecționarea automată, cu excepția cazului în care obține confirmarea utilizatorului, deoarece condițiile cererii ar putea fi modificate. Atenție: deși standardele RFC 1945 și RFC 2068 nu permit clientului să schimbe metoda cererii la redirecționare, multe browsere existente consideră răspunsurile 302 ca răspunsuri 303 și folosesc metoda GET pentru a accesa URI specificat în Location, ignorând metoda cererii originale. Statele 303 și 307 au fost adăugate pentru a clarifica ceea ce serverul se așteaptă de la reacția clientului. |
| 303 |
Răspunsul la cererea curentă poate fi găsit la o altă URI, și clientul ar trebui să acceseze acea resursă folosind metoda GET. Această metodă există pentru a permite redirecționarea rezultatelor cererilor POST activate de scripturi către o nouă resursă. Noua URI nu este o referință alternativă pentru resursa originală. În plus, răspunsul 303 este interzis să fie cache-uit. Desigur, a doua cerere (redirecționare) poate fi cache-uită. Noua URI ar trebui să fie returnată în domeniul Location al răspunsului. Cu excepția cazului în care aceasta este o cerere HEAD, răspunsul ar trebui să conțină un hyperlink către noua URI și o descriere scurtă în entitate. Atenție: multe browsere din versiunile anterioare ale HTTP/1.1 nu pot înțelege corect codul de stare 303. Dacă este necesar să se adreseze aceste browsere, codul de stare 302 ar trebui să fie adecvat, deoarece majoritatea browserelor tratează răspunsurile 302 exact așa cum specifica standardul că clientul ar trebui să trateze răspunsurile 303. |
| 304 |
Dacă clientul a trimis o cerere GET condiționată și cererea a fost acceptată, iar conținutul documentului (de la ultima vizitare sau conform condițiilor cererii) nu s-a schimbat, atunci serverul ar trebui să returneze acest cod de stare. Răspunsul 304 interzice includerea unui corp de mesaj și se termină întotdeauna cu prima linie goală după anteturile de mesaj. Răspunsul trebuie să conțină următoarele antete: Date, cu excepția cazului în care serverul nu are un ceas. Dacă serverul fără ceas respectă aceste reguli, serverele proxy și clientul pot adăuga de sine-dizvolte câmpul Date în anteturile răspunsului recepționat (așa cum este stipulat în RFC 2068) și mecanismul pentru cache va funcționa normal. ETag și/sau Content-Location, dacă aceeași cerere ar trebui să returneze un răspuns 200. Expires, Cache-Control și/sau Vary, dacă valorile lor ar putea diferi de valorile corespunzătoare ale altor răspunsuri conform variabilelor anterioare. Dacă această cerere a utilizat validarea cache-ului If-Range puternic, atunci acest răspuns nu ar trebui să conțină alte antete de entitate; altfel (de exemplu, folosind validarea cache-ului If-Range slab pentru o cerere GET condiționată), acest răspuns nu ar trebui să conțină alte antete de entitate; acest lucru evită inconsistențele între conținuturile de entitate din cache și antetele de entitate actualizate. Dacă un răspuns 304 indică faptul că un anumit conținut nu este în cache, atunci sistemul de cache trebuie să ignore acest răspuns și să retrimită o cerere fără condiții de limitare. Dacă se primește un răspuns 304 care necesită actualizarea unui element din cache, sistemul de cache trebuie să actualizeze întregul element pentru a reflecta toate câmpurile actualizate în răspuns. |
| 305 |
Resursa solicitată trebuie accesată prin intermediul unui proxy specificat. În domeniul Location se va oferi informații despre URI-ul locatorului. Aceasta este necesar pentru ca utilizatorul să retrimită o cerere separată, dar doar prin acea adresă. Doar serverul original poate genera un răspuns 305. Atenție: RFC 2068 nu clarifică suficient că răspunsul 305 este destinat redirecționării unei cereri separate și doar serverul original poate genera un astfel de răspuns. Ignorarea acestor restricții poate duce la consecințe severe din punct de vedere al securității. |
| 306 |
În cele mai recente specificații, codul de stare 306 nu mai este utilizat. |
| 307 |
Resursa solicitată răspunde acum temporar la o cerere de URI diferit. Deoarece această redirecționare este temporară, clientul ar trebui să continue să trimită cereri către adresa originală în viitor. Acest răspuns este cache-uibil doar dacă este specificat în Cache-Control sau Expires. Noua URI temporară ar trebui să fie returnată în domeniul Location al răspunsului. Cu excepția cazului în care aceasta este o cerere HEAD, răspunsul ar trebui să conțină un hyperlink către noua URI și o descriere scurtă în entitate. Deoarece unele browsere nu pot recunoaște răspunsul 307, sunt necesare informațiile anterioare pentru a ajuta utilizatorul să înțeleagă și să trimită cererea către noua URI. Dacă aceasta nu este o cerere GET sau HEAD, atunci browserul interzice redirecționarea automată, cu excepția cazului în care obține confirmarea utilizatorului, deoarece condițiile cererii ar putea fi modificate. |
| 400 |
1. Semnificație greșită, cererea curentă nu poate fi înțeleasă de server. Exceptând modificările, clientul nu ar trebui să retrimită această cerere. 2. Parametrii cererii sunt greșiți. |
| 401 |
Cererea curentă necesită autentificarea utilizatorului. Răspunsul trebuie să conțină o antet WWW-Authenticate aplicabil pentru resursa solicitată, solicitând informații despre utilizator. Clientul poate retrimite o cerere cu antetul Authorization corespunzător. Dacă cererea curentă a inclus un certificat de autorizare, atunci răspunsul 401 reprezintă o respingere a acelui certificat de către server. Dacă răspunsul 401 conține aceeași întrebare de autentificare ca răspunsul anterior, iar browserul a încercat să autentifice cel puțin o dată, atunci browserul ar trebui să prezinte utilizatorului entitatea de informații conținută în răspuns, deoarece aceasta ar putea include informații de diagnostic relevante. Consultați RFC 2617. |
| 402 |
Această cod de stare este rezervat pentru cerințe potențiale viitoare. |
| 403 |
Serverul a înțeles cererea, dar o refuză. Spre deosebire de răspunsul 401, autentificarea nu va ajuta în acest caz, iar cererea nu ar trebui să fie repetată. Dacă aceasta nu este o cerere HEAD și serverul dorește să clarifice de ce cererea nu poate fi executată, ar trebui să descrie motivul refuzului în entitate. Desigur, serverul poate returna un răspuns 404, dacă nu dorește să ofere informații suplimentare clientului. |
| 404 |
Cererea a eșuat, resursa așteptată nu a fost găsită pe server. Nu există informații care să spună utilizatorului dacă această situație este temporară sau permanentă. Dacă serverul știe despre situație, atunci ar trebui să utilizeze codul de stare 410 pentru a informa utilizatorul că resursa veche nu mai este disponibilă din cauza unor probleme interne de configurare și că nu există o adresă unde să redirecționeze solicitările. Codul de stare 404 este pe larg utilizat atunci când serverul nu vrea să dezvăluie de ce cererea a fost refuzată sau nu există alte răspunsuri adecvate disponibile. |
| 405 |
Metoda de cerere specificată în linia de cerere nu poate fi utilizată pentru a solicita resursa corespunzătoare. Răspunsul trebuie să includă o antet Allow pentru a lista metodele de cerere care sunt acceptate de resursa curentă. Având în vedere că metodele PUT și DELETE efectuează operații de scriere asupra resurselor de pe server, majoritatea serverelor web nu suportă aceste metode în mod local sau nu le permit în configurația default, reduceri care în general generează un răspuns de eroare 405. |
| 406 |
Caracteristicile de conținut ale resursei solicitate nu pot satisface condițiile din antetul cererii, prin urmare nu se poate genera un răspuns. Cu excepția cazului în care aceasta este o cerere HEAD, acest răspuns ar trebui să returneze o entitate care conține o listă de caracteristici de entitate și adrese pe care utilizatorul sau browserul să le aleagă. Formatul entității este determinat de tipul media definit în antetul Content-Type. Browserul poate face alegerea optimă în funcție de format și capacitățile lor. Totuși, standardul nu definește nici un standard pentru astfel de selecții automate. |
| 407 |
Similar cu răspunsul 401, dar clientul trebuie să se autentifice pe un proxy server. Proxy-ul trebuie să returneze un antet Proxy-Authenticate pentru a solicita autentificarea. Clientul poate returna un antet Proxy-Authorization pentru a se autentifica. Consultați RFC 2617. |
| 408 |
Cererea a expirat. Clientul nu a finalizat trimiterea unei cereri în timpul pe care serverul era pregătit să aștepte. Clientul poate să trimită din nou această cerere fără vreo modificare. |
| 409 |
Cererea nu poate fi completată din cauza conflictelor cu starea curentă a resursei solicitate. Acest cod de stare este permis doar în circumstanțele în care utilizatorul poate rezolva conflictele și va retrimite o nouă cerere. Răspunsul ar trebui să conțină suficiente informații pentru ca utilizatorul să identifice sursa conflictului. Conflictele au loc de obicei în procesarea cererilor PUT. De exemplu, într-un mediu în care se aplică verificarea versiunii, o cerere PUT de modificare pentru o resursă specifică care include informații de versiune care conflictuează cu informațiile de versiune dintr-o cerere precedentă (de la un terț) ar trebui să returneze o eroare 409, informând utilizatorul că cererea nu poate fi îndeplinită. În această situație, entitatea răspunsului ar putea conține o comparație a diferențelor dintre cele două versiuni în conflict, permițând utilizatorului să retrimită o nouă versiune fuzionată. |
| 410 |
Resursa solicitată nu mai este disponibilă pe server și nu există nici o adresă de redirecționare cunoscută. Această situație ar trebui considerată ca fiind permanentă. Dacă este posibil, clienții care au funcții de modificare a linkurilor ar trebui să șteargă toate referințele la această adresă, după ce au obținut permisiunea utilizatorului. Dacă serverul nu știe sau nu poate să determine că această situație este permanentă, atunci ar trebui să folosească codul de stare 404. Cu excepția cazului în care este specificat în mod explicit, acest răspuns este cache-uibil. Scopul răspunsului 410 este, în principal, de a ajuta administratorii de site-uri să întrețină site-ul, informând utilizatorii că resursa nu mai este disponibilă și că deținătorul serverului dorește ca toate conexiunile externe care conduc la această resursă să fie eliminate. Această situație este frecvent întâlnită în cazul serviciilor cu termen limitat sau servicii suplimentare. De asemenea, răspunsul 410 este utilizat pentru a informa clienții că resursele care erau asociate cu un anumit utilizator nu mai sunt disponibile pe serverul curent. Desigur, dacă este necesar să se marcheze toate resursele care nu mai sunt disponibile ca '410 Gone' și cât timp ar trebui să se păstreze această marcă, depinde în totalitate de deținătorul serverului. |
| 411 |
Serverul refuză să accepte cererea fără un antet Content-Length definit. După ce a fost adăugat un antet Content-Length valid care indică lungimea corpului mesajului cererii, clientul poate retrimite cererea. |
| 412 |
Serverul nu a putut să satisfacă unul sau mai multe dintre condițiile prealabile care au fost date în câmpurile antetului cererii. |
| 413 |
Serverul refuză să proceseze cererea curentă, deoarece dimensiunea datelor entității trimise în cerere depășește limita pe care serverul este dispus sau capabil să o proceseze. În această situație, serverul poate închide conexiunea pentru a preveni clientul să continue să trimită această cerere. Dacă această situație este temporară, serverul ar trebui să returneze un antet Retry-After pentru a informa clientul când poate încerca din nou. |
| 414 |
URI-ul solicitat depășește lungimea pe care serverul este capabil să o interpreteze, astfel încât serverul refuză să proceseze cererea. Acest lucru se întâmplă rar, dar este frecvent întâlnit în următoarele situații: un formular care ar trebui să utilizeze metoda POST devine o cerere GET, provocând lungi șiruri de interogare (Query String). URI-urile de redirecționare „black hole”, de exemplu, în care fiecare redirecționare folosește vechiul URI ca parte a noului URI, provocând lungimi excesive ale URI-ului după mai multe redirecționări. Clienții încearcă să exploateze unele vulnerabilități de securitate prezente în servere. Aceste servere folosesc memory buffers cu lungimi fixe pentru a citi sau a acționa asupra URI-ului cererii, putând duce la o depășire a memoriei tampon, provocând astfel o executare a codului arbitrar. Serverele fără această vulnerabilitate ar trebui să returneze codul de stare 414. |
| 415 |
Pentru metoda cererii curente și resursa solicitată, entitatea trimisă nu este în formatul acceptat de server și, prin urmare, cererea a fost refuzată. |
| 416 |
Dacă cererea include un antet Range și orice interval specificat în Range nu se potrivește cu intervalul disponibil al resursei curente și cererea nu definește un antet If-Range, atunci serverul ar trebui să returneze codul de stare 416. Dacă Range folosește octeți, atunci această situație înseamnă că locul unde începe primul octet specificat pentru cerere depășește lungimea resursei curente. Serverul ar trebui, de asemenea, să includă un antet Content-Range pentru a indica lungimea curentă a resursei în timp ce returnează codul de stare 416. Acest răspuns nu ar trebui să folosească multipart/byteranges ca tip de conținut. |
| 417 |
Conținutul așteptat din antetul Expect nu a putut fi satisfăcut de server, sau serverul este un server proxy care are dovezi evidente că, la următorul nod de rutare, conținutul așteptat nu poate fi satisfăcut. |
| 421 |
Numărul de conexiuni simultane de la adresa IP curentă a clientului la server a depășit limita maximă permisă de server. De obicei, adresa IP se referă la adresa clientului vizibilă de pe server (de exemplu, adresa gateway-ului sau a serverului proxy). În această situație, numărul de conexiuni poate implica mai mult de un utilizator final. |
| 422 |
Formatul cererii este corect, însă din cauza unor erori semantice nu poate fi procesat. (RFC 4918 WebDAV) 423 Locked: resursa curentă este blocată. (RFC 4918 WebDAV) |
| 424 |
Un error în cererea anterioară a cauzat eșecul cererii curente, de exemplu PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definit în proiectul WebDav Advanced Collections, dar nu apare în „Protocolele ordonate WebDAV” (RFC 3658). |
| 426 |
Clientul ar trebui să treacă la TLS/1.0. (RFC 2817) |
| 449 |
Extins de Microsoft, reprezintă că cererea ar trebui să fie repetată după satisfacerea operațiunilor adecvate. |
| 500 |
Serverul a întâmpinat o situație neașteptată, care l-a determinat să nu poată îndeplini cererea. De obicei, această problemă apare atunci când există o eroare în codul serverului. |
| 501 |
Serverul nu suportă o funcționalitate necesară pentru cererea curentă. Când serverul nu recunoaște metoda cererii și nu este capabil să o susțină pentru nicio resursă. |
| 502 |
Serverul, care funcționează ca gateway sau proxy, a primit un răspuns invalid de la serverul din amonte în timp ce încerca să execute cererea. |
| 503 |
Serverul este temporar incapabil de a procesa cererea din cauza întreținerii sau a supraîncărcării. Acest lucru este temporar și se va recupera după un timp. Dacă se poate estima timpul de întârziere, răspunsul poate include un antet Retry-After pentru a indica acest timp de întârzire. Dacă această informație nietă Retry-After nu este oferită, clientul ar trebui să trateze răspunsul 500 în mod similar. Atenție: existența codului de stare 503 nu implică faptul că serverul ar trebui să-l folosească când este supraîncărcat. Unele servere pur și simplu doresc să refuze conexiunea clientului. |
| 504 |
Serverul, care funcționează ca gateway sau proxy, a eșuat să primească un răspuns în timp util de la serverul din amonte (serverul identificat prin URI, de exemplu HTTP, FTP, LDAP) sau un server auxiliar (de exemplu DNS). Atenție: unele servere proxy returnează erori 400 sau 500 în caz de timeout DNS. |
| 505 |
Serverul nu suportă sau refuză să susțină versiunea HTTP utilizată în cerere. Acest lucru sugerează că serverul nu poate sau nu dorește să folosească aceeași versiune ca clientul. Răspunsul ar trebui să includă o explicație referitoare la motivul pentru care versiunea nu este suportată și care protocoale sunt suportate de server. |
| 506 |
Extins de „Protocolul de negociere a conținutului transparent” (RFC 2295), se referă la o configurație internă a serverului: resursa negociată a fost configurată să se folosească pe ea însăși în negocierea transparentă, deci nu este un punct corespunzător într-o negociere. |
| 507 |
Serverul nu poate stoca conținutul necesar pentru a finaliza cererea. Această situație este considerată temporară. WebDAV (RFC 4918) |
| 509 |
Serverul a atins limita de lățime de bandă. Acesta nu este un cod de stare oficial, dar este în continuare folosit pe scară largă. |
| 510 |
Politicile necesare pentru a obține resursa nu au fost satisfăcute. (RFC 2774) |