Lista codurilor de stare HTTP

Codul de stare HTTP face parte din prima linie a răspunsului serverului pentru solicitările HTTP .  Este un număr zecimal din trei cifre. Prima cifră indică clasa de stare . Codul de răspuns este de obicei urmat de o frază explicativă, separată de spațiu, în limba engleză, care explică persoanei motivul unui astfel de răspuns. Exemple:

• 201 Creat .
• 401 Neautorizat .
• 507 Stocare insuficientă .

Clientul învață din codul de răspuns despre rezultatele solicitării sale și stabilește ce acțiuni să întreprindă în continuare. Setul de coduri de stare este un standard și sunt descrise în documentele RFC relevante . Introducerea noilor coduri ar trebui făcută numai după consultarea cu IETF . Cu toate acestea, există două coduri cunoscute în uz care nu sunt menționate în RFC: 449 Retry With. De asemenea, este menționată sintagma explicativă „Reply With” [1] în specificația pentru WebDAV în Microsoft Developer Network introdusă de Microsoft și 509 Bandwidth Limit Exceededintrodusă în cPanel .

Este posibil ca clientul să nu cunoască toate codurile de stare, dar trebuie să răspundă în funcție de clasa de cod. În prezent, există cinci clase de coduri de stare.

Serverul web Internet Information Services în fișierele sale jurnal, pe lângă codurile de stare standard, utilizează subcoduri, scriindu-le cu un punct după cel principal. În același timp, acest subcod nu este plasat în răspunsurile de la server - este nevoie de administratorul serverului pentru a putea determina mai precis sursele problemelor.

Lista de recenzii

Mai jos este o listă generală a tuturor codurilor de răspuns descrise în acest articol:

• 1xx: Informațional
  • 100 Continuare [ 2] [3] ;
  • 101 Protocoale de comutare [ 2] [3] ;
  • 102 Prelucrare („prelucrare”);
  • 103 Early Hints („meta-informații timpurii”);
• 2xx: Succes
  • 200 OK ("bine") [2] [3] ;
  • 201 Creat [ 2] [3] [4] ;
  • 202 Acceptat [ 2] [3] ;
  • 203 Informații neautorizate [ 2] [3] ;
  • 204 Fără conținut [ 2] [3] ;
  • 205 Resetare conținut [ 2] [3] ;
  • 206 Conținut parțial [ 2] [3] ;
  • 207 Multi-Status ("multi-status") [5] ;
  • 208 Deja raportat [ 6] ;
  • 226 IM Folosit .
• 3xx: Redirecționare :
  • 300 de alegeri multiple [ 2] [7] ;
  • 301 Mutat permanent [2] [7] ;
  • 302 Mutat temporar [ 2] [7] , 302 Găsit [ 7] ;;
  • 303 Vezi altele („vedeți altele”) [2] [7] ;
  • 304 Nemodificat [ 2] [7] ;
  • 305 Utilizați proxy [ 2] [7] ;
  • 306  - rezervat (codul a fost folosit doar în specificațiile timpurii) [7] ;
  • 307 Redirecționare temporară („redirecționare temporară”) [7] ;
  • 308 Redirecționare permanentă [ 8] .
• 4xx: Eroare client :
  • 400 Solicitare greșită („cerere incorectă, incorectă”) [2] [3] [4] ;
  • 401 Neautorizat („neautorizat (nu s-a prezentat)”) [2] [3] ;
  • 402 Plata necesară [ 2] [3] ;
  • 403 Interzis („interzis (neautorizat)”) [2] [3] ;
  • 404 Negăsit [ 2] [3] ;
  • 405 Metoda nepermisă [2] [3] ;
  • 406 Inacceptabil [ 2] [3] ;
  • 407 Este necesară autentificarea proxy [ 2] [3] ;
  • 408 Request Timeout [ 2] [3] ;
  • 409 Conflict („conflict”) [2] [3] [4] ;
  • 410 Plecat [ 2] [3] ;
  • 411 Lungime necesară [ 2] [3] ;
  • 412 Precondiție eșuată [ 2] [3] [9] ;
  • 413 Sarcină utilă prea mare [2] [3] ;
  • 414 URI Too Long (" URI prea lung") [2] [3] ;
  • 415 Tip suport media neacceptat [ 2] [3] ;
  • 416 Interval nesatisfăcător [3] ;
  • 417 Așteptarea eșuată [ 3] ;
  • 418 Sunt un ceainic („Sunt un ceainic”);
  • 419 Authentication Timeout (nu în RFC 2616) („de obicei validarea CSRF a eșuat”);
  • 421 Cerere direcționată greșit [10] ;
  • 422 Entitate neprocesabilă
  • 423 Blocat („blocat”);
  • 424 Dependență eșuată
  • 425 Prea devreme („prea devreme”);
  • 426 Actualizare necesară
  • 428 Precondiție necesară [ 11] ;
  • 429 Prea multe cereri [ 11] ;
  • 431 Câmpuri pentru antetul cererii prea mari [ 11] ;
  • 449 Reîncercați cu [ 1] ;
  • 451 Indisponibil din motive juridice [ 12] .
  • 499 Client Closed Request (clientul a închis conexiunea);
