| Codul de stare HTTP | Codul de stare Înțeles |
|---|
| 100 | Clientul trebuie să continue să trimită cereri. Acest răspuns temporar este utilizat pentru a informa clientul că o parte din cererea sa a fost primită de server și nu a fost respinsă. Clientul trebuie să continue să trimită restul cererii sau să ignore acest răspuns dacă cererea este completă. Serverul trebuie să trimită un răspuns final clientului atunci când cererea este completă. |
| 101 | Serverul a înțeles cererea clientului și va notifica clientul prin antetul mesajului Upgrade să utilizeze un protocol diferit pentru a finaliza cererea. După trimiterea ultimei linii goale din acest răspuns, serverul va trece la protocoalele definite în antetul mesajului Upgrade. Acest lucru trebuie făcut numai dacă este mai avantajos să se treacă la un protocol nou. De exemplu, trecerea la o versiune nouă a HTTP este mai avantajoasă decât o versiune mai veche sau trecerea la un protocol sincron și în timp real pentru a furniza resurse care profită de astfel de caracteristici. |
| 102 | Codurile de stare, extinse de WebDAV (RFC 2518), reprezintă faptul că procesarea va continua. |
| 200 | Cererea a fost acceptată, iar antetul de răspuns sau corpul de date dorit de cerere va fi returnat cu acest răspuns. |
| 201 | Cererea a fost îndeplinită și o nouă resursă a fost creată conform cerințelor cererii, iar URI-ul acesteia a fost returnat cu antetul Location. În cazul în care resursa solicitată nu poate fi creată în timp util, se returnează "202 Accepted". |
| 202 | Serverul a acceptat cererea, dar nu a procesat-o încă. La fel cum poate fi respinsă, în cele din urmă cererea poate fi executată sau nu. În contextul operațiunilor asincrone, nu există nimic mai convenabil decât trimiterea acestui cod de stare. Scopul returnării unui răspuns cu un cod de stare 202 este de a permite serverului să accepte cereri din partea altor procese (cum ar fi o operațiune pe loturi care se execută o singură dată pe zi) fără a fi nevoie să mențină clientul conectat la server până când operațiunea pe loturi este complet finalizată. Un răspuns care acceptă o cerere de procesare și returnează un cod de stare 202 TREBUIE să includă în entitatea returnată anumite informații care indică starea actuală a procesului, precum și un indicator către un monitor de stare a procesării sau o predicție de stare, astfel încât utilizatorul să poată estima dacă operațiunea a fost finalizată. |
| 203 | Serverul a procesat cu succes cererea, dar metainformațiile din antetul entității returnate nu sunt un set definitiv valabil pe serverul original, ci o copie de la o parte locală sau terță. Informațiile actuale pot fi un subset sau un supraset al versiunii originale. De exemplu, metadatele care conțin resurse pot face ca serverul original să cunoască super-informațiile meta. Utilizarea acestui cod de stare nu este obligatorie și este adecvată numai dacă răspunsul ar fi returnat 200 OK fără acesta. |
| 204 | Serverul a procesat cererea cu succes, dar nu trebuie să returneze niciun conținut fizic și dorește să returneze meta-informații actualizate. Răspunsul poate returna meta-informații noi sau actualizate sub formă de antete de entitate. Dacă există astfel de antete, acestea ar trebui să corespundă variabilelor solicitate. În cazul în care clientul este un browser, browserul utilizatorului TREBUIE să păstreze pagina pe care a fost trimisă solicitarea fără a modifica vizualizarea documentului, chiar dacă, în conformitate cu specificațiile, meta-informațiile noi sau actualizate TREBUIE să fie aplicate documentului în vizualizarea activă a browserului utilizatorului. Deoarece răspunsul 204 nu poate conține niciun corp de mesaj, acesta se încheie întotdeauna cu prima linie goală după antetul mesajului. |
| 205 | Serverul a procesat cu succes cererea și nu a returnat nimic. Cu toate acestea, spre deosebire de răspunsul 204, răspunsul care returnează acest cod de stare cere solicitantului să reseteze vizualizarea documentului. Acest răspuns este utilizat în primul rând pentru a reseta formularul imediat după acceptarea datelor introduse de utilizator, astfel încât utilizatorul să poată începe cu ușurință o altă intrare. La fel ca răspunsul 204, acest răspuns nu poate conține niciun corp de mesaj și se încheie cu prima linie goală după antetul mesajului. |
| 206 | Serverul a procesat cu succes o parte din cererea GET. Instrumentele de descărcare HTTP precum FlashGet sau Thunderbolt utilizează acest tip de răspuns pentru a efectua descărcări intermitente sau pentru a împărți un document mare în mai multe segmente de descărcare în același timp. Cererea trebuie să conțină un antet Range pentru a indica intervalul de conținut pe care clientul dorește să îl primească și poate conține un If-Range ca o condiție a cererii. Răspunsul trebuie să conțină următoarele câmpuri de antet: Content-Range pentru a indica domeniul de aplicare al conținutului returnat în acest răspuns; în cazul unei descărcări multisegment cu un Content-Type de multipart/byteranges, fiecare segment multipartit trebuie să conțină un câmp Content-Range care să indice domeniul de aplicare al conținutului din segmentul respectiv. Dacă răspunsul conține un câmp Content-Length, valoarea acestuia trebuie să corespundă numărului real de octeți din intervalul de conținut returnat. date ETag și/sau Content-Location, dacă aceeași cerere ar fi trebuit să returneze un răspuns 200. Expires, Cache-Control și/sau Vary, dacă valorile acestora pot fi diferite de alte răspunsuri cu aceleași variabile. Expires, Cache-Control și/sau Vary, dacă valorile lor pot fi diferite de valorile altor răspunsuri anterioare pentru aceleași variabile. Acest răspuns NU TREBUIE să conțină alte antete de entitate în cazul în care cererea utilizează validarea puternică a memoriei cache If-Range și NU TREBUIE să conțină alte antete de entitate în cazul în care cererea utilizează validarea slabă a memoriei cache If-Range; astfel se evită neconcordanțele între conținutul entității memorate în memorie cache și informațiile actualizate ale antetelor de entitate. În caz contrar, acest răspuns ar trebui să conțină toate câmpurile de antet de entitate care ar fi trebuit să fie returnate în toate răspunsurile 200 care ar fi trebuit să fie returnate. În cazul în care antetele ETag sau Last-Modified nu corespund exact, memoria cache de pe partea clientului ar trebui să interzică combinarea conținutului returnat în răspunsul 206 cu orice conținut anterior stocat în memorie cache. Orice cache care nu acceptă antetele Range și Content-Range nu are voie să stocheze în cache conținutul returnat prin răspunsul 206. |
| 207 | Codul de stare, astfel cum a fost extins de WebDAV (RFC 2518), înseamnă că corpul mesajului ulterior va fi un mesaj XML și poate conține o serie de coduri de răspuns separate, în funcție de numărul de subrechiziții anterioare. |
| 300 | Resursa solicitată are o serie de mesaje de răspuns alternative, fiecare cu adresa sa specifică și cu informații de negociere determinate de browser. Utilizatorul sau browserul poate selecta singur o adresă preferată pentru redirecționare. Cu excepția cazului în care este vorba de o cerere HEAD, răspunsul trebuie să includă o entitate care este o listă de caracteristici ale resursei și adrese din care utilizatorul sau browserul poate selecta cea mai adecvată adresă de redirecționare. Formatul acestei entități este determinat de formatul definiției Content-Type. Browserul poate face automat cea mai adecvată selecție pe baza formatului răspunsului și a capacităților proprii ale browserului. Desigur, specificația RFC 2616 nu specifică modul în care ar trebui făcută o astfel de alegere automată. Dacă serverul însuși are deja o alegere preferată a răspunsului, atunci URI-ul acestui răspuns trebuie specificat în Location; browserul poate utiliza această valoare Location ca adresă pentru redirecționarea automată. În plus, acest răspuns poate fi pus în cache, cu excepția cazului în care se specifică altfel. |
| 301 | Resursa solicitată a fost mutată permanent în noua locație, iar orice referire viitoare la aceasta trebuie să utilizeze unul dintre cele câteva URI returnate în acest răspuns. Dacă este posibil, clienții cu capacități de editare a legăturilor ar trebui să schimbe automat adresa solicitată cu cea returnată de server. Acest răspuns poate fi, de asemenea, pus în cache, cu excepția cazului în care se specifică altfel. Noul URI permanent ar trebui să fie returnat în câmpul Location al răspunsului. Cu excepția cazului în care aceasta este o cerere HEAD, entitatea răspunsului trebuie să conțină un hyperlink către noul URI și o scurtă descriere. În cazul în care aceasta nu este o cerere GET sau HEAD, browserului îi este interzisă redirecționarea automată, cu excepția cazului în care aceasta este confirmată de utilizator, deoarece termenii cererii se pot schimba în consecință. Notă: Pentru unele browsere care utilizează protocolul HTTP/1.0, atunci când trimit o cerere POST și primesc un răspuns 301, următoarea cerere de redirecționare va fi o GET. |
| 302 | Resursa solicitată răspunde acum temporar solicitării de la un URI diferit. Deoarece această redirecționare este temporară, clientul trebuie să continue să trimită viitoarele cereri la adresa inițială. Acest răspuns poate fi pus în cache numai dacă este specificat în Cache-Control sau Expires. Noul URI temporar trebuie să fie returnat în câmpul Location al răspunsului. Cu excepția cazului în care aceasta este o cerere HEAD, entitatea răspunsului trebuie să conțină un hyperlink către noul URI și o scurtă descriere. În cazul în care aceasta nu este o cerere GET sau HEAD, browserului îi este interzisă redirecționarea automată, cu excepția cazului în care aceasta este confirmată de către utilizator, deoarece termenii cererii se pot schimba în consecință. Notă: Deși specificațiile RFC 1945 și RFC 2068 nu permit clientului să schimbe metoda cererii la redirecționare, multe browsere existente tratează răspunsul 302 ca pe un răspuns 303 și utilizează GET pentru a accesa URI-ul specificat în Location, ignorând metoda cererii inițiale. Codurile de stare 303 și 307 au fost adăugate pentru a clarifica ce răspuns așteaptă serverul de la client. |
| 303 | Răspunsul la solicitarea curentă poate fi găsit la un alt URI, iar clientul ar trebui să acceseze resursa respectivă folosind GET. Această metodă există în primul rând pentru a permite redirecționarea către o nouă resursă a rezultatelor cererii POST activate de script. Acest nou URI nu este o referință alternativă la resursa inițială. De asemenea, este interzis ca răspunsul 303 să fie pus în cache. Desigur, a doua cerere (redirecționarea) poate fi plasată în cache. Noul URI ar trebui să fie returnat în câmpul Location al răspunsului. Cu excepția cazului în care este vorba de o cerere HEAD, entitatea răspunsului trebuie să conțină un hyperlink către noul URI și o scurtă descriere. Notă: Multe browsere anterioare versiunilor HTTP/1.1 nu înțeleg corect starea 303. În cazul în care trebuie avută în vedere interacțiunea cu aceste browsere, codul de stare 302 ar trebui să fie suficient, deoarece majoritatea browserelor procesează răspunsurile 302 exact în același mod în care specificația de mai sus cere clientului să facă atunci când procesează un răspuns 303. |
| 304 | Serverul TREBUIE să returneze acest cod de stare în cazul în care clientul trimite o cerere GET condiționată care a fost permisă, iar conținutul documentului (fie de la ultima vizită, fie în conformitate cu condițiile cererii) nu s-a modificat. răspunsurilor 304 le este interzis să conțină corpuri de mesaj și, prin urmare, se încheie întotdeauna cu primul rând gol după antetul mesajului. Răspunsul TREBUIE să conțină următoarele antete: Data, cu excepția cazului în care serverul nu are un ceas. Dacă un server fără ceas respectă aceste reguli, atunci serverul proxy și clientul pot adăuga singuri câmpul Date la antetul răspunsului primit (așa cum se specifică în RFC 2068), iar mecanismul de cache va funcționa corect.ETag și/sau Content-Location, dacă aceeași cerere ar fi returnat un răspuns 200.Expires Expires, Cache-Control și/sau Vary, dacă valoarea poate fi diferită de valoarea corespunzătoare altor răspunsuri anterioare pentru aceeași variabilă. Dacă această cerere de răspuns utilizează validarea puternică a cache-ului, atunci acest răspuns nu trebuie să conțină alte antete de entitate; în caz contrar (de exemplu, o cerere GET condiționată utilizează validarea slabă a cache-ului), este interzis ca acest răspuns să conțină alte antete de entitate; astfel se evită neconcordanțele între conținutul entității din cache și informațiile actualizate ale antetelor de entitate. Dacă un răspuns 304 indică faptul că o entitate nu se află în prezent în cache, sistemul de cache trebuie să ignore răspunsul și să repete cererea fără restricție. În cazul în care se primește un răspuns 304 care solicită actualizarea unei intrări în cache, sistemul de cache TREBUIE să actualizeze întreaga intrare pentru a reflecta valorile tuturor câmpurilor actualizate în răspuns. |
| 305 | Resursa solicitată trebuie să fie accesată prin intermediul proxy-ului specificat. câmpul Location va oferi informații despre URI-ul în care se află proxy-ul specificat. destinatarul va trebui să trimită o cerere separată în mod repetat pentru a accesa resursa prin intermediul acestui proxy. Numai serverul inițial poate crea un răspuns 305. Notă: Din RFC 2068 nu reiese clar că un răspuns 305 este destinat redirecționării unei singure cereri și că poate fi creat numai de către serverul original. Ignorarea acestor restricții ar putea duce la consecințe grave în materie de securitate. |
| 306 | În cea mai recentă versiune a specificațiilor, codul de stare 306 nu mai este utilizat. |
| 307 | Resursa solicitată răspunde acum temporar solicitării de la un URI diferit. Deoarece astfel de redirecționări sunt temporare, clienții trebuie să continue să trimită viitoarele cereri la adresa inițială. Acest răspuns poate fi pus în cache numai dacă este specificat în Cache-Control sau Expires. Noul URI temporar trebuie să fie returnat în câmpul Location al răspunsului. Cu excepția cazului în care este vorba de o cerere HEAD, entitatea răspunsului trebuie să conțină un hyperlink către noul URI și o scurtă descriere. Deoarece unele browsere nu recunosc răspunsul 307, informațiile de mai sus trebuie adăugate astfel încât utilizatorul să poată înțelege și solicita accesul la noul URI. Dacă aceasta nu este o cerere GET sau HEAD, atunci browserul interzice redirecționarea automată, cu excepția cazului în care aceasta este confirmată de utilizator, deoarece condițiile cererii se pot schimba. |
| 400 | 1. Există o eroare semantică și cererea curentă nu poate fi înțeleasă de server. Cu excepția cazului în care este modificat, clientul nu trebuie să trimită în mod repetat această cerere. 2, parametrii cererii sunt greșiți. |
| 401 | Solicitarea curentă necesită autentificarea utilizatorului. Răspunsul trebuie să conțină un antet WWW-Authenticate pentru resursa solicitată pentru a cere informații despre utilizator. Clientul poate trimite în mod repetat o cerere care conține informațiile corespunzătoare din antetul Authorisation. Dacă cererea curentă conține deja acreditările Authorisation, atunci răspunsul 401 înseamnă că serverul verifică dacă acele acreditări au fost respinse. Dacă răspunsul 401 conține aceeași interogare de autentificare ca și răspunsul anterior, iar browserul a încercat deja autentificarea cel puțin o dată, atunci browserul TREBUIE să prezinte utilizatorului informațiile despre entitate conținute în răspuns, deoarece aceste informații despre entitate pot conține informații relevante de diagnosticare. A se vedea RFC 2617. |
| 402 | Acest cod de stare este rezervat pentru eventuale cerințe viitoare. |
| 403 | Serverul a înțeles cererea, dar refuză să o execute. Spre deosebire de un răspuns 401, autentificarea nu oferă niciun ajutor, iar această cerere nu ar trebui să fie transmisă din nou. Dacă aceasta nu este o cerere HEAD și serverul dorește să poată vorbi clar despre motivul pentru care cererea nu poate fi executată, atunci motivul refuzului ar trebui să fie descris în cadrul entității. Desigur, serverul poate returna și un răspuns 404 dacă nu dorește să ofere clientului nicio informație. |
| 404 | Cererea a eșuat, resursa solicitată nu a fost găsită pe server. Nu există nicio informație care să îi spună utilizatorului dacă situația este temporară sau permanentă. Dacă serverul este conștient de situație, ar trebui să utilizeze codul de stare 410 pentru a informa utilizatorul că vechea resursă este permanent indisponibilă din cauza unui mecanism de configurare internă și că nu există nicio redirecționare disponibilă. 404 este utilizat pe scară largă atunci când serverul nu dorește să dezvăluie motivul pentru care cererea a fost respinsă sau când nu există niciun alt răspuns adecvat disponibil. |
| 405 | Metoda de solicitare specificată în linia de solicitare nu poate fi utilizată pentru a solicita resursa corespunzătoare. Răspunsul trebuie să returneze un antet Allow care indică lista metodelor de solicitare care sunt acceptate pentru resursa curentă. Având în vedere că metodele PUT și DELETE scriu în resursa de pe server, majoritatea serverelor web nu acceptă aceste metode de solicitare sau nu le permit implicit și vor returna o eroare 405 pentru astfel de solicitări. |
| 406 | Caracteristicile de conținut ale resursei solicitate nu îndeplinesc condițiile din antetul cererii și nu poate fi generată o entitate de răspuns. Cu excepția cazului în care aceasta este o cerere HEAD, răspunsul trebuie să returneze o entitate care conține o listă de caracteristici și adrese ale entității din care utilizatorul sau browserul poate selecta entitatea cea mai adecvată. Formatul entității este determinat de tipul media definit în antetul Content-Type. Browser-ele pot face cele mai bune alegeri pe baza formatului și a propriilor capacități. Cu toate acestea, specificațiile nu definesc niciun criteriu pentru a face astfel de alegeri automate. |
| 407 | Similar cu răspunsul 401, cu excepția faptului că clientul TREBUIE să se autentifice la serverul proxy. Serverul proxy TREBUIE să returneze un Proxy-Authenticate pentru interogarea identității. Clientul POATE returna un antet Proxy-Authorization pentru autentificare. A se vedea RFC 2617. |
| 408 | Timeout cerere. Clientul nu a finalizat trimiterea unei cereri în intervalul de timp în care serverul era pregătit să aștepte. Clientul poate retrimite solicitarea în orice moment, fără a face nicio modificare. |
| 409 | Cererea nu a putut fi finalizată din cauza unui conflict cu starea actuală a resursei solicitate. Acest cod poate fi utilizat numai dacă utilizatorul este considerat capabil să rezolve conflictul și să retrimită o nouă cerere. Răspunsul trebuie să conțină suficiente informații pentru ca utilizatorul să poată descoperi sursa conflictului. Conflictele apar de obicei în timpul procesării cererilor PUT. De exemplu, într-un mediu de verificare a versiunii, în cazul în care informațiile privind versiunea atașate unui PUT trimis pentru a modifica o anumită resursă intră în conflict cu o cerere anterioară (terță parte), serverul ar trebui să returneze o eroare 409 prin care să informeze utilizatorul că cererea nu a putut fi finalizată. În acest caz, este probabil ca entitatea de răspuns să conțină o comparație a diferențelor dintre cele două versiuni în conflict, astfel încât utilizatorul să poată retrimite noua versiune după fuzionare. |
| 410 | Resursa solicitată nu mai este disponibilă pe server și nu are nicio adresă de redirecționare cunoscută. O astfel de condiție trebuie considerată permanentă. Dacă este posibil, clienții cu capacități de editare a legăturilor ar trebui să elimine toate trimiterile la această adresă cu permisiunea utilizatorului. În cazul în care serverul nu știe sau nu poate determina dacă această condiție este permanentă, atunci ar trebui utilizat un cod de stare 404. Scopul răspunsului este, în primul rând, de a ajuta webmasterul să mențină site-ul, informând utilizatorul că resursa nu mai este disponibilă și că proprietarul serverului dorește ca toate conexiunile la distanță la această resursă să fie, de asemenea, eliminate. Acest tip de eveniment este frecvent în cazul serviciilor cu valoare adăugată, limitate în timp. În mod similar, răspunsul 410 este utilizat pentru a notifica clienții că o resursă care a aparținut inițial unei persoane de pe site-ul actual al serverului nu mai este disponibilă. Desigur, este la latitudinea proprietarului serverului dacă toate resursele permanent indisponibile trebuie să fie marcate ca "410 Gone" și cât timp trebuie menținută această marcare. |
| 411 | Serverul refuză să accepte cereri fără antetul Content-Length definit. După adăugarea unui antet Content-Length valid care să indice lungimea corpului mesajului de cerere, clientul poate trimite din nou cererea. |
| 412 | Serverul nu a reușit să îndeplinească una sau mai multe dintre condițiile prealabile atunci când a verificat dacă acestea au fost indicate în câmpul de antet al cererii. Acest cod de stare permite clientului să stabilească precondiții în metamesajul cererii (datele din câmpul antetului cererii) atunci când obține o resursă, împiedicând astfel aplicarea metodei cererii la alte resurse decât conținutul dorit. |
| 413 | Serverul refuză să proceseze cererea curentă deoarece aceasta trimite date de entitate de o dimensiune mai mare decât dorește sau poate serverul să gestioneze. În acest caz, serverul poate închide conexiunea pentru a împiedica clientul să continue să trimită această cerere. Dacă această condiție este temporară, serverul ar trebui să returneze un antet de răspuns Retry-After pentru a informa clientul după cât timp poate efectua o nouă încercare. |
| 414 | Lungimea URI-ului solicitării depășește lungimea pe care serverul o poate interpreta, astfel încât serverul refuză să servească solicitarea. Acest lucru este rar și se întâmplă adesea atunci când trimiterea unui formular care ar fi trebuit să utilizeze metoda POST devine o metodă GET, rezultând un Query String lung. "Găuri negre" URI de redirecționare, cum ar fi utilizarea vechiului URI ca parte a noului URI cu fiecare redirecționare, rezultând un URI lung după mai multe redirecționări. Clienții încearcă să atace serverele exploatând vulnerabilitățile de securitate care există în unele servere. Astfel de servere utilizează un buffer de lungime fixă pentru a citi sau manipula URI-ul unei cereri, iar atunci când parametrii după un GET depășesc o anumită valoare, se poate produce o depășire a buffer-ului, ceea ce duce la executarea unui cod arbitrar [1]. Serverele fără astfel de vulnerabilități ar trebui să returneze un cod de stare 414. |
| 415 | Pentru metoda și resursa solicitate în prezent, entitatea prezentată în cerere nu este într-un format acceptat de server, astfel încât cererea este respinsă. |
| 416 | În cazul în care cererea conține un antet de cerere Range și orice intervale de date specificate în Range nu se suprapun cu intervalele disponibile pentru resursa curentă, iar antetul de cerere If-Range nu este definit în cerere, atunci serverul trebuie să returneze un cod de stare 416. Dacă Range utilizează intervale de octeți, atunci acesta este cazul dacă prima poziție de octeți a tuturor intervalelor de date specificate în cerere depășește lungimea resursei curente. Serverul ar trebui să includă, de asemenea, un antet de entitate Content-Range care să specifice lungimea resursei curente împreună cu codul de stare 416. De asemenea, acestui răspuns îi este interzisă utilizarea multipart/byteranges ca Content-Type. |
| 417 | Conținutul așteptat specificat în antetul de cerere Expect nu poate fi îndeplinit de server sau acest server este un server proxy care are dovezi clare că conținutul Expect nu poate fi îndeplinit la următorul nod din ruta curentă. |
| 421 | Numărul de conexiuni la server de la adresa IP la care se află clientul curent depășește maximul permis de server. De obicei, adresa IP se referă aici la adresa clientului așa cum este văzută de server (de exemplu, adresa gateway-ului sau a serverului proxy al utilizatorului). În acest caz, numărul de conexiuni poate implica mai mult de un utilizator final. |
| 422 | Numărul de conexiuni la server de la adresa IP a clientului curent depășește maximul permis de server. De obicei, adresa IP se referă aici la adresa clientului așa cum este văzută de server (de exemplu, adresa gateway-ului sau a serverului proxy al utilizatorului). În acest caz, numărul de conexiuni poate implica mai mult de un utilizator final. |
| 422 | Cererea a fost formatată corect, dar nu s-a putut răspunde la ea deoarece conținea erori semantice. (RFC 4918 WebDAV) 423 Blocat Resursa curentă este blocată. (RFC 4918 WebDAV) |
| 424 | Cererea curentă a eșuat din cauza unei erori care a apărut într-o cerere anterioară, cum ar fi PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definit în proiectul WebDav Advanced Collections, dar nu apare în protocolul WebDAV Sequential Collections (RFC 3658). |
| 426 | Clienții trebuie să treacă la TLS/1.0. (RFC 2817) |
| 449 | Extended by Microsoft to represent that requests should be retried after the appropriate action has been performed. |
| 500 | Serverul a întâmpinat o condiție neprevăzută care l-a împiedicat să finalizeze procesarea cererii. De obicei, această problemă apare atunci când există o eroare în codul programului serverului. |
| 501 | Serverul nu acceptă o anumită caracteristică care este necesară pentru cererea curentă. Atunci când serverul nu este în măsură să recunoască metoda solicitată și nu este în măsură să susțină cererea sa pentru nicio resursă. |
| 502 | Un server care funcționează ca gateway sau proxy primește un răspuns invalid de la un server din amonte atunci când încearcă să execute o cerere. |
| 503 | Serverul este în prezent în imposibilitatea de a procesa cererea din cauza întreținerii temporare a serverului sau a suprasolicitării. Această condiție este temporară și va fi restabilită după un anumit timp. Dacă se poate aștepta o întârziere, răspunsul poate include un antet Retry-After pentru a indica întârzierea. Dacă această informație Retry-After nu este furnizată, atunci clientul trebuie să o gestioneze în același mod ca un răspuns 500. Notă: Existența codului de stare 503 nu înseamnă că serverul trebuie să îl folosească dacă este supraîncărcat. Unele servere doresc pur și simplu să refuze clientului o conexiune. |
| 504 | Un server care funcționează ca gateway sau proxy și care încearcă să execute o cerere nu primește un răspuns în timp util de la un server din amonte (un server identificat printr-un URI, cum ar fi HTTP, FTP, LDAP) sau de la un server secundar (cum ar fi DNS). Notă: Unele servere proxy returnează o eroare 400 sau 500 atunci când căutarea DNS se oprește. |
| 505 | Serverul nu acceptă sau refuză să accepte versiunea de HTTP utilizată în cerere. Aceasta implică faptul că serverul nu poate sau nu dorește să utilizeze aceeași versiune ca și clientul. Răspunsul trebuie să conțină o entitate care să descrie de ce versiunea nu este suportată și ce protocoale suportă serverul. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295) to represent that the server has an internal misconfiguration: the requested Negotiation Variant resource is configured to use itself in transparent content negotiation, and is therefore not an appropriate focus in a negotiation process. |
| 507 | Serverul nu este în măsură să stocheze conținutul necesar pentru a finaliza solicitarea. Această condiție este considerată temporară.WebDAV (RFC 4918) |
| 509 | Serverul și-a atins limita de lățime de bandă. Acesta nu este un cod de stare oficial, dar este încă utilizat pe scară largă. |
| 510 | Politica necesară pentru obținerea resursei nu a fost neîndeplinită. (RFC 2774) |