| Http állapotkód | Állapotkód jelentése |
|---|
| 100 | Az ügyfélnek folytatnia kell a kérések küldését. Ez az ideiglenes válasz arra szolgál, hogy tájékoztassa az ügyfelet arról, hogy kérésének egy részét a kiszolgáló megkapta, és nem utasította el. Az ügyfélnek folytatnia kell a kérés további részének elküldését, vagy figyelmen kívül kell hagynia ezt a választ, ha a kérés teljes. A kiszolgálónak végleges választ kell küldenie az ügyfélnek, ha a kérés teljes. |
| 101 | A kiszolgáló megértette az ügyfél kérését, és az Upgrade üzenet fejlécén keresztül értesíti az ügyfelet, hogy más protokollt használjon a kérés befejezéséhez. A válasz utolsó üres sorának elküldése után a kiszolgáló átvált az Upgrade üzenetfejlécben meghatározott protokollokra. Ezt csak akkor szabad megtenni, ha előnyösebb az új protokollra való váltás. Például a HTTP egy új verziójára való váltás előnyösebb, mint egy régebbi verzióra, vagy a valós idejű és szinkron protokollra való váltás az ilyen funkciókat kihasználó erőforrások szállítása érdekében. |
| 102 | A WebDAV (RFC 2518) által kibővített állapotkódok jelzik, hogy a feldolgozás folytatódik. |
| 200 | A kérés sikeres volt, és a kérés által kívánt válaszfejléc vagy adattörzs a válaszban visszakerül. |
| 201 | A kérés teljesült, és a kérésnek megfelelően új erőforrás jött létre, amelynek URI-je a Location fejléccel együtt visszaküldésre került. Ha a kért erőforrás nem hozható létre időben, akkor a "202 Accepted" választ kell visszaküldeni. |
| 202 | A kiszolgáló elfogadta a kérést, de még nem dolgozta fel. Ugyanúgy, mint az elutasítás, végül a kérés vagy végrehajtásra kerül, vagy nem. Az aszinkron műveletekkel összefüggésben nincs kényelmesebb, mint ennek az állapotkódnak a küldése. A 202-es státuszkóddal adott válasz visszaküldésének célja, hogy a kiszolgáló más folyamatok kéréseit (például egy naponta csak egyszer végrehajtott kötegelt műveletét) fogadhassa anélkül, hogy az ügyfélnek a kötegelt művelet teljes befejezéséig kapcsolatban kellene maradnia a kiszolgálóval. A feldolgozásra irányuló kérést elfogadó és 202-es állapotkóddal visszajelző válasznak a visszaküldött egységben KELL tartalmaznia a folyamat aktuális állapotát jelző információkat, valamint egy mutatót a feldolgozás állapotfigyelőjére vagy állapotjóslásra, hogy a felhasználó megbecsülhesse, hogy a művelet befejeződött-e. Az ilyen válaszok nem tartalmaznak olyan információkat, amelyek a folyamat aktuális állapotát jelzik. |
| 203 | A kiszolgáló sikeresen feldolgozta a kérést, de a visszaküldött entitásfejléc metainformáció nem az eredeti kiszolgálón érvényes végleges készlet, hanem egy helyi vagy harmadik féltől származó másolat. Az aktuális információ lehet az eredeti változat részhalmaza vagy szuperhalmaza. Például az erőforrásokat tartalmazó metaadatok miatt az eredeti kiszolgáló ismerheti a metainformációk szuperét. Ennek az állapotkódnak a használata nem kötelező, és csak akkor helyénvaló, ha a válasz e nélkül 200 OK-t kapna vissza. |
| 204 | A kiszolgáló sikeresen feldolgozta a kérést, de nem kell fizikai tartalmat visszaadnia, hanem frissített metainformációkat szeretne visszaküldeni. A válasz új vagy frissített metainformációkat küldhet vissza entitásfejlécek formájában. Ha léteznek ilyen fejlécek, azoknak meg kell felelniük a kért változóknak. Ha az ügyfél egy böngésző, akkor a felhasználó böngészőjének meg KELL tartania azt az oldalt, amelyen a kérést elküldték, a dokumentum nézetének módosítása nélkül, még akkor is, ha a specifikáció szerint az új vagy frissített metainformációkat a felhasználó böngészőjének aktív nézetében lévő dokumentumra KELL alkalmazni. Mivel a 204-es válasz nem tartalmazhat semmilyen üzenettörzset, ezért mindig az üzenetfejléc utáni első üres sorral végződik. |
| 205 | A kiszolgáló sikeresen feldolgozta a kérést, és nem küldött vissza semmit. A 204-es választól eltérően azonban az ezt az állapotkódot visszaküldő válasz arra kéri a kérvényezőt, hogy állítsa vissza a dokumentum nézetét. Ezt a választ elsősorban arra használják, hogy a felhasználói bemenet elfogadása után azonnal visszaállítsák az űrlapot, hogy a felhasználó könnyen kezdhessen újabb bemenetet. A 204-es válaszhoz hasonlóan ez a válasz sem tartalmazhat üzenettörzset, és az üzenetfejléc utáni első üres sorral végződik. |
| 206 | A kiszolgáló sikeresen feldolgozta a GET-kérés egy részét. Az olyan HTTP letöltőeszközök, mint a FlashGet vagy a Thunderbolt ezt a fajta választ használják szakaszos letöltések elvégzésére vagy egy nagy dokumentum egyidejűleg több letöltési szegmensre való felbontására. A kérésnek tartalmaznia kell egy Range fejlécet, amely jelzi, hogy az ügyfél milyen tartalmi tartományt szeretne megkapni, és kérési feltételként tartalmazhat egy If-Range-t is. A válasznak a következő fejlécmezőket kell tartalmaznia: Content-Range a válaszban visszaküldött tartalom terjedelmének jelzésére; több szegmensből álló letöltés esetén, amelynek Content-Type-ja multipart/byteranges, minden egyes többrészes szegmensnek tartalmaznia kell egy Content-Range mezőt, amely az adott szegmensben lévő tartalom terjedelmét jelzi. Ha a válasz Content-Length mezőt tartalmaz, akkor annak értékének meg kell egyeznie a visszaküldött tartalmi tartományban lévő bájtok valódi számával. date ETag és/vagy Content-Location, ha ugyanennek a kérésnek 200-as választ kellett volna visszaadnia. Expires, Cache-Control és/vagy Vary, ha értékeik eltérhetnek más, azonos változókat tartalmazó válaszoktól. Expires, Cache-Control és/vagy Vary, ha értékeik eltérhetnek más korábbi válaszok értékeitől ugyanazoknál a változóknál. Ez a válasz NEM KELL, hogy tartalmazzon más entitásfejlécet, ha a kérés If-Range erős gyorsítótár-érvényesítést használ, és NEM KELL, hogy tartalmazzon más entitásfejlécet, ha a kérés If-Range gyenge gyorsítótár-érvényesítést használ; ezzel elkerülhető a gyorsítótárban tárolt entitás-tartalom és a frissített entitásfejléc-információk közötti ellentmondás. Ellenkező esetben ennek a válasznak tartalmaznia KELL az összes olyan entitásfejlécmezőt, amelyet az összes visszaküldendő 200-as válaszban vissza kellett volna küldeni. Ha az ETag vagy a Last-Modified fejlécek nem egyeznek pontosan, az ügyféloldali gyorsítótárnak meg KELL tiltania a 206-os válaszban visszaküldött tartalom kombinálását bármely korábban gyorsítótárazott tartalommal. Minden olyan gyorsítótár, amely nem támogatja a Range és Content-Range fejléceket, nem tárolhatja a 206-os válasz által visszaküldött tartalmat. |
| 207 | A WebDAV (RFC 2518) által kibővített állapotkód azt jelenti, hogy a következő üzenettörzs egy XML-üzenet lesz, és a korábbi részkérdések számától függően több külön válaszkódot is tartalmazhat. |
| 300 | A kért erőforrásnak egy sor alternatív válaszüzenete van, mindegyik saját specifikus címmel és böngészővezérelt tárgyalási információval. A felhasználó vagy a böngésző saját maga választhatja ki az átirányításhoz preferált címet. Hacsak nem HEAD kérésről van szó, a válasznak tartalmaznia kell egy olyan entitást, amely az erőforrás jellemzőinek és címeinek listája, amelyből a felhasználó vagy a böngésző kiválaszthatja a legmegfelelőbb átirányítási címet. Ennek az entitásnak a formátumát a Content-Type definíció formátuma határozza meg. A böngésző a válasz formátuma és a böngésző saját képességei alapján automatikusan elvégezheti a legmegfelelőbb kiválasztást. Természetesen az RFC 2616 specifikáció nem határozza meg, hogyan kell az ilyen automatikus választást elvégezni. Ha maga a kiszolgáló már rendelkezik egy előnyben részesített visszatérési lehetőséggel, akkor ennek a visszatérésnek az URI-jét a Location-ben kell megadni; a böngésző ezt a Location-értéket használhatja az automatikus átirányítás címeként. Ezenkívül ez a válasz is gyorsítótárba helyezhető, hacsak nincs másként megadva. |
| 301 | A kért erőforrás véglegesen átkerült az új helyre, és a jövőbeni hivatkozásoknak a válaszban visszaküldött több URI egyikét kell használniuk. Ha lehetséges, a linkszerkesztési képességgel rendelkező klienseknek automatikusan módosítaniuk kell a kért címet a kiszolgálótól visszakapott címre. Eltérő rendelkezés hiányában ez a válasz is gyorsítótárba helyezhető. Az új állandó URI-t a válasz Location mezőjében kell visszaadni. Hacsak nem HEAD kérésről van szó, a válasz entitásnak tartalmaznia kell egy hiperhivatkozást az új URI-ra és egy rövid leírást. Ha ez nem GET vagy HEAD kérés, a böngészőnek ezért tilos automatikusan átirányítani, hacsak a felhasználó nem erősíti meg, mivel a kérés feltételei ennek következtében megváltozhatnak. Megjegyzés: Néhány HTTP/1.0 protokollt használó böngésző esetében, amikor POST kérést küld és 301-es választ kap, a következő átirányítási kérés GET lesz. |
| 302 | A kért erőforrás most ideiglenesen egy másik URI-ról válaszol a kérésre. Mivel ez az átirányítás ideiglenes, az ügyfélnek továbbra is az eredeti címre kell küldenie a jövőbeni kéréseket. Ez a válasz csak a Cache-Control vagy Expires beállítások esetén gyorsítótárba helyezhető. Az új ideiglenes URI-t a válasz Location mezőjében kell visszaadni. Hacsak nem HEAD kérésről van szó, a válaszegységnek tartalmaznia kell egy hiperhivatkozást az új URI-ra és egy rövid leírást. Ha ez nem GET vagy HEAD kérés, akkor a böngészőnek tilos automatikusan átirányítani, hacsak a felhasználó nem erősíti meg, mivel a kérés feltételei ennek következtében megváltozhatnak. Megjegyzés: Bár az RFC 1945 és RFC 2068 specifikációk nem teszik lehetővé, hogy az ügyfél megváltoztassa a kérés módszerét az átirányításkor, sok létező böngésző a 302-es választ 303-as válaszként kezeli, és a GET-et használja a Location-ben megadott URI elérésére, figyelmen kívül hagyva az eredeti kérés módszerét. A 303-as és 307-es állapotkódok azért kerültek be a rendszerbe, hogy egyértelművé tegyék, milyen választ vár a kiszolgáló az ügyféltől. |
| 303 | Az aktuális kérésre adott válasz egy másik URI-n található, és az ügyfélnek GET használatával kell elérnie ezt az erőforrást. Ez a módszer elsősorban azért létezik, hogy lehetővé tegye a szkript aktivált POST-kérés kimenetének átirányítását egy új erőforrásra. Ez az új URI nem alternatív hivatkozás az eredeti erőforrásra. Továbbá a 303-as választ tilos gyorsítótárba helyezni. Természetesen a második kérés (átirányítás) gyorsítótárba helyezhető. Az új URI-t a válasz Location mezőjében kell visszaadni. Hacsak nem HEAD kérésről van szó, a válaszegységnek tartalmaznia kell egy hiperhivatkozást az új URI-ra és egy rövid leírást. Megjegyzés: A HTTP/1.1 verziót megelőzően sok böngésző nem érti megfelelően a 303 állapotot. Ha ezekkel a böngészőkkel való interakciót kell figyelembe venni, akkor a 302-es állapotkódnak elegendőnek kell lennie, mivel a legtöbb böngésző a 302-es válaszokat pontosan úgy dolgozza fel, ahogyan a fenti specifikáció a 303-as válasz feldolgozásakor megköveteli az ügyféltől. |
| 304 | A kiszolgálónak ezt az állapotkódot KELL visszaküldenie, ha az ügyfél feltételes GET-kérést küld, amelyet engedélyeztek, és a dokumentum tartalma (a legutóbbi látogatás óta vagy a kérés feltételeinek megfelelően) nem változott. 304 A válaszok nem tartalmazhatnak üzenettörzset, ezért mindig az üzenetfejléc utáni első üres sorral végződnek. A válasznak a következő fejléceket KELL tartalmaznia: Dátum, kivéve, ha a kiszolgáló nem rendelkezik órával. Ha az órával nem rendelkező szerver követi ezeket a szabályokat, akkor a proxy szerver és a kliens a Date mezőt a bejövő válasz fejlécéhez saját maga is hozzáadhatja (az RFC 2068-ban meghatározottak szerint), és a gyorsítótárazási mechanizmus megfelelően fog működni.ETag és/vagy Content-Location, ha ugyanez a kérés 200-as választ adott volna vissza.Expires. Expires, Cache-Control és/vagy Vary, ha az érték eltérhet az ugyanarra a változóra adott más korábbi válaszoknak megfelelő értéktől. Ha ez a válaszkérés erős gyorsítótár-érvényesítést használ, akkor ez a válasz nem tartalmazhat más entitásfejlécet; ellenkező esetben (pl. egy feltételes GET-kérés gyenge gyorsítótár-érvényesítést használ), ez a válasz nem tartalmazhat más entitásfejlécet; ezzel elkerülhető a gyorsítótárban tárolt entitástartalom és a frissített entitásfejléc-információk közötti ellentmondás. Ha egy 304-es válasz azt jelzi, hogy egy entitás jelenleg nincs a gyorsítótárban, a gyorsítótárazási rendszernek figyelmen kívül kell hagynia a választ, és a kérést a korlátozás nélkül kell megismételnie. Ha egy 304-es válasz érkezik, amely egy gyorsítótár-bejegyzés frissítését kéri, a gyorsítótárazási rendszernek a teljes bejegyzést frissítenie kell, hogy az tükrözze a válaszban frissített összes mező értékét. |
| 305 | A kért erőforrást a megadott proxy-n keresztül kell elérni. a Location mező információt ad arról az URI-ról, ahol a megadott proxy található. a címzettnek ismételten külön kérést kell küldenie ahhoz, hogy az erőforrást ezen a proxy-n keresztül érje el. Csak az eredeti kiszolgáló hozhat létre 305-ös választ. Megjegyzés: Az RFC 2068-ból nem egyértelmű, hogy a 305-ös válasz egyetlen kérés átirányítására szolgál, és csak az eredeti kiszolgáló készítheti el. E korlátozások figyelmen kívül hagyása komoly biztonsági következményekkel járhat. |
| 306 | A specifikáció legújabb verziójában a 306-os állapotkód már nem használatos. |
| 307 | A kért erőforrás most ideiglenesen egy másik URI-ról válaszol a kérésre. Mivel az ilyen átirányítások ideiglenesek, az ügyfeleknek a jövőben is az eredeti címre kell küldeniük a kéréseket. Ez a válasz csak a Cache-Control vagy Expires beállítások esetén gyorsítótárba helyezhető. Az új ideiglenes URI-t a válasz Location mezőjében kell visszaadni. Hacsak nem HEAD kérésről van szó, a válaszegységnek tartalmaznia kell egy hiperhivatkozást az új URI-ra és egy rövid leírást. Mivel egyes böngészők nem ismerik fel a 307-es választ, a fenti információt hozzá kell adni, hogy a felhasználó megértse és kérhesse az új URI elérését. Ha ez nem GET vagy HEAD kérés, akkor a böngésző tiltja az automatikus átirányítást, hacsak a felhasználó nem erősíti meg, mert a kérés feltételei megváltozhatnak. |
| 400 | 1. Szemantikai hiba történt, és az aktuális kérést a kiszolgáló nem érti. Hacsak nem módosul, az ügyfél nem küldheti el ismételten ezt a kérést. 2. A kérés paraméterei hibásak. |
| 401 | Az aktuális kérés felhasználói hitelesítést igényel. A válasznak tartalmaznia kell egy WWW-Authenticate fejlécet a kért erőforráshoz, amely a felhasználói adatokat kéri. Az ügyfél ismételten elküldhet egy olyan kérést, amely tartalmazza a megfelelő Authorisation fejléc információkat. Ha az aktuális kérés már tartalmaz Authorisation hitelesítő adatokat, akkor a 401-es válasz azt jelenti, hogy a kiszolgáló ellenőrzi, hogy ezeket a hitelesítő adatokat elutasították. Ha a 401-es válasz ugyanazt a hitelesítési lekérdezést tartalmazza, mint az előző válasz, és a böngésző már legalább egyszer megkísérelte a hitelesítést, akkor a böngészőnek meg KELL mutatnia a felhasználónak a válaszban szereplő entitásinformációkat, mivel ezek az entitásinformációk releváns diagnosztikai információkat tartalmazhatnak. Lásd RFC 2617. |
| 402 | Ez az állapotkód a lehetséges jövőbeli követelmények számára van fenntartva. |
| 403 | A kiszolgáló megértette a kérést, de nem hajlandó végrehajtani azt. A 401-es választól eltérően a hitelesítés nem nyújt segítséget, és ezt a kérést nem szabad újra benyújtani. Ha ez nem HEAD kérés, és a kiszolgáló világosan akar beszélni arról, hogy a kérés miért nem hajtható végre, akkor az elutasítás okát az entitáson belül kell leírni. Természetesen a kiszolgáló 404-es választ is adhat vissza, ha nem kíván információt adni az ügyfélnek. |
| 404 | A kérés sikertelen, a kért erőforrás nem található a szerveren. Nincs olyan információ, amelyből a felhasználó megtudhatná, hogy a helyzet átmeneti vagy végleges. Ha a kiszolgáló tisztában van a helyzettel, akkor a 410-es állapotkóddal tájékoztatnia kell a felhasználót arról, hogy a régi erőforrás valamilyen belső konfigurációs mechanizmus miatt tartósan nem elérhető, és hogy nem áll rendelkezésre átirányítás. A 404-es kódot széles körben használják, ha a kiszolgáló nem akarja elárulni, hogy miért utasították el a kérést, vagy ha nem áll rendelkezésre más megfelelő válasz. |
| 405 | A kérés sorában megadott kérési módszerrel nem lehet a megfelelő erőforrást kérni. A válasznak vissza kell adnia egy Allow fejlécet, amely az aktuális erőforráshoz elfogadható kérési módszerek listáját jelzi. Tekintettel arra, hogy a PUT és DELETE módszerek a kiszolgálón lévő erőforrásra írnak, a legtöbb webkiszolgáló nem támogatja ezeket a kérési módszereket, vagy alapértelmezés szerint nem engedélyezi őket, és 405-ös hibaüzenetet küld az ilyen kérések esetén. |
| 406 | A kért erőforrás tartalmi jellemzői nem felelnek meg a kérés fejlécében szereplő feltételeknek, és nem lehet válasz entitást generálni. Hacsak nem HEAD kérésről van szó, a válasznak egy olyan entitást kell visszaadnia, amely az entitások jellemzőinek és címeinek listáját tartalmazza, amelyből a felhasználó vagy a böngésző kiválaszthatja a legmegfelelőbb entitást. Az entitás formátumát a Content-Type fejlécben meghatározott médiatípus határozza meg. A böngészők a formátum és a saját képességeik alapján maguk választhatják ki a legjobbat. A specifikáció azonban nem határoz meg kritériumokat az ilyen automatikus választásokhoz. |
| 407 | Hasonló a 401-es válaszhoz, azzal a különbséggel, hogy az ügyfélnek hitelesítenie KELL a proxykiszolgálónál. A proxykiszolgálónak vissza KELL küldenie egy Proxy-Authenticate-t az identitás lekérdezéséhez. Az ügyfél a hitelesítéshez visszaküldhet egy Proxy-Authorization fejlécet. Lásd RFC 2617. |
| 408 | Kérési időkorlát. Az ügyfél nem fejezte be a kérés elküldését a kiszolgáló által várakozásra felkészített időn belül. Az ügyfél bármikor újra elküldheti a kérést változtatás nélkül. |
| 409 | A kérést nem lehetett befejezni a kért erőforrás aktuális állapotával való ütközés miatt. Ez a kód csak akkor használható, ha a felhasználó képesnek ítéli magát a konfliktus feloldására és egy új kérés ismételt elküldésére. A válasznak elegendő információt kell tartalmaznia ahhoz, hogy a felhasználó felfedezze a konfliktus forrását. A konfliktusok jellemzően a PUT-kérelmek feldolgozása során fordulnak elő. Például egy verzióellenőrző környezetben, ha egy adott erőforrás módosítására benyújtott PUT kérelemhez csatolt verzióinformáció ütközik egy korábbi (harmadik féltől származó) kérelemmel, a kiszolgálónak 409-es hibaüzenetet kell küldenie, amely tájékoztatja a felhasználót, hogy a kérelmet nem lehetett teljesíteni. Ebben az esetben a válasz entitás valószínűleg tartalmazza a két ütköző verzió közötti különbségek összehasonlítását, hogy a felhasználó az egyesítés után újra elküldhesse az új verziót. |
| 410 | A kért erőforrás már nem elérhető a kiszolgálón, és nincs ismert továbbítási címe. Az ilyen állapotot állandónak kell tekinteni. Ha lehetséges, a linkszerkesztési képességgel rendelkező klienseknek a felhasználó engedélyével el kell távolítaniuk minden hivatkozást erre a címre. Ha a kiszolgáló nem tudja, vagy nem tudja megállapítani, hogy ez az állapot állandó-e, akkor 404-es állapotkódot kell használni. Eltérő megjegyzés hiányában ez a válasz gyorsítótárba helyezhető. 410 A válasz célja elsősorban az, hogy segítse a webmestert a webhely karbantartásában, tájékoztatva a felhasználót arról, hogy az erőforrás már nem elérhető, és hogy a kiszolgáló tulajdonosa szeretné, ha az erőforráshoz vezető összes távoli kapcsolat is megszűnne. Az ilyen típusú esemény gyakori az időbeli korlátozású, értéknövelt szolgáltatásoknál. Hasonlóképpen, a 410-es válasz arra szolgál, hogy értesítse az ügyfeleket arról, hogy egy erőforrás, amely eredetileg az aktuális kiszolgálóhelyen lévő egyénhez tartozott, már nem elérhető. Természetesen teljesen a kiszolgáló tulajdonosán múlik, hogy minden tartósan nem elérhető erőforrást "410 Elmúlt" jelzéssel kell-e ellátni, és hogy ezt a jelölést mennyi ideig kell fenntartani. |
| 411 | A kiszolgáló nem fogadja el a Content-Length fejléc nélküli kéréseket. Miután a kérés üzenettörzsének hosszát jelző érvényes Content-Length fejlécet hozzáadta, az ügyfél újra elküldheti a kérést. |
| 412 | A kiszolgáló a kérelem fejléc mezőjében megadott előfeltételek közül egyet vagy többet nem teljesített, amikor ellenőrizte azokat. Ez az állapotkód lehetővé teszi az ügyfél számára, hogy az erőforrás megszerzésekor a kérés metaüzenetében (a kérés fejlécmezőjének adatai) előfeltételeket állítson be, így megakadályozza, hogy a kérési módszert az általa kívánt tartalomtól eltérő erőforrásokra alkalmazzák. |
| 413 | A kiszolgáló megtagadja az aktuális kérés feldolgozását, mivel az olyan méretű entitásadatokat küld, amelyek mérete nagyobb, mint amekkorát a kiszolgáló kezelni akar vagy tud. Ebben az esetben a kiszolgáló lezárhatja a kapcsolatot, hogy megakadályozza, hogy az ügyfél tovább küldje ezt a kérést. Ha ez a feltétel átmeneti, a kiszolgálónak vissza kell küldenie egy Retry-After válaszfejlécet, hogy tájékoztassa az ügyfelet arról, hogy mennyi idő után próbálkozhat újra. |
| 414 | A kérés URI-jának hossza meghaladja a kiszolgáló által értelmezhető hosszúságot, ezért a kiszolgáló megtagadja a kérés kiszolgálását. Ez ritkán fordul elő, és gyakran akkor, amikor egy olyan űrlapküldés, amelynek POST módszert kellett volna használnia, GET módszerré válik, ami hosszú lekérdezési karakterláncot eredményez. Átirányítási URI "fekete lyukak", például a régi URI használata az új URI részeként minden egyes átirányításnál, ami több átirányítás után hosszú URI-t eredményez. Az ügyfelek megpróbálják megtámadni a kiszolgálókat, kihasználva az egyes kiszolgálókban meglévő biztonsági réseket. Az ilyen szerverek fix hosszúságú puffert használnak a kérés URI-jának olvasására vagy manipulálására, és ha a GET után a paraméterek meghaladnak egy bizonyos értéket, puffer túlcsordulás következhet be, ami tetszőleges kódfuttatáshoz vezethet [1]. Az ilyen sebezhetőséggel nem rendelkező szervereknek 414-es státuszkódot kell visszaküldeniük. |
| 415 | Az aktuálisan kért módszer és kért erőforrás esetében a kérelemben megadott entitás nem a kiszolgáló által támogatott formátumban van, ezért a kérelem elutasításra kerül. |
| 416 | Ha a kérés Tartomány kérés fejlécet tartalmaz, és a Tartományban megadott adattartományok nem fedik át az aktuális erőforráshoz rendelkezésre álló tartományokat, és az If-Tartomány kérés fejléc nincs definiálva a kérésben, akkor a kiszolgálónak 416 státuszkódot kell visszaküldenie. Ha a Range bájt-tartományokat használ, akkor ez a helyzet akkor áll fenn, ha a kérésben megadott összes adattartomány első bájtpozíciója meghaladja az aktuális erőforrás hosszát. A kiszolgálónak a 416-os állapotkóddal együtt egy Content-Range entitásfejlécet is tartalmaznia kell, amely megadja az aktuális erőforrás hosszát. Ez a válasz szintén nem használhatja a multipart/byteranges-t Content-Type-típusként. |
| 417 | A kérelem Expect fejlécében megadott elvárt tartalom nem teljesíthető a kiszolgáló által, vagy ez a kiszolgáló egy proxy-kiszolgáló, amely egyértelmű bizonyítékkal rendelkezik arra, hogy az Expect tartalma nem teljesíthető az aktuális útvonal következő csomópontjánál. |
| 421 | A szerverhez az aktuális ügyfél IP-címéről érkező kapcsolatok száma meghaladja a szerver által megengedett maximumot. Az IP-cím itt jellemzően az ügyfélnek a kiszolgálóról látható címét jelenti (pl. a felhasználó átjárójának vagy proxykiszolgálójának címét). Ebben az esetben a kapcsolatszám egynél több végfelhasználót is érinthet. |
| 422 | Az aktuális ügyfél IP-címéről a kiszolgálóhoz való kapcsolódások száma meghaladja a kiszolgáló által megengedett maximumot. Az IP-cím itt jellemzően az ügyfélnek a kiszolgálóról látható címét jelenti (pl. a felhasználó átjárójának vagy proxy-kiszolgálójának címét). Ebben az esetben a kapcsolatszám egynél több végfelhasználót is érinthet. |
| 422 | A kérés helyesen volt formázva, de nem lehetett rá válaszolni, mert szemantikai hibákat tartalmazott. (RFC 4918 WebDAV) 423 Zárolt Az aktuális erőforrás zárolt. (RFC 4918 WebDAV) |
| 424 | Az aktuális kérés egy korábbi kérésben, például a PROPPATCH-ban bekövetkezett hiba miatt sikertelen (RFC 4918 WebDAV). |
| 425 | A WebDav Advanced Collections tervezetben definiált, de nem jelenik meg a WebDAV Sequential Collections Protocol (RFC 3658) protokollban. |
| 426 | Az ügyfeleknek TLS/1.0-ra kell váltaniuk.(RFC 2817) |
| 449 | A Microsoft által kibővített kifejezés, amely azt jelzi, hogy a kéréseket a megfelelő művelet elvégzése után újra meg kell próbálni. |
| 500 | A kiszolgáló olyan váratlan körülménybe ütközött, amely megakadályozta a kérés feldolgozásának befejezésében. Ez a probléma általában akkor fordul elő, ha a kiszolgáló programkódjában hiba van. |
| 501 | A kiszolgáló nem támogat egy adott funkciót, amely az aktuális kéréshez szükséges. Amikor a kiszolgáló nem képes felismerni a kért módszert, és nem tudja támogatni a kérését semmilyen erőforráshoz. |
| 502 | Az átjáróként vagy proxyként működő kiszolgáló érvénytelen választ kap egy feljebb lévő kiszolgálótól, amikor megpróbál végrehajtani egy kérést. |
| 503 | A kiszolgáló ideiglenes szerverkarbantartás vagy túlterhelés miatt jelenleg nem tudja feldolgozni a kérést. Ez az állapot átmeneti, és egy idő után helyreáll. Ha késedelemre lehet számítani, a válasz tartalmazhat egy Retry-After fejlécet a késedelem jelzésére. Ha ez a Retry-After információ nincs megadva, akkor az ügyfélnek ugyanúgy kell kezelnie, mint egy 500-as választ. Megjegyzés: Az 503-as állapotkód létezése nem jelenti azt, hogy a kiszolgálónak használnia kell, ha túlterhelt. Egyes kiszolgálók egyszerűen csak meg akarják tagadni az ügyféltől a kapcsolatot. |
| 504 | Az átjáróként vagy proxyként működő kiszolgáló, amely megpróbál egy kérést végrehajtani, nem kap időben választ egy upstream kiszolgálótól (URI által azonosított kiszolgáló, például HTTP, FTP, LDAP) vagy egy másodlagos kiszolgálótól (például DNS). Megjegyzés: Egyes proxy-kiszolgálók 400-as vagy 500-as hibát küldenek vissza, amikor a DNS-keresés megszakad. |
| 505 | A kiszolgáló nem támogatja, vagy nem hajlandó támogatni a HTTP-nek a kérelemben használt verzióját. Ez azt jelenti, hogy a kiszolgáló nem tudja vagy nem akarja ugyanazt a verziót használni, mint az ügyfél. A válasznak tartalmaznia kell egy olyan egységet, amely leírja, hogy miért nem támogatott a verzió, és hogy a kiszolgáló mely protokollokat támogatja. |
| 506 | Az átlátható tartalomtárgyalási protokoll (RFC 2295) által kibővítve, hogy a kiszolgáló belső hibás konfigurációját jelezze: a kért tárgyalási variáns erőforrás úgy van konfigurálva, hogy önmagát használja az átlátható tartalomtárgyalásban, és ezért nem megfelelő fókuszpontja a tárgyalási folyamatnak. |
| 507 | A kiszolgáló nem tudja tárolni a kérés teljesítéséhez szükséges tartalmat. Ez az állapot ideiglenesnek tekinthető.WebDAV (RFC 4918) |
| 509 | A kiszolgáló elérte a sávszélességi korlátját. Ez nem hivatalos állapotkód, de mégis széles körben használják. |
| 510 | Az erőforrás megszerzéséhez szükséges házirend nem volt teljesíthetetlen. (RFC 2774) |