• 5xx: Eroare server :
  • 500 Eroare Interna Server [ 2] [3] ;
  • 501 Neimplementat [ 2] [3] ;
  • 502 Gateway rău [ 2] [3] ;
  • 503 Serviciu indisponibil [ 2] [3] ;
  • 504 Gateway Timeout [ 2] [3] ;
  • 505 Versiunea HTTP neacceptată [ 2] [3] ;
  • 506 Varianta De asemenea negociază [ 13] ;
  • 507 Depozitare insuficientă („overflow stocare”);
  • 508 Buclă detectată [ 14] ;
  • 509 Limită lățime de bandă depășită („lățimea de bandă a canalului epuizat”);
  • 510 Not Extended („nu extins”);
  • 511 Este necesară autentificarea în rețea [ 11] ;
  • 520 Eroare necunoscută („eroare necunoscută”) [15] ;
  • 521 Serverul web este oprit [15] ;
  • 522 Conexiune expirată („conexiunea nu răspunde”) [15] ;
  • 523 Originea este inaccesabilă [ 15] ;
  • 524 A avut loc un timeout [ 15] ;
  • 525 SSL Handshake a eșuat [ 15] ;
  • 526 Certificat SSL nevalid [ 15] .

Descrierea codurilor

Informațional

Această clasă conține coduri care informează despre procesul de transmitere. Când lucrați cu versiunea de protocol 1.0, mesajele cu astfel de coduri ar trebui ignorate. În versiunea 1.1, clientul trebuie să fie pregătit să accepte această clasă de mesaje ca răspuns normal, dar serverul nu trebuie să trimită nimic. Mesajele de la server în sine conțin doar linia de început a răspunsului și, dacă este necesar, câteva câmpuri de antet specifice răspunsului. Serverele proxy ar trebui să trimită astfel de mesaje mai departe de la server către client.

• 100 Continuare - Serverul este mulțumit de informațiile inițiale despre cerere, clientul poate continua să trimită anteturi. Introdus în HTTP/1.1.
• 101 Protocoale de comutare - Serverul îndeplinește cererea clientului și comută protocoale conform indicației date în câmpul antet Upgrade. Serverul trimite un antet de răspuns Upgradecare indică protocolul la care a trecut. Introdus în HTTP/1.1.
• 102 Procesare - Solicitarea a fost acceptată, dar va dura mult timp pentru a o procesa. Folosit de server pentru a împiedica clientul să încheie conexiunea din cauza unui timeout. Clientul, la primirea unui astfel de răspuns, trebuie să resetați cronometrul și să aștepte următoarea comandă în modul normal. A apărut în WebDAV .
• 103 Sugestii timpurii - Folosit pentru a returna o parte din anteturi devreme atunci când anteturile de răspuns complete nu pot fi formate rapid.

Succes

Mesajele acestei clase informează despre cazurile de acceptare și procesare cu succes a unei cereri de client. În funcție de stare, serverul poate trimite, de asemenea, anteturi și un corp de mesaj.

• 200 OK - cerere reușită. Dacă au fost solicitate date de către client, acestea se află în antetul și/sau corpul mesajului. Introdus în HTTP/1.0.
• 201 Creat - O nouă resursă a fost creată ca urmare a unei solicitări reușite. Serverul POATE specifica adresele (pot fi mai multe) ale resursei create în corpul răspunsului, cu adresa preferată indicată în Location. Se recomandă serverului să indice în corpul răspunsului caracteristicile resursei create și adresa acesteia, formatul corpului răspunsului este determinat de antet Content-Type. La procesarea unei cereri, trebuie creată o nouă resursă înainte ca răspunsul să fie trimis clientului, altfel un răspuns cu cod 202. Introdus în HTTP/1.0.
• 202 Acceptat - Solicitarea a fost acceptată pentru procesare, dar nu a fost finalizată. Clientul nu trebuie să aștepte transmiterea finală a mesajului, deoarece poate fi început un proces foarte lung. Introdus în HTTP/1.0.
• 203 Informații neautorizate - similar cu 200, dar în acest caz, informațiile transmise nu au fost preluate din sursa primară (backup, alt server etc.) și, prin urmare, este posibil să nu fie actualizate. Introdus în HTTP/1.1.
• 204 Fără conținut - Serverul a procesat cu succes cererea, dar numai anteturile au fost trimise în răspuns fără un corp de mesaj. Clientul nu trebuie să actualizeze conținutul documentului, dar poate aplica metadatele primite acestuia . Introdus în HTTP/1.0.
• 205 Resetare conținut - Serverul obligă clientul să reseta datele introduse de utilizator. Serverul nu transmite corpul mesajului, iar documentul nu trebuie actualizat. Introdus în HTTP/1.1.
• 206 Conținut parțial - Serverul a finalizat cu succes o solicitare GET parțială , returnând doar o parte a mesajului. În antet, Content-Rangeserverul specifică intervalele de octeți ale conținutului. Când lucrați cu astfel de răspunsuri, trebuie acordată o atenție deosebită stocării în cache. Introdus în HTTP/1.1. ( mai mult... )
• 207 Multi-Status - serverul transmite rezultatele mai multor operațiuni independente simultan. Acestea sunt plasate în corpul mesajului ca document XML cu un multistatus. Nu se recomandă plasarea stărilor din serie în acest obiect din cauza lipsei 1xxde sens și redundanței. A apărut în WebDAV .
• 208 Deja raportați - Membrii obligatorii DAV au fost deja enumerați în partea anterioară (multistatus) a răspunsului și nu sunt incluși din nou.
• 226 IM Utilizat - antetul A-IMa fost primit cu succes de la client și serverul returnează conținutul, ținând cont de parametrii specificați. Introdus în RFC 3229 pentru a mări protocolul HTTP cu suport pentru codificare delta .

Redirecționare

Codurile din această clasă îi spun clientului că trebuie făcută o altă solicitare pentru ca operația să reușească, de obicei la un URI diferit . Din această clasă, cinci coduri 301, 302, 303, 305și 307se referă direct la redirecționări. Adresa la care clientul ar trebui să facă o cerere este indicată de server în fișierul Location. Acest lucru permite utilizarea fragmentelor în URI-ul țintă.

