Instrumente online
Coduri de stare HTTP Cod de stare Semnificație
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 a fost finalizată. 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 Upgrade că a fost utilizat un protocol diferit pentru a finaliza cererea. După trimiterea ultimei linii goale din răspuns, serverul va trece la protocoalele definite în antetul Upgrade. Acest lucru trebuie făcut numai dacă este mai avantajos să se treacă la noul protocol. De exemplu, trecerea la o nouă versiune a HTTP poate fi avantajoasă față de o versiune mai veche sau trecerea la un protocol sincron, în timp real, pentru a furniza resurse care profită de astfel de caracteristici.
102 Codurile de stare, extinse de WebDAV (RFC 2518), indică faptul că procesarea va continua.
200 Cererea a fost acceptată, iar antetele de răspuns sau corpul de date dorit de cerere vor fi returnate împreună cu răspunsul.
201 Cererea a fost îndeplinită și o nouă resursă a fost creată ca răspuns la cerere, iar URI-ul acesteia a fost returnat cu antetul Location. În cazul în care resursa solicitată nu poate fi creată la timp, ar trebui returnat următorul răspuns'202 Accepted'。
202 Serverul a acceptat cererea, dar nu a procesat-o încă. La fel cum poate fi respinsă, cererea poate sau nu poate fi executată în cele din urmă. În cazul operațiunilor asincrone, nu există nimic mai convenabil decât trimiterea acestui cod de stare. Scopul returnării unui răspuns 202 este de a permite serverului să accepte cereri de la alte procese (cum ar fi o operațiune pe loturi care se execută o singură dată pe zi) fără ca clientul să fie nevoit să mențină o conexiune la server până la finalizarea operațiunii pe loturi. Un răspuns care acceptă o cerere de procesare și returnează un cod de stare 202 ar trebui să includă în entitatea returnată anumite informații care indică starea actuală a procesului, precum și un indicator către un monitor al stării de procesare sau o predicție a stării, astfel încât utilizatorul să poată estima dacă operațiunea a fost finalizată sau nu.
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 celor originale. De exemplu, metadatele care conțin resurse pot determina serverul de origine 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ă el.
204 Serverul a procesat cererea cu succes, dar nu trebuie să returneze niciun conținut fizic și dorește să returneze metainformații actualizate. Răspunsul poate returna meta-informații noi sau actualizate sub formă de antete de entitate. Dacă aceste antete există, ele 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ă nicio modificare a vizualizării documentului, chiar dacă meta-informațiile noi sau actualizate TREBUIE, în conformitate cu specificațiile, 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 gestionează cu succes cererea și nu returnează 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 principal 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 fișier mare în mai multe descărcări î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 sau, în cazul descărcărilor multipartit cu un Content-Type de multipart/byteranges, un câmp Content-Range în fiecare segment multipartit pentru a indica 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. Expires, Cache-Control și/sau Vary, dacă valorile lor pot fi diferite de valorile altor răspunsuri anterioare cu aceleași variabile. Acest răspuns nu ar trebui să conțină alte antete de entitate în cazul în care cererea utilizează validarea puternică If-Range a memoriei cache și nu ar trebui să conțină alte antete de entitate în cazul în care cererea utilizează validarea slabă If-Range a memoriei cache; astfel se evită neconcordanțele între conținutul entității memorate în memoria cache și informațiile actualizate ale antetului entității. În caz contrar, acest răspuns TREBUIE să conțină toate câmpurile antetului entității care ar fi trebuit să fie returnate în răspunsul 200. În cazul în care antetele ETag sau Last-Modified nu corespund exact, memoria cache din partea clientului nu ar trebui să permită 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 Coduri de stare extinse de WebDAV(RFC 2518) Codul de stare, astfel cum este extins de WebDAV, î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 subcereri anterioare.
300 Resursa solicitată are o serie de răspunsuri alternative, fiecare cu propria adresă specifică și informații de negociere determinate de browser. Depinde de utilizator sau de browser să aleagă o adresă preferată pentru redirecționare. Cu excepția cazului în care aceasta este 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 să se facă această selecție automată. Dacă serverul însuși are deja o opțiune de răspuns preferată, URI-ul răspunsului trebuie specificat în Location; browserele pot utiliza această valoare Location ca adresă pentru redirecționarea automată. În plus, răspunsul poate fi stocat î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 către 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 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ă. Răspunsul 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 în timpul redirecționării, 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 trebuie să acceseze resursa respectivă utilizând 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ță de înlocuire a resursei originale. De asemenea, răspunsul 303 nu are voie 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 HTTP/1.1 nu înțeleg corect starea 303. În cazul în care trebuie luată în considerare interacțiunea cu aceste browsere, codul de stare 302 ar trebui să funcționeze, deoarece majoritatea browserelor gestionează răspunsul 302 exact în modul în care specificația de mai sus cere clientului să gestioneze răspunsul 303.
304 Acest cod de stare ar trebui returnat de server dacă clientul trimite o cerere GET condiționată și cererea este permisă, iar conținutul documentului nu s-a modificat (fie de la ultima vizită, fie în conformitate cu condițiile cererii). Răspunsurilor 304 le este interzis să conțină un corp al mesajului și, prin urmare, se încheie întotdeauna cu primul rând gol după antetul mesajului. Răspunsul trebuie să conțină următoarele informații de antet: 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 (după 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 trebuit să returneze un răspuns 200. Expires, Cache-Control și/sau Vary, dacă valorile lor pot fi diferite de valorile altor răspunsuri anterioare cu aceleași variabile. În cazul în care cererea de răspuns utilizează validarea puternică a cache-ului, atunci răspunsul nu trebuie să conțină antete de entitate suplimentare; în caz contrar (de exemplu, o cerere GET condiționată utilizează validarea slabă a cache-ului), răspunsul nu trebuie să conțină antete de entitate suplimentare; astfel se evită neconcordanțele dintre 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ă printr-un proxy specificat. Câmpul Location va oferi informații despre URI-ul proxy-ului specificat, iar destinatarul va trebui să trimită o cerere separată în mod repetat pentru a accesa resursa prin acest proxy. Numai serverul original 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 poate fi creat numai de către serverul de origine. Ignorarea acestor restricții poate 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 Resursele solicitate răspund acum temporar la solicitări din URI-uri diferite. Deoarece această redirecționare este temporară, 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, este necesar să se adauge informațiile de mai sus, 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 este confirmată de utilizator, deoarece condițiile cererii se pot schimba.
400 1, eroare semantică, cererea curentă nu poate fi înțeleasă de server. Dacă nu este modificat, clientul nu trebuie să repete cererea. 2, parametrii cererii sunt greșiți.
401 Cererea 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 retrimite o cerere cu informațiile corespunzătoare din antetul Authorisation. Dacă cererea curentă conține deja acreditările Authorisation, atunci un răspuns 401 înseamnă că serverul verifică dacă acele acreditări au fost respinse. În cazul în care răspunsul 401 conține aceeași interogare de autentificare ca și răspunsul anterior, iar browserul a făcut deja cel puțin o încercare de autentificare, atunci browserul ar trebui să arate utilizatorului informațiile despre entitate conținute în răspuns, deoarece aceste informații despre entitate pot conține informații de diagnostic relevante. 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 solicitarea nu trebuie să fie trimisă din nou. Dacă aceasta nu este o cerere HEAD, iar serverul dorește să poată spune de ce cererea nu poate fi executată, atunci motivul refuzului ar trebui să fie descris în entitate. Desigur, serverul poate returna și un răspuns 404 dacă nu dorește ca clientul să obțină nicio informație.
404 Cererea a eșuat, resursa solicitată nu a fost găsită pe server. Nu există informații care să 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 serverul 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ă. Deoarece metodele PUT și DELETE scriu în resursa de pe server, majoritatea serverelor web nu le acceptă sau nu le permit implicit și vor returna o eroare 405 pentru astfel de cereri.
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 este vorba de o cerere HEAD, răspunsul trebuie să returneze o entitate care conține cele mai adecvate caracteristici ale entității și o listă de adrese din care utilizatorul sau browserul poate alege. Formatul entității este determinat de tipul media definit în antetul Content-Type. Browserul poate face cea mai bună alegere 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-Authorisation pentru autentificare. A se vedea RFC 2617.
408 Timeout cerere. Clientul nu a finalizat o cerere în intervalul de timp în care serverul era pregătit să aștepte. Clientul poate retrimite cererea în orice moment, fără a face nicio modificare.
409 Cererea nu a putut fi finalizată din cauza unui conflict cu starea curentă 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 adesea în timpul procesării cererilor PUT. De exemplu, într-un mediu de verificare a versiunilor, un PUT trimis pentru a modifica o anumită resursă cu informații privind versiunea care intră în conflict cu o cerere anterioară (terță parte) ar trebui să returneze o eroare 409 care informează 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 aflate în conflict, astfel încât utilizatorul să poată retrimite noua versiune fuzionată.
410 Resursa solicitată nu mai este disponibilă pe server și nu există nicio adresă de redirecționare cunoscută. O astfel de situație ar trebui să fie 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ă situația este permanentă, atunci ar trebui utilizat un cod de stare 404. Dacă nu se specifică altfel, acest răspuns poate fi stocat în cache. Scopul răspunsului 410 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 de la distanță la resursă să fie șterse. 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 clientul că o resursă aparținând unei persoane nu mai este disponibilă pe site-ul actual al serverului. Desigur, întrebarea dacă toate resursele permanent indisponibile trebuie să fie marcate ca atare și cât timp trebuie să fie menținute astfel este, de asemenea, importantă.'410 Gone'， și cât timp ar trebui să fie menținută este în întregime la latitudinea proprietarului serverului.
411 Serverul refuză să accepte cereri fără antetul Content-Length definit. Clientul poate retrimite cererea după adăugarea unui antet Content-Length valid care să indice lungimea corpului mesajului de cerere.
412 Serverul nu a reușit să îndeplinească una sau mai multe dintre condițiile prealabile indicate în câmpul de antet al cererii la validarea cererii. Acest cod de stare permite clientului să stabilească precondiții în metainformațiile 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 prezintă mai multe date fizice decât dorește sau poate serverul să gestioneze. În acest caz, serverul poate închide conexiunea pentru a împiedica clientul să continue să trimită cererea. Dacă situația este temporară, serverul ar trebui să returneze un antet Retry-After pentru a informa clientul cât timp are la dispoziție pentru o nouă încercare.
414 URI-ul cererii este mai lung decât poate interpreta serverul, astfel încât serverul refuză să servească cererea. Acest lucru este rar și apare, de obicei, 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 pentru 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 solicitat, ceea ce poate duce la o depășire a buffer-ului atunci când parametrul GET depășește o anumită valoare, ducând 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 și cererea este respinsă.
416 În cazul în care cererea conține un antet de cerere Range, iar orice interval de date specificat în Range nu coincide cu intervalele disponibile pentru resursa curentă, iar cererea nu definește un antet de cerere If-Range, atunci serverul ar trebui să returneze un cod de stare 416. Dacă intervalul utilizează intervale de octeți, înseamnă că primul octet din toate intervalele 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 serverul 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 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, gateway-ul utilizatorului sau adresa serverului proxy). În acest caz, mai mult de un utilizator final poate fi implicat în numărul de conexiuni.
422 Numărul de conexiuni de la adresa IP a clientului curent la server 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, mai mult de un utilizator final poate fi implicat în numărul de conexiuni.
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) 423 Blocat
424 Cererea curentă a eșuat din cauza unei erori î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 Extins de Microsoft pentru a reprezenta faptul că cererile ar trebui reluate după ce a fost efectuată acțiunea corespunzătoare.
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 caracteristică cerută de solicitarea curentă. Atunci când serverul nu recunoaște metoda solicitată și nu poate susține 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ă o perioadă de timp. Dacă este de așteptat 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 acționează ca gateway sau proxy 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 motivul pentru care versiunea nu este acceptată și ce protocoale acceptă serverul.
506 Extended by the Transparent Content Negotiation Protocol (RFC 2295) to represent an internal misconfiguration on the part of the server: 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 îndeplini cererea. 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 îndeplinită. (RFC 2774)
Accesul la înregistrări: