| HTTP állapotkód |
Az állapotkód jelentése |
| 100 |
A kliensnek folytatnia kell a kérés küldését. Ez a dobozválasz arra szolgál, hogy értesítse a klienst, hogy a kérésének egy része már érkezett a szerverhez, de még nem lett elutasítva. A kliens folytathatja a kérés további részének küldését, vagy ha a kérés befejeződött, figyelmen kívül hagyhatja ezt a választ. A szervernek végső választ kell küldenie a kliensnek, amikor a kérés befejeződött. |
| 101 |
A szerver megértette a kliens kérését, és az Upgrade fejléccel értesíti a klienst, hogy más protokollt használnak a kérés teljesítéséhez. Miután ezt a választ elküldték, a szerver a fejlécekben definiált protokollokra vált. Csak akkor érdemes hasonló lépéseket tenni, ha az új protokoll használata előnyösebb. Például, ha az új HTTP verzió előnyösebb, mint a régi, vagy ha egy valós idejű és szinkronizált protokollra váltanak, hogy olyan tartalmakat továbbítsanak, amelyek kihasználják ezeket a képességeket. |
| 102 |
WebDAV (RFC 2518) által kiterjesztett állapotkód, amely azt jelzi, hogy a feldolgozás folytatódik. |
| 200 |
A kérés sikeresen teljesült, a válaszban a kívánt fejléc vagy adat test részeként visszatérnek. |
| 201 |
A kérés végrehajtásra került, és egy új erőforrást hoztak létre a kérelem szükségletei alapján, és a URI a Location fejléccel visszatér. Ha az erőforrás nem hozható létre azonnal, '202 Accepted' státuszt kell visszaadni. |
| 202 |
A szerver elfogadta a kérést, de még nem dolgozta fel. Mint ahogy elutasíthatják is, a végén a kérés lehet, hogy végrehajtásra kerül, vagy nem. Aszinkron műveletek esetén nem volt egyszerűbb mód, mint a 202 státuszkódot küldeni. A 202 státuskódú válasz célja, hogy lehetővé tegye a szerver számára más folyamatok kérésének fogadását (például egy napi egyszeri, kötegelésen alapuló művelet) anélkül, hogy a kliensnek folyamatosan fenn kellene tartania a kapcsolatot a szerverrel, amíg a kötegelési művelet befejeződik. A kérés feldolgozásának elfogadása és 202 statuszódú válasz visszaadásakor a válasznak tartalmaznia kell némi tájékoztatást a jelenlegi állapotról, valamint arra mutató hivatkozást, hogy a felhasználó képes legyen becsülni, hogy a művelet befejeződött-e. |
| 203 |
A szerver sikeresen kezelte a kérést, de a visszaadott dokumentum fejlécének metainformációja nem az eredeti szerveren érvényes, hanem helyi vagy harmadik féltől származó másolat. A jelenlegi információ lehet, hogy az eredeti verzió részhalmaza vagy túlnézete. Például a forrás metadátumai arra lehetnek képesek, hogy az eredeti szerver ismerje a metainformációk többletét. Az ilyen státuszkód használata nem kötelező, és csak akkor megfelelő, ha a válasz nélküli válasz ezen státuszkód használata 200 OK lenne. |
| 204 |
A szerver sikeresen kezelte a kérést, de nem szükséges egyedülálló tartalom visszaadása, helyette inkább frissített metainformációkat szeretne retornálni. A válasz formájában új vagy frissített metainformációk lánca lehetséges. Ha vannak ilyen fejlécek, akkor válaszolnia kell a kért változókra. Ha a kliens böngésző példánya, akkor a böngészőnek meg kell őriznie azt az oldalt, ahonnan ezt a kérést küldték, és nem kell megváltoztatnia a dokumentum megjelenítését, még akkor sem, ha a specifikáció szerint az új vagy frissített információkat a böngésző tevékenységének megjelenítésébe is be kellene alkalmazni. Mivel a 204 válasznak nem szabad tartalmaznia semmilyen üzenettestet, mindig a következő üzenetfejléc üres sorával ér véget. |
| 205 |
A szerver sikeresen kezelte a kérést, és nem ad vissza semmilyen tartalmat. Azonban a 204 válasszal ellentétben ennek a státuszkódnak a válaszának el kell követnie a kérők dokumentum megjelenítési felfrissítését. Ezt a választ akkor használják, amikor a felhasználói bementek után a formanyomtatvány azonnali visszaállítása a következő bemenetre lehetővé teszi a felhasználót. A 204 válaszhoz hasonlóan ez a válasz is megakadályozza az üzenettest beillesztését, és az üzenetfejléc után az első üres sorral ér véget. |
| 206 |
A szerver már sikeresen feldolgozta a részleges GET kérést. Az ilyen válaszokat a FlashGet vagy a Thunder használja, hogy támogatást nyújtson a folytathatóságra vagy egy nagy dokumentum továbbítására több letöltési szegmenst egyszerre letöltve. A kérelemnek tartalmaznia kell a Range fejlécként, amely megadja a kliensnek, hogy mely tartományt szeretne megkapni, és esetleg If-Range-t, mint a kérelem feltételét. A válasznak a következő fejlec mezőket kell tartalmaznia: Content-Range a válaszban lévő tartalom tartományának megadásához; ha a Content-Type multipart/byteranges, minden multipart résznek tartalmaznia kell a Content-Range mezőt, hogy jelezze annak tartalmát. Ha a válasz tartalmaz Content-Length-t, akkor az száma meg kell hogy egyezzen a visszaadott tartomány valódi byte-méretével. Date, ETag és/vagy Content-Location, ha a kérelem eredetileg 200 választ kellett volna kapnia. Expires, Cache-Control, és/vagy Vary, ha az értékek eltérhetnek korábbi válaszokban elérhető más változókkal. Ha a válasz kérése If-Range-t használott kellett volna erősítési hitelesítést kérni, ez a válasz ne tartalmazzon egyéb entity-headert; ha a válasz kérése If-Range-n gyenge cache verifikációt használt, akkor ez a válasz ne tartalmazzon egyéb entity-headert, elkerülve a cacheolt tartalom és az új entity-fejlécek közötti inkonzisztenciát. Ellenkező esetben ez a válasznak tartalmaznia kell minden entity-headert, amelyet egy 200 válaszként kellett volna visszaadni. Ha az ETag vagy Last-Modified fejlécek nem egyeznek, a kliens cache-nek meg kell akadályoznia a 206 válaszként visszaadásához használt tartalmakat. |
| 207 |
WebDAV (RFC 2518) kiterjesztett állapotkód, amely jelzi, hogy a következő üzenettörzs XML üzenet lesz, és az korábban történő al-kérdések száma alapján különféle válaszkódokat tartalmazhat. |
| 300 |
A kért forrásnak számos választható visszajelzése van, mindegyik saját címével és az internetböngésző által megjelenített információkkal. A felhasználó vagy a böngésző saját preferenciái alapján választhat redirekciós címet. Kivéve, ha ez egy HEAD kérés, a válasznak egy forrás jellemzőit és címét tartalmazó dokumentumnak kell lennie, amelyből a felhasználó vagy böngésző választja ki a legmegfelelőbb redirekciós címet. A dokumentum formátumát a Content-Type által meghatározott formátum határozza meg. A böngésző automatikusan hozhat meg legmegfelelőbb választ a válasz formátuma és a böngésző saját képességei alapján. Természetesen az RFC 2616 előírásai nem határozzák meg, hogy az automatikusan leválasztott mód hogyan történik. Ha a szerver rendelkezik a preferált választási lehetőségekkel, azokat a helyen kell feltüntetni, a böngésző azt az automatikusan átnézés címeként használhatja. Kivéve, ha egy másik redirekciós cím meg van határozva, ez a válasz is cache-elhető. |
| 301 |
A kért forrás véglegesen áthelyezésre került egy új helyre, és a jövőbeli valahány forrás hivatkozásnak a válaszban visszaküldött URI egyikét kell használnia. Ha lehetséges, a kliensnek automatikusan ki kell cserélnie a kért címet a szerver által visszaadott addressre. Kivéve, ha egyébként meg van határozva, ez a válasz is cache-elhető. Az új végleges URI-t a válasz Location területén kell megadni. Kivéve, ha ez egy HEAD kérés, a válasznak az új URI-ra hivatkozó hyperlinket és egy rövid leírást kell tartalmaznia. Ha ez nem GET vagy HEAD kérelem, akkor a böngészőnek meg kell akadályoznia, hogy automatikusan redirekción jusson el, kivéve, ha a felhasználó visszaigazolja, mert a kérés feltételei ettől változhatnak. Megjegyzés: egyes HTTP/1.0 protokollt használó böngészők, amikor POST kéréseket 301 válaszban küldenek, a következő redirekciós kérések GET módszerre módosulnak. |
| 302 |
A kért erőforrás most átmenetileg egy másik URI címén válaszol a kérésre. Mivel a redirekció átmeneti, a kliensnek folytatnia kell a későbbi kérések küldését az eredeti címre. Csak akkor cache-elhető, ha azt a Cache-Control vagy Expires megadta. Az új átmeneti URI-t a válasz Location területén kell megadni. Kivéve, ha ez egy HEAD kérés, a válasznak tartalmaznia kell az új URI-ra mutató hyperlinket és egy rövid leírást. Ha ez nem GET vagy HEAD kérés, akkor a böngészőnek meg kell akadályoznia, hogy automatikusan redirekción lekövetett lehessen, kivéve, ha a felhasználó megerősítette, mivel a kérés feltételei lehet, hogy megváltoznak. Megjegyzés: bár az RFC 1945 és az RFC 2068 megjegyzései nem teszik lehetővé, hogy a kliens redirekció során módosítsa a kérések kérésmódját, sok létező böngésző a 302 választ 303 válaszként tekint, és a Location-ban meghatározott URI-t GET módszerrel látogatja, figyelmen kívül hagyva az eredeti kérés módját. A 303 és 307 státuszkódok azért kerültek bevezetésre, hogy világossá tegyék, hogy a szerver milyen reakciót vár el a klienstől. |
| 303 |
A jelenlegi kéréshez tartozó válasz egy másik URI-n található, és a kliensnek GET módszert kell használnia ennek az erőforrásnak a megközelítéséhez. Ez a módszer főként lehetővé teszi a különböző POST kérelem által aktivált redirekciót egy új erőforrásra. Ez az új URI nem az eredeti forrás helyettesítő hivatkozása. Ugyanakkor a 303 válasz nem cache-elhető. Természetesen a második kérés (redirekció) cache-elhető. Az új URI-t a válasz Location területén kell megadni. Kivéve, ha ez egy HEAD kérés, a válasznak tartalmaznia kell egy hivatkozást az új URI-ra és egy rövid leírást. Megjegyzés: sok, a HTTP/1.1-en korábbi verziójú böngésző nem érti helyesen a 303 státuszkódot. Ha figyelembe kell venni az ilyen böngészőkkel való kölcsönhatást, a 302 státuszkód megfelelően működik, mivel a legtöbb böngésző az 302 válaszok kezelésével foglalkozik, pontosan így, ahogy a szabványok szerint elvárják a klienstől a 303 válaszok kezelését. |
| 304 |
Ha a kliens egyszeri feltételes GET kéréssel rendelkezik, amelyet már megengedtek, és a dokumentum tartalma az utolsó megtekintés óta vagy a kért feltételek szerint nem változott, a szervernek ezt a státuszkódot kell felszolgálnia. A 304 válasz nem tartalmazhat üzenettörzset, így mindig a következő üzenetfejléc üres sorával ér véget. A válasznak tartalmaznia kell a következő fejlesztéseket: Date, hacsak a szerver nem rendelkezik órával. Ha a szerver, amelynek nincs órája, szintén betartja ezeket a szabályokat, a proxykiszolgálók és a kliensek maguk is hozzáadhatják a kapott válaszok fejléceihez Date mezőket (ahogyan az RFC 2068 írja le), és a cache mechanizmusnak normálisan működnie kell. ETag és/vagy Content-Location, ha a kérelem eredetileg 200 válaszra kellett volna, Expires, Cache-Control és/vagy Vary, ha értékek eltérhetnek a korábbi válaszoknál. Ha a jelenlegi kérés megerősítő cache-verifikációval kéri, ez a válasz ne tartalmazzon egyéb entity-headert; ellenkező esetben (például a feltételes GET kérelem gyenge cache-verifikációt használt), ez a válasz ne tartalmazzon egyéb entity-headert, elkerülve a cacheolt entity tartalom és a frissített entity-fejlécek közötti inkonzisztenciát. Ha egy 304 válasz jelez valamilyen entitás nem cache-olt, akkor a cache rendszereknek figyelmen kívül kell hagyniuk ezt a választ, és újból fel kell kérniük az érvényesítés nélküli kéréseket. Ha egy 304 válasz a cachebe beadott elem frissítését igényli, akkor a cache rendszereknek frissíteniük kell az egész bejegyzést, hogy tükrözze minden frissített mezőt valóságos értékével a válaszban. |
| 305 |
A kéréshez a megadott proxyn keresztül kell hozzáférni. A Location mezőben megadott információ nyújtja a megadott proxyt. A vevőnek újra meg kell küldenie egy külön kérést, hogy a proxyval hozzáférhessen a megfelelő forráshoz. Csak az eredeti szerver képes 305 választ előidézni. Megjegyzés: az RFC 2068 nem határozza meg a 305 státuszkódot, mint amelyet egy egyéni kérés átirányítására használnak, és csak az eredeti szerver által létrehozhatók. E területek figyelmen kívül hagyásának komoly biztonsági következményei lehetnek. |
| 306 |
A legújabb specifikációkban a 306 státuszkód már nem használatos. |
| 307 |
A kért forrás most átmenetileg egy másik URI címén válaszol a kérésre. Mivel a redirekció átmeneti, a kliensnek folytatnia kell a későbbi kérések küldését az eredeti címre. Csak akkor cache-elhető, ha azt a Cache-Control vagy Expires megadta. Az új átmeneti URI-t a válasz Location területén kell megadni. Kivéve, ha ez egy HEAD kérés, a válasznak tartalmaznia kell az új URI-ra mutató hyperlinket és egy rövid leírást. Mivel egyes böngészők nem értik a 307 választ, ezért azt az elsődleges információt kell tartalmaznia, hogy a felhasználók megértsék, és új hozzáférés kérést generáljanak az új URI-n. Ha ez nem GET vagy HEAD kérés, a böngészőnek meg kell akadályoznia, hogy automatikusan redirekcionalis lehetősége legyen, kivéve, ha a felhasználó megerősítette, mivel a kérés feltételei ettől változhatnak. |
| 400 |
1. Szintaktikai hiba, a jelenlegi kérés nem érthető a szerver számára. A kliensnek nem kellene újra benyújtania ezt a kérést a módosítások nélkül. 2. A kérés paraméterei helytelenek. |
| 401 |
A jelenlegi kérés felhasználói hitelesítést igényel. A válasznak tartalmaznia kell egy WWW-Authenticate információfejléceket, hogy megkérdőjelezze a felhasználói információt. A kliens újból benyújthat egy kérdést, amely tartalmazza a megfelelő Authorization fejlécet. Ha a jelenlegi kéréshez is tartalmazza az Authorization hitelesítést, akkor a 401 válasz azt mutatja, hogy a szerver elutasította az ilyen hitelesítéseket. Ha a 401 válasz azonos az előzőval a hitelesítési kéréssel, és a böngésző legalább egyszer próbálkozik, akkor a böngészőnek meg kell mutatnia az adott válaszban lévő entitásinformációt, mivel ez tartalmazhat diagnosztikai információkat. Lásd: RFC 2617. |
| 402 |
Ez a státuszkód a jövőbeni igényekre van fenntartva. |
| 403 |
A szerver megértette a kérést, de megtagadta annak végrehajtását. A 401 válasszal ellentétben a hitelesítés nem tud segíteni, és nem javasolt a kérés újra benyújtása. A válaszmegadás elsődleges célja, hogy a szerver a kérést elutasítsa. Ha ez nem egy HEAD kérés, és a szerver szeretné elmondani, miért nem tudta végrehajtani a kérést, akkor az entitásban meg kell magyarázni az elutasítást. Természetesen a szerver visszaadhat egy 404-as választ, ha nem akarja, hogy a kliens információkat kapjon. |
| 404 |
A kérés nem teljesült, a kívánt erőforrást nem találják meg a szerveren. Nincs információ, amely tájékoztatná a felhasználót arról, hogy ez az állapot átmeneti vagy állandó. Ha a szerver tudja, hogy az ok, akkor a 410 státuszkódot kellene használni, hogy tájékoztassa a felhasználót, hogy az régi erőforrás valamilyen belső konfigurációs hiba miatt megszűnt, és nincs lehetőség az átirányításra. A 404-es kódot széles körben használják, ha a szerver nem akarja megosztani az elutasítás okát, vagy nincs más megfelelő válasz. |
| 405 |
A kérésből megadott kérési módszer nem használható a megfelelő erőforrás kérésében. A válasz kötelezi az Allow fejlécet, amely lista a megfelelő módszerekről, amelyeket az aktuális erőforrás milyen kérdéseket fogadhat. Tekintettel arra, hogy a PUT és DELETE módszerek írási műveleteket indítanak el a szerveren, a legtöbb webszerver vagy nem támogatja a kérések küldését, vagy alapértelmezett beállítás szerint elutasítja azokat, ezért ezek a kérések 405 hibakódot eredményeznek későbbi használatkor. |
| 406 |
A kérés erőforrása nem felel meg a kérés fejléceiben megadott feltételeknek, és így nem képes választ visszaadni. Kivéve, ha ez egy HEAD kérés, a válasznak tartalmaznia kell egy entitást, amely lehetővé teszi a felhasználó vagy a böngésző számára a legmegfelelőbb entitás jellemzők és címek választását. Az entitás formátumát a Content-Type mezőben definiált média típus határozza meg. A böngésző a formátum és a saját képességek alapján választhat tehát a legjobb lehetőség közül. Azonban a specifikáció nem határoz meg ilyen automatikus választási szabványokat. |
| 407 |
Hasonló a 401 válaszhoz, de a kliensnek autentikálásra van szüksége a proxy szerveren. A proxy szervernek Proxy-Authenticate nevű információt kell visszaadnia a hitelesítés kérésére. A kliens visszatérhet egy Proxy-Authorization információfejléctel a hitelesítésre. Lásd: RFC 2617. |
| 408 |
A kérés időtúllépés. A kliens nem teljesítette a kérést a szerver által megadott várakozási időn belül. A kliens bármikor újra benyújthatja a kérelmet további módosítások nélkül. |
| 409 |
A kérés nem tud teljesülni a kért erőforrások és a jelen állapot közötti ellentmondás miatt. Ez a kód csak akkor használható, ha a felhasználó megérti és képes megoldani az ellentmondást, és újra benyújtja a kérést. A válasznak elegendő információt kell tartalmaznia, hogy az felhasználó felismerje az ellentmondás forrását. Az ellentmondás jellemzően PUT kérés feldolgozása során merül fel. Például egy adott erőforrással kapcsolatos módosítás kísérletének mellékelt verziója ellentmondhat egy korábbi (harmadik felet) kérésnek, ekkor a szervernek 409 hibát kell adnia az értesítéshez. |
| 410 |
A kért erőforrás már nem elérhető a szerveren, és nincs ismert átirányítási cím. Ez az állapot tartósnak tekintendő. Ha lehetséges, a kliensnek, aki link-módosítással rendelkezik, fel kell kérnie, hogy távolítsa el az összes hivatkozást. Ha a szerver nem tudja vagy nem tudja megérteni a státust, akkor a 404 állapotkódot kell megadnia. Kivéve egy másik megjegyzést, a válasz cache-elhető. A 410 válasz célja legfőképp, hogy támogassa a weboldal adminisztrátorait, és értesítse a felhasználót, hogy egy erőforrás nem érhető el, és a szerver birtokosa szeretné, ha minden távoli kapcsolatot törölnének. |
| 411 |
A szerver megtagadja a kérelem elfogadását a Content-Length mező definiálása nélkül. Az érvényes Content-Length fejléc, amely kifejezi a kéri üzenet test hosszát, hozzáadása után a kérés újbóli benyújtása lehetséges. |
| 412 |
A szerver nem tudta érvényesíteni a kérés fejléceiben megadott precondition-ket. Ez a státuszkód lehetővé teszi a kliensek számára, hogy az erőforrások igénylésekor precondition-ket állapítsanak meg a kérés metainformációiban (kérdések fejlécei). Elkerülve a kérelmet, hogy az kívülről irányuljon az általuk kívánt tartalmakon. |
| 413 |
A szerver megtagadja a kérés teljesítését, mert a beküldött entitásadat mérete meghaladja a kiszolgáló által feldolgozáshoz elfogadott könyvkereteket. Ilyen esetben a szerver bezárhatja a kapcsolatot, hogy elkerülje a kliens folytatólagos kéréseit. Ha ez a probléma ideiglenes, a szervernek egy Retry-After fejlécet kellene visszajuttatnia a probléma keletkezésére vonatkozó információkkal. |
| 414 |
A kért URI hossza meghaladta a szerver által értelmezett hosszt, így a szerver megtagadja a kérések kiszolgálását. Ez ritkán fordul elő, az ilyen esetek közé tartozik: a POST módszer szabványos használata GET módszerkóddá, ami túl hosszú kérdés-sorozatot generál. Átirányított URI-k "fekete lyuk", amely minden egyes irányított címet az új URI részeként hozott létre, egyes irányítások után URI hajlásához vezet. A kliens megpróbálja kihasználni a szerverhez tartozó biztonsági réseket. A szerverek fix méretű puffert használnak a kérések URI olvasása vagy kezelése során, egy GET kérés paramétereinek meghatározott magasságainál túlmutatott, ami puffer túlcsordulást okoz, aminek következményeként a válaszkóddal érvényteleníteni próbált 1. Kérelem. Enélkül a tétel nélkül, a 414 státuszkódot a szervereknek meg kell adniuk. |
| 415 |
A jelenlegi kéréshöz tartozó módszer és a kért erőforrás számára a kérelemben benyújtott entitás nem a típus, amelyet a szerver támogat, így a kérést megtagadják. |
| 416 |
Ha a kérelemben Range fejléc van megadva, és a Range megadott adathatárak bármelyike nem fedheti le a jelenlegi erőforrás elérhető határait, és a kérelmen belül nincs If-Range fejléc definiálva, a szervernek 416 kódot kell adnia. Ha a Range byte-értékek használatára vonatkozik, akkor az esetek közé tartozik, amikor a kérelemben megadott határok az első byte-érték helyzetei túllépik a forrást. A szervernek a válasz megfelelően kell kapcsolódnia a 416 kódra a Content-Range fejlécet, amely mutatja a jelenlegi forrás hosszát. Ez a válasz nem használhatja a multipart/byteranges-t mint Content-Type-ját. |
| 417 |
A kérés fejléceiben az Expect-ben jelzett számítási elvárások nem teljesülnek a szerver által, vagy ez a szerver proxy, amely nyilvánvalóan bizonyítja, hogy az elvárásokat a jelenlegi útvonal következő csomópontján nem kötözködhetik. |
| 421 |
A szerverhez való csatlakozások számának átmeneti megzavarása a szerver engedélyezett maximális értékén túl, amely a szerver önálló IP-jére vonatkozik (például a felhasználó átjárója vagy proxy). Ilyen esetekben a csatlakozások száma nemcsak egyetlen terminál felhasználóra összpontosít. |
| 422 |
A kérés helyesnek tűnik, de a jelentése során nem alkalmazható. |
| 423 |
A jelenlegi erőforrás zárolva van (RFC 4918 WebDAV). |
| 424 |
A korábbi kérdés során fellépett hiba miatt a jelenlegi kérés meghiúsult, mint például a PROPPATCH (RFC 4918 WebDAV). |
| 425 |
A WebDav Advanced Collections javasolt de nem szerepel az RFC 3658-ban. |
| 426 |
A kliensnek váltania kellene TLS/1.0-ra (RFC 2817). |
| 449 |
Microsoft kiterjesztés, amely jelzi, hogy a kérést a megfelelő műveletek végrehajtása után kell elküldeni. |
| 500 |
A szerver váratlan eseménybe ütközött, amely megakadályozta a kérés feldolgozását. Általában ez a probléma a szerver kódjának hibája miatt jelentkezik. |
| 501 |
A szerver nem támogatja az aktuális kéréshez szükséges funkciót. Amikor a szerver nem ismeri a kérések módszereit, és nem tud támogatni a bármilyen forrást. |
| 502 |
A szerver, mint gateway vagy proxy, érvénytelen választ kapott a felsőbb szervertől. |
| 503 |
A szerver jelenleg nem tudja kezelni a kérést a karbantartás vagy túlterhelés miatt. Ez az állapot átmeneti és egy idő után helyreáll. Ha az elérés ideje előre látható, válaszban tartalmazhat egy Retry-After fejlécet az esetlegesen visszavárható idővel. Ha a Retry-After információ nem kapható meg, a kliensnek 500-as válaszkezeléssel kellene foglalkoznia. Megjegyzés: a 503-as státuszkód megléte nem kötelező arra, hogy a szerver használja, ha túlterhelés bevitelével nem foglalkozik. Egyes szerverek egyszerűen azt szeretnék, ha elutasítanák a kliensek csatlakozását. |
| 504 |
A szerver, mint gateway vagy proxy, nem tudott időben válaszolni a felsőbb szervtől (URI által azonosítva, mint például HTTP, FTP, LDAP) vagy a segédszervertől (például DNS). Megjegyzés: a proxyk esetleg 400-as vagy 500-as hibát adnak DNS időkülönbséggel. |
| 505 |
A szerver nem támogatja, vagy arra az igényre elutasítja a kérelem során használt HTTP verziót. Ez azt implikálja, hogy a szerver nem tudja, vagy nem hajlandó használni a kliens által használt verziót. A válasznak tartalmaznia kell egy leírást arról, hogy miért nem támogatják a verziót, és azok a protokollok, amelyeket a szerver támogat. |
| 506 |
Az RFC 2295 kiterjesztette a szerver belső alkalmazás hibáját; a kérés által elnavigált tartalmi egység konfigurálva van arra, hogy magát a tartalmat átlépje, ezért nem ideális a figyelembe venni egy navigációs folyamatot. |
| 507 |
A szerver nem tudta tárolni a kérelem teljesítéséhez szükséges tartalmakat. Ez az állapot ideiglenes. WebDAV (RFC 4918) |
| 509 |
A szerver elérte a sávszélesség korlátot. Ez nem hivatalos státuszkód, de így is széles körben használják. |
| 510 |
A megváltozott erőforrások megszerzése érdekében szükséges stratégiák nincsenek megfelelve (RFC 2774). |