Conform celor mai recente standarde, clientul poate redirecționa doar fără a întreba utilizatorul dacă a doua resursă este solicitată folosind metoda GETsau HEAD[7] . Specificațiile anterioare spuneau că pentru a evita călătoriile dus-întors, utilizatorul ar trebui să fie întrebat după a 5-a redirecționare consecutivă [16] . Pentru toate redirecționările, dacă metoda de solicitare nu a fost HEAD, atunci în corpul răspunsului ar trebui inclus un scurt mesaj hipertext cu adresa de destinație, astfel încât în ​​cazul unei erori, utilizatorul să poată naviga singur.

Dezvoltatorii HTTP notează că mulți clienți, atunci când redirecționează cu coduri 301și 302aplică în mod eronat metoda GETla a doua resursă, în ciuda faptului că prima solicitare a fost cu o metodă diferită (cel mai adesea PUT) [17] . Pentru a evita neînțelegerile, HTTP/1.1 a introdus coduri 303și 307și se recomandă să fie folosite în loc de 302. Trebuie să schimbați metoda doar dacă serverul a răspuns 303. În alte cazuri, următoarea cerere se face cu metoda inițială.

Comportamentul clienților pentru diferite redirecționări este descris în tabel:

Starea răspunsului	stocarea în cache	Dacă metoda nu este GET sau HEAD
301 Moved Permanently	Poți, ca de obicei.	Cereți utilizatorului confirmarea și solicitați o altă resursă folosind metoda originală.
307 Temporary Redirect	Este posibil doar dacă un titlu Cache-Controlsau Expires.
302 Found(HTTP/1.1) 302 Moved Temporarily(HTTP/1.0)
303 See Other	Este interzis.	Mergeți automat, dar folosind GET.

• 300 de opțiuni multiple - La URI-ul specificat, există mai multe opțiuni pentru furnizarea unei resurse după tip MIME , după limbă sau după alte caracteristici. Serverul trimite o listă de alternative împreună cu mesajul, permițând ca alegerea să fie făcută automat de către client sau utilizator. Introdus în HTTP/1.0.
• 301 Mutat permanent  - Documentul solicitat a fost mutat permanent în noul URI specificat în Locationcâmpul antet. Unii clienți se comportă incorect atunci când procesează acest cod. Introdus în HTTP/1.0.
• 302 găsit, 302 mutat temporar - documentul solicitat este disponibil temporar la un alt URI specificat în antetul din Location. Acest cod poate fi folosit, de exemplu, în negocierea de conținut bazată pe server . niste[ ce? ] clienții se comportă incorect atunci când procesează acest cod. Introdus în HTTP/1.0.
• 303 Vezi Altele - Documentul de la URI solicitat trebuie solicitat la adresa din Locationcâmpul antet folosind metoda GET, chiar dacă primul a fost solicitat printr-o metodă diferită. Acest cod a fost introdus împreună cu codul 307pentru a evita ambiguitatea, astfel încât serverul să poată fi sigur că următoarea resursă va fi solicitată de către GET. De exemplu, o pagină web are un câmp de introducere a textului pentru navigare și căutare rapidă. După introducerea datelor, browserul face o solicitare folosind metoda POST, inclusiv textul introdus în corpul mesajului. Dacă se găsește un document cu numele introdus, serverul răspunde cu codul 303, indicând Locationadresa permanentă a acestuia în antet. Apoi browserul este garantat să îl solicite cu o metodă GETde a obține conținutul. În caz contrar, serverul va returna pur și simplu pagina cu rezultatele căutării către client. Introdus în HTTP/1.1.
• 304 Nemodificat - Serverul returnează acest cod dacă clientul a solicitat documentul folosind GETantetul If-Modified-Sincesau If-None-Matchși documentul nu s-a modificat de la ora specificată. În acest caz, mesajul serverului nu trebuie să conțină un corp. Introdus în HTTP/1.0.
• 305 Utilizați proxy - Solicitarea pentru resursa solicitată trebuie făcută printr-un server proxy al cărui URI este specificat în Locationcâmpul antet. Acest cod de răspuns poate fi utilizat numai de serverele HTTP de origine (nu proxy). Introdus în HTTP/1.1.
• 306 (Rezervat) - Folosit în versiunile anterioare ale specificației, codul de răspuns este rezervat în prezent. Menționat în RFC 2616 (actualizare HTTP/1.1). Conform schițelor timpurii, codul însemna Switch Proxy, spunându-i clientului să schimbe proxy-ul în uz cu cel specificat de server în antetul răspunsului [18] .
• 307 Redirecționare temporară - Resursa solicitată este disponibilă pentru scurt timp la un URI diferit specificat în Locationcâmpul antet. Metoda de solicitare (GET/POST) nu poate fi schimbată. De exemplu, o solicitare POST trebuie trimisă la un nou URI folosind aceeași metodă POST. Acest cod a fost introdus împreună cu 303 în loc de 302 pentru a evita ambiguitatea. Introdus în RFC 2616 (actualizare HTTP/1.1).
• 308 Redirecționare permanentă - Resursa solicitată a fost relocată permanent în noul URI specificat în Locationcâmpul antet. Metoda de solicitare (GET/POST) nu poate fi schimbată. De exemplu, o solicitare POST trebuie trimisă la un nou URI folosind aceeași metodă POST. Acest cod a fost introdus în loc de 301 pentru a evita ambiguitatea. Introdus în RFC 7238 ( RFC 7538 ).

Eroare client

Clasa de coduri 4xxeste menită să indice erorile din partea clientului. Când utilizați toate metodele, cu excepția HEAD, serverul trebuie să returneze o explicație hipertext pentru utilizator în corpul mesajului.

• 400 Solicitare greșită - Serverul a întâlnit o eroare de sintaxă în cererea clientului. Introdus în HTTP/1.0.
• 401 Neautorizat - Este necesară autentificarea pentru a accesa resursa solicitată . Antetul răspunsului trebuie să conțină un câmp WWW-Authenticatecu o listă de condiții de autentificare. Cu alte cuvinte, pentru a accesa resursa solicitată, clientul trebuie să se prezinte prin trimiterea unei cereri, incluzând în același timp un câmp Authorizationcu datele necesare autentificării în antetul mesajului. Dacă cererea include deja date de autorizare, un răspuns 401 înseamnă că autorizarea cu aceasta este refuzată.
• 402 Plata necesară - destinată a fi utilizată în viitor[ când? ] . In prezent[ când? ] nu este folosit. Acest cod este pentru serviciile plătite pentru utilizatori, nu pentru companiile de găzduire . Înseamnă că această eroare nu va fi emisă de furnizorul de găzduire în cazul plății restante pentru serviciile sale. Rezervat din HTTP/1.1.

• 403 Interzis [19]  - Serverul a înțeles cererea, dar refuză să o îndeplinească din cauza restricțiilor de acces pentru client la resursa specificată. Cu alte cuvinte, clientul nu este autorizat să efectueze operațiuni pe resursa solicitată. Dacă accesul la o resursă necesită autentificare HTTP, atunci serverul va returna un răspuns 401sau 407atunci când folosește un proxy. În caz contrar, limitele au fost stabilite de administratorul serverului sau de dezvoltatorul aplicației web și pot varia în funcție de capacitățile software-ului utilizat . În orice caz, serverul TREBUIE informat cu privire la motivele refuzului de a procesa cererea. Cele mai probabile motive pentru restricție pot fi o încercare de a accesa resursele de sistem ale serverului web (de exemplu, fișiere .htaccesssau .htpasswd) sau fișiere la care accesul a fost refuzat folosind fișiere de configurare, cerința de autentificare diferită de HTTP, de exemplu, pentru a accesați sistemul de gestionare a conținutului sau secțiunea pentru utilizatorii înregistrați sau serverul nu este mulțumit de adresa IP a clientului , de exemplu, atunci când este blocat. Introdus în HTTP/1.0.
• 404 Not Found [20]  este cea mai frecventă eroare la utilizarea internetului, motivul principal fiind o greșeală în scrierea adresei unei pagini Web. Serverul a înțeles cererea, dar nu a găsit o resursă potrivită la adresa URL specificată. Dacă serverul știe că a existat un document la această adresă, atunci este de dorit să se folosească codul 410 . Răspunsul 404poate fi folosit în loc 403de dacă doriți să ascundeți cu atenție anumite resurse de privirile indiscrete. Introdus în HTTP/1.0.
• 405 Metoda nepermisă - Metoda specificată de client nu poate fi aplicată resursei curente. În răspuns, serverul trebuie să indice metodele disponibile în antet Allow, separate prin virgulă. Serverul ar trebui să returneze această eroare dacă metoda îi este cunoscută, dar nu este aplicabilă în mod specific resursei specificate în cerere, dar dacă metoda specificată nu este aplicabilă pe întregul server, atunci clientul trebuie să returneze codul 501( Neimplementat). Introdus în HTTP/1.1.
• 406 Nu este acceptabil - URI-ul solicitat nu poate satisface caracteristicile transmise în antet. Dacă metoda nu a fost HEAD, atunci serverul ar trebui să returneze o listă de caracteristici valide pentru resursa dată. Introdus în HTTP/1.1.
• 407 Proxy Authentication Required - Răspunsul este similar cu codul 401, cu excepția faptului că autentificarea este efectuată pentru un server proxy. Mecanismul este similar cu autentificarea pe serverul de origine. Introdus în HTTP/1.1.
• 408 Request Timeout - Serverul a expirat în așteptarea unui transfer de la client. Clientul poate repeta oricând cererea similară celei precedente. De exemplu, o astfel de situație poate apărea atunci când încărcați un fișier mare pe server folosind POSTsau PUT. La un moment dat al transferului, sursa de date a încetat să mai răspundă, de exemplu, din cauza unui CD deteriorat sau a pierderii comunicării cu un alt computer din rețeaua locală. Atâta timp cât clientul nu transmite nimic, în așteptarea unui răspuns de la acesta, se menține conexiunea la server. După ceva timp, serverul poate închide conexiunea pe partea sa pentru a permite altor clienți să facă o cerere. Acest răspuns nu este returnat atunci când clientul a oprit forțat transferul la comanda utilizatorului sau conexiunea a fost întreruptă din alt motiv, deoarece răspunsul nu mai poate fi trimis. Introdus în HTTP/1.1.
• 409 Conflict - Solicitarea nu a putut fi finalizată din cauza unui conflict de resurse. Acest lucru se poate întâmpla, de exemplu, atunci când doi clienți încearcă să modifice o resursă folosind PUT. Introdus în HTTP/1.1.
• 410 Gone - serverul trimite un astfel de răspuns dacă resursa era la adresa URL specificată, dar a fost ștearsă și acum nu este disponibilă. În acest caz, serverul nu știe, de asemenea, locația documentului alternativ (de exemplu, o copie). Introdus în HTTP/1.1.
• 411 Lungime necesară - Pentru resursa specificată, clientul trebuie să specifice Content-Lengthîn antetul cererii. Fără a specifica acest câmp, nu ar trebui să reîncercați cererea către server pentru acest URI. Un astfel de răspuns este firesc pentru interogări precum POSTși PUT. De exemplu, dacă fișierele sunt descărcate la URI-ul specificat și există o limită a volumului lor pe server. Atunci ar fi mai înțelept să verifici antetul chiar de la început Content-Lengthși să refuzi imediat descărcarea, decât să provoci o încărcare fără sens prin întreruperea conexiunii atunci când clientul trimite cu adevărat un mesaj prea mare. Introdus în HTTP/1.1.
• 412 Precondiție eșuată - Returnat dacă niciunul dintre câmpurile de antet condiționate (If-Match, etc., vezi RFC 7232 ) ale cererii nu a fost completat. Introdus în HTTP/1.1.
• 413 Payload Too Large - Returnat dacă serverul refuză să proceseze cererea deoarece corpul solicitării este prea mare. Serverul POATE închide conexiunea pentru a opri transmiterea ulterioară a cererii. Dacă problema este temporară, se recomandă includerea unui antet în răspunsul serverului Retry-Aftercare să indice timpul după care o cerere similară poate fi repetată. Introdus în HTTP/1.1. Denumit anterior „Entitate solicitată prea mare”.
• 414 URI prea lung - Serverul nu poate procesa cererea deoarece URI-ul specificat este prea lung. O astfel de eroare poate fi provocată, de exemplu, atunci când clientul încearcă să treacă parametri lungi prin metodă GETîn loc de POST. Introdus în HTTP/1.1. Denumit anterior „Request-URI Too Long”.
• 415 Tip media neacceptat - din anumite motive, serverul refuză să lucreze cu tipul de date specificat cu această metodă. Introdus în HTTP/1.1.
• 416 Interval nesatisfăcător - Un Rangeinterval în afara resursei a fost specificat în câmpul antet al cererii și câmpul lipsește If-Range. Dacă clientul a trimis un interval de octeți, atunci serverul POATE returna dimensiunea reală în Content-Rangecâmpul antet. Acest răspuns nu trebuie utilizat atunci când treceți tipulmultipart/byteranges . Introdus în RFC 2616 (actualizare HTTP/1.1). Denumit anterior „Interval solicitat nu este satisfăcător”.
• 417 Așteptarea eșuată - Din anumite motive, serverul nu poate satisface valoarea Expectcâmpului antet cererii. Introdus în RFC 2616 (actualizare HTTP/1.1).
• 418 Sunt un ceainic - Acest cod a fost introdus în 1998 ca una dintre glumele tradiționale ale IETF April Fools în RFC 2324 , Hyper Text Coffee Pot Control Protocol . Acest cod nu este de așteptat să fie suportat de servere reale [21] .
• 419 Authentication Timeout (nu în RFC 2616 ) - Acest cod nu este în RFC 2616 , folosit ca alternativă la codurile 401 care sunt autentificate, dar nu au acces la anumite resurse de server. De obicei, codul este dat dacă jetonul CSRF este învechit sau s-a dovedit a fi incorect.
• 421 Solicitare direcționată greșit - Solicitarea a fost redirecționată către un server care nu a putut răspunde.
• 422 Unprocessable Entity - serverul a acceptat cu succes cererea, poate lucra cu tipul specificat de date (de exemplu, corpul cererii conține un document XML care are sintaxa corectă), dar există un fel de eroare logică din cauza căreia este imposibil de efectuat o operație asupra resursei. Introdus în WebDAV .
• 423 Blocat - Resursa țintă din solicitare este blocată să-i aplice metoda specificată. Introdus în WebDAV .
• 424 Dependență eșuată - Implementarea cererii curente poate depinde de succesul unei alte operațiuni. Dacă nu este executat și din această cauză este imposibil să se execute cererea curentă, atunci serverul va returna acest cod. Introdus în WebDAV .
• 425 Prea devreme - Serverul nu este pregătit să accepte riscurile procesării „informațiilor timpurii”. Introdus în RFC 8470 pentru a proteja împotriva atacurilor de reluare atunci când se utilizează 0-RTT în TLS 1.3.
• 426 Upgrade Required - Serverul solicită clientului să actualizeze protocolul. Antetul răspunsului trebuie să conțină câmpuri bine formate Upgradeși Connection. Introdus în RFC 2817 pentru a permite tranziția la TLS prin HTTP.
• 428 Precondiție necesară - Serverul îi spune clientului să folosească antete de condiție precum If-Match. Introdus în proiectul RFC 6585 .
• 429 Too Many Requests - Clientul a încercat să trimită prea multe solicitări într-un timp scurt, ceea ce poate indica, de exemplu, o încercare de atac DDoS. Poate fi însoțit de un antet Retry-After care indică cât timp poate fi reîncercată cererea. Introdus în proiectul RFC 6585 .
• 431 Câmpuri de antet de solicitare prea mari - Lungimea permisă a antetelor a fost depășită. Serverul nu este obligat să răspundă cu acest cod, ci pur și simplu poate reseta conexiunea. Introdus în proiectul RFC 6585 .
• 434 Gazda solicitată indisponibilă - Adresa solicitată nu este disponibilă .
• 449 Retry With - Returnat de server dacă nu au fost primite suficiente informații de la client pentru a procesa cererea. În acest caz, câmpul este plasat în antetul răspunsului Ms-Echo-Request. Introdus de Microsoft pentru WebDAV . In prezent[ când? ] este folosit cel puțin de Microsoft Money .
• 451 Indisponibil din motive legale  - accesul la resursă este închis din motive legale, de exemplu, la cererea autorităților publice sau la solicitarea deținătorului drepturilor de autor în cazul încălcării drepturilor de autor. Introdus într-o schiță IETF de Google [12] , cu codul de eroare fiind o referire la romanul lui Ray Bradbury Fahrenheit 451 . A fost adăugat la standard la 21 decembrie 2015 [22] .
• 499 Client Closed Request este un cod non-standard propus și utilizat de nginx pentru cazurile în care clientul a închis conexiunea în timp ce nginx procesa cererea.

Eroare server

Codurile 5xxsunt dedicate cazurilor de excepții netratate atunci când se efectuează operațiuni pe partea serverului. Pentru toate situațiile, altele decât utilizarea metodei HEAD, serverul TREBUIE să includă o explicație în corpul mesajului pe care clientul o va afișa utilizatorului.

• 500 Internal Server Error [23]  Orice eroare internă de server care nu este acoperită de celelalte erori ale clasei. Introdus în HTTP/1.0.
• 501 Neimplementat - Serverul nu acceptă capabilitățile necesare procesării cererii. Un răspuns tipic pentru cazurile în care serverul nu înțelege metoda specificată în cerere. Dacă metoda este cunoscută de server, dar nu este aplicabilă acestei resurse, atunci trebuie să returnați răspunsul 405. Introdus în HTTP/1.0.
• 502 Bad Gateway - Serverul, care acționează ca un gateway sau server proxy, a primit un mesaj de răspuns nevalid de la un server din amonte. Introdus în HTTP/1.0.
• 503 Serviciu indisponibil - serverul nu poate procesa temporar solicitările din motive tehnice (întreținere, supraîncărcare etc.). În Retry-Aftercâmpul antet, serverul poate specifica timpul după care se recomandă ca clientul să repete cererea. Deși pare evident să se încheie imediat conexiunea în timpul congestiei, poate fi mai eficient să se stabilească câmpul la o valoare mare Retry-Afterpentru a reduce frecvența solicitărilor redundante. Introdus în HTTP/1.0.
• 504 Gateway Timeout - Serverul care acționează ca gateway sau proxy nu a așteptat un răspuns de la serverul din amonte pentru a finaliza cererea curentă. Introdus în HTTP/1.1.
• 505 Versiunea HTTP neacceptată - Serverul nu acceptă sau refuză să accepte versiunea protocolului HTTP specificată în cerere. Introdus în HTTP/1.1.
• 506 De asemenea, varianta negociază - Ca urmare a unei configurații eronate, varianta selectată indică spre sine, din cauza căreia procesul de conectare este întrerupt. Experimental. Introdus în RFC 2295 pentru a spori protocolul HTTP cu tehnologia Transparent Content Negotiation .
• 507 Stocare insuficientă - Nu există suficient spațiu pentru a finaliza cererea curentă. Problema poate fi temporară. Introdus în WebDAV .
• 508 Loop Detected - Operațiunea anulată deoarece serverul a întâlnit o buclă infinită în timpul procesării unei cereri fără limită de adâncime. Introdus în WebDAV .
  • 508 Resource Limit Reached este o variantă a erorii 508 în CloudLinux care apare atunci când sunt atinse limitele de găzduire [24] .
• 509 Bandwidth Limit Exceeded - utilizat atunci când site-ul web depășește limita de consum de trafic alocată acestuia. În acest caz, proprietarul site-ului ar trebui să contacteze furnizorul său de găzduire. În prezent, acest cod nu este descris în niciun RFC și este folosit doar de modulul „bw/limited” inclus în panoul de control al găzduirii cPanel , unde a fost introdus.
• 510 Not Extended - Serverul nu are o extensie pe care clientul dorește să o utilizeze. Serverul poate trimite opțional informații despre extensiile disponibile pentru el. Introdus în RFC 2774 pentru a mări protocolul HTTP cu suport pentru extensii.
• 511 Network Authentication Required - acest răspuns nu este trimis de serverul căruia i-a fost destinată cererea, ci de un server intermediar - de exemplu, serverul furnizorului - dacă clientul trebuie mai întâi să se conecteze la rețea, de exemplu, introduceți o parolă pentru un punct de acces la internet plătit. Se presupune că corpul răspunsului va returna un formular de autorizare web sau o redirecționare către acesta. Introdus în proiectul RFC 6585 .
• 520 Eroare necunoscută, apare atunci când serverul CDN nu a putut procesa eroarea serverului web; cod CloudFlare personalizat .
• 521 Web Server Is Down, apare atunci când conexiunile CDN sunt respinse de serverul web; cod CloudFlare personalizat .
• 522 Connection Timed Out, apare atunci când CDN -ul nu s-a conectat la serverul web; cod CloudFlare personalizat .
• 523 Origin Is Unreachable, apare atunci când serverul web este inaccesibil; cod CloudFlare personalizat .
• 524 A avut loc un timeout, apare atunci când expiră timpul conexiunii între serverul CDN și serverul web. cod CloudFlare personalizat .
• 525 SSL Handshake Failed, apare atunci când eșuează legătura SSL între serverul CDN și serverul web; cod CloudFlare personalizat .
• 526 Certificat SSL invalid, apare atunci când certificatul de criptare al serverului web nu poate fi validat; cod CloudFlare personalizat .

Vezi și

• Lista antetelor HTTP
• Cod de răspuns

Note

1. ↑ 1 2 2.2.6 449 „Reîncercați cu codul de stare” // Protocol Web Distributed Authoring and Versioning (WebDAV): Extensii client. Arhivat pe 5 octombrie 2009 la Wayback Machine pe MSDN
2. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 35 16 33 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 35 16 33 16 33 16 34 33 16 34 33 16 34 34 33 16 34 34 34 34 34 34 34 36 7, 2018 la Wayback Machine » în RFC 2068
3. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 RFC . Data accesului: 29 iulie 2009. Arhivat din original pe 7 martie 2011. (nedefinit)
4. ↑ 1 2 3 IETF Proiect WebDAV Advanced Collections Protocol  - S.4.2.5 . Data accesului: 18 mai 2012. Arhivat din original pe 9 iulie 2012. (nedefinit)
5. ↑ IETF Draft WebDAV Advanced Collections Protocol  - S.10 . Data accesului: 18 mai 2012. Arhivat din original pe 9 iulie 2012. (nedefinit)
6. ↑ rfc5842 . Consultat la 12 septembrie 2017. Arhivat din original la 10 octombrie 2017. (nedefinit)
7. ↑ 1 2 3 4 5 6 7 8 9 10 RFC 2616 „10.3 Redirecționare 3xx” (p. 61) . Data accesului: 29 iulie 2009. Arhivat din original pe 7 martie 2011. (nedefinit)
8. ↑ rfc7538 . Consultat la 12 septembrie 2017. Arhivat din original la 16 aprilie 2015. (nedefinit)
9. ↑ IETF Draft WebDAV Advanced Collections Protocol  - S.4.3.1.1 . Data accesului: 18 mai 2012. Arhivat din original pe 9 iulie 2012. (nedefinit)
10. ↑ rfc7540 . Consultat la 12 septembrie 2017. Arhivat din original la 23 iunie 2015. (nedefinit)
11. ↑ 1 2 3 4 RFC 6585
12. ↑ 1 2 IETF elaborează un nou cod de stare HTTP pentru a raporta obstacolele legale . Preluat la 6 martie 2013. Arhivat din original la 22 mai 2013. (nedefinit)
13. ↑ RFC 2295 Negociere de conținut transparent în HTTP  - S.8.1 . Data accesului: 18 mai 2012. Arhivat din original pe 8 iunie 2012. (nedefinit)
14. ↑ IETF Draft WebDAV Advanced Collections Protocol  - S.7.1 . Data accesului: 18 mai 2012. Arhivat din original pe 9 iulie 2012. (nedefinit)
15. ↑ 1 2 3 4 5 6 7 Pagini de eroare - Suport CloudFlare . Consultat la 18 aprilie 2016. Arhivat din original pe 4 martie 2016. (nedefinit)
16. ↑ RFC 2068 „10.3 Redirection 3xx” (p. 56) Arhivat la 7 iunie 2018 la Wayback Machine .
17. ↑ RFC 2616 , secțiunea „10.3.3 302 Found”, pagina 63 Arhivat la 7 martie 2011 la Wayback Machine .
18. ↑ Josh Cohen HTTP/1.1 Codurile de răspuns 305 și 306 Arhivate la 8 septembrie 2014 la Wayback Machine  // Netscape Communications Corp., 25 decembrie 1996
19. ↑ Ce înseamnă 403 Interzis? Arhivat pe 21 februarie 2014 la Wayback Machine .
20. ↑ Cauze of a 404 Not Found Error Arhivat 21 februarie 2014 la Wayback Machine .
21. ↑ RFC 2324 - Protocolul de control al cafelei hipertext (HTCPCP/1.0) .
22. ↑ draft-ietf-httpbis-legally-restricted-status-04 . datatracker.ietf.org. Preluat la 22 decembrie 2015. Arhivat din original la 23 decembrie 2015. (nedefinit)
23. ↑ Descrierea 500 de erori interne ale serverului Arhivat 21 februarie 2014 la Wayback Machine .
24. ↑ Limita de resurse atinsă . www.cloudlinux.com _ Preluat la 21 iunie 2022. Arhivat din original la 15 mai 2021. (nedefinit)

Link -uri

Documente de bază HTTP (descrescătoare după data publicării)

•  Registrul codurilor de stare a protocolului de transfer hipertext (HTTP) . IANA (17 octombrie 2007). - Registrul codului de stare HTTP. Data accesului: 30 iulie 2009. Arhivat din original la 17 februarie 2012.
• RFC 2616 Proiect de standard „ Protocol de transfer  hipertext  - HTTP/1.1 ”  ( în engleză ) IETF , iunie 1999; Fielding Roy ( UC Irvine), Gettys Jim ( Compaq / W3C ), Mogul J. ( Compaq ), Frystyk Henrik( MIT / W3C ), Masinter L. ( Xerox ), Leach P. ( Microsoft ), Berners-Lee Tim ( W3C / MIT )  - actualizare a protocolului HTTP versiunea 1.1.
• RFC 2068 Standard propus „ Hypertext Transfer Protocol - HTTP/1.1 ”  (engleză) (din  engleză  –  „Hypertext Transfer Protocol - HTTP/1.1”); IETF , ianuarie 1997; Fielding Roy ( UC Irvine), Gettys Jim ( DEC ), Mogul J. ( DEC ), Frystyk Henrik( MIT /LCS), Berners-Lee Tim ( MIT /LCS)  este o specificație timpurie pentru versiunea HTTP 1.1.
• RFC 1945 informațional „ Protocol de transfer  hipertext - HTTP  /  1.0 ” IETF , mai 1996; Berners-Lee Tim ( MIT /LCS), Fielding Roy ( UC Irvine), Frystyk Henrik( MIT /LCS)  este prima specificație pentru protocolul HTTP. Include, de asemenea, o descriere a HTTP/0.9.

Documente privind extensiile și actualizările protocolului HTTP (descrescătoare după data publicării)

• RFC 4918 Standard propus „ Extensii  HTTP pentru crearea și  versiunea distribuită pe web (  WebDAV ) ” IETF , iunie 2007; Dusseault Ed. L. ( CommerceNet)  este o specificație târzie pentru protocolul WebDAV, care înlocuiește RFC 2518 .
• RFC 3229 Standard propus „ Codificare Delta în HTTP ”  (engleză) (din  engleză  -  „Codificare Delta în HTTP”); IETF , ianuarie 2002; Mogul J. ( Compaq WRL), Krishnamurthy B. ( AT&T ), Douglis F. ( AT&T ), Feldmann A. ( Univ. din Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA) .
• RFC 2817 Standard propus „ Actualizarea  la TLS  în cadrul HTTP  / 1.1 ” IETF , mai 2000; Khare Rohit(4K Associates/ UC Irvine), Lawrence S. (Agranat Systems, Inc.)  - actualizare la RFC 2616 pentru a descrie modul în care funcționează HTTP și TLS .
• RFC 2774 Experimental „ An HTTP Extension Framework ”  (engleză) (din  engleză  -  „HTTP Extension Framework”); IETF , februarie 2000; Nielsen H. ( Microsoft ), Leach P. ( Microsoft ), Lawrence S. (Agranat Systems) .
• Internet Draft „ WebDAV Advanced Collections Protocol ” (din  engleză  – „WebDAV Advanced Collections Protocol  ”); IETF , 18 iunie 1999; Slein J. ( Xerox ), Whitehead Jr. EJ ( UC Irvine), Davis J. (CourseNet), Clemm G. ( Rational ), Fay C. ( FileNet), Crawford J. ( IBM ), Chihaya T. (DataChannel)  - managementul colecțiilor în WebDAV; expirat la 18 decembrie 1999.
• Standardul propus RFC 2518 „  Extensii HTTP pentru crearea  distribuită -  WEBDAV ” IETF , februarie 1999; Goland Y. ( Microsoft ), Whitehead E. ( UC Irvine), Faizi A. ( Netscape ), Carter S. ( Novell ), Jensen D. ( Novell )  - prima specificație pentru protocolul WebDAV ( înlocuită de RFC 4918 ).
•  RFC 2295  Negociere de conținut transparent experimental  în HTTP IETF , martie 1998; Holtman K. (TUE), Mutz A. ( Hewlett-Packard ) .

Materiale suplimentare

•  Protocol Web Distributed Authoring and Versioning (WebDAV) : Extensii client . Microsoft (14 martie 2007). — Descrierea suportului pentru extensia client în protocolul WebDAV. Data accesului: 30 iulie 2009. Arhivat din original la 17 februarie 2012.
• RFC 2324 Informațional „ Protocolul de control al cafelei hipertext (  HTPCP  /  1.0 ) ” IETF , 1 aprilie 1998; Maestrul L. .
• KB 318380 Coduri de stare IIS . Microsoft (4 decembrie 2007). — listă de coduri de stare extinse pentru protocoalele HTTP și FTP. Data accesului: 16 ianuarie 2010. Arhivat din original la 17 februarie 2012. (Rusă)
• Un manual al codurilor de stare HTTP . Yandex . — procesarea codurilor de stare HTTP de către roboții Yandex . Preluat: 2 mai 2018. (nedefinit)

Web și site-uri web
la nivel global	World Wide Web Web 1.0 Web 2.0 Web 3.0 web semantic Neuronet
La nivel local	Site-ul web Portal Pagină Serviciu Inel
Tipuri de site-uri și servicii	Atlas virtual rețea de bannere Bibliotecă Blog ( platformă ) Gazduire video Wiki Site cărți de vizită Întrebare răspuns Marcaje servicii matrimoniale joc browser Director de resurse Magazin online microblog site de știri Sistem de căutare site porno E-mail web Rețea socială Tumblelog Tracker BitTorrent Gazduire fisiere forum Serviciu Imageboard Gazduire foto conversație
Creare si intretinere	Maestru Dezvoltare Proiecta Aspect Programare utilizabilitate Experiență de interacțiune Promovarea site-ului web Optimizare pentru motoarele de căutare (SEO) Gazduire Administrator de sistem Moderator Cont Autorizare
Tipuri de machete, pagini, site-uri	Static Dinamic Fix Cauciuc dinamic elastic Adaptiv
Tehnic	server web Browser DNS CMF CMS HTTP ( răspunsuri anteturi ) SPDY QUIC CGI HTML XHTML css PHP JavaScript DHTML prăjitură DOM XML AJAX JSON Flash RSS atom informator Microformat favicon.ico _ robots.txt Sitemaps harta site-ului .htaccess
Marketing	Internet Marketing publicitate pe internet Banner publicitate contextuală Teaser Cybersquatting
Societate și cultură	Blogosfera Comunitatea Internet ( district ) Literatura de rețea

http
Concepte generale	Conexiune permanentă Conducte HTTP compresie HTTPS HTTP/2 HTTP/3
Metode	OPȚIUNI OBȚINE CAP POST A PUNE ȘTERGE URMĂ CONECTAȚI PLASTURE
Titluri	prăjitură ETag Referitor Locație HTTP urmăriți X-Redirecţionat-
Codurile de stare	1xx: Informațional 2xx: Succes 3xx: Redirecționare 301 mutat permanent 4xx: Eroare client 403 Interzis 404 Nu a fost gasit 451: Indisponibil din motive legale 5xx: Eroare server