Online eszközök
Http állapotkódok Á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 fejlécen keresztül értesíti az ügyfelet arról, hogy a kérés befejezéséhez más protokollt használtak. A válasz utolsó üres sorának elküldése után a kiszolgáló átvált az Upgrade fejlécben meghatározott protokollokra. Ezt csak akkor kell megtenni, ha az új protokollra való átállás előnyösebb. Például a HTTP egy új verziójára való váltás előnyösebb lehet, mint egy régebbi verzióra, vagy egy valós idejű, szinkron protokollra való váltás az ilyen funkciókat kihasználó erőforrások átadásához.
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écek vagy adattörzs a válasszal együtt visszakerül.
201 A kérés teljesült, és a kérésre válaszul új erőforrás jött létre, amelynek URI-je a Location fejléccel együtt visszakerült. Ha a kért erőforrás nem hozható létre időben, akkor a következőket kell visszaküldeni'202 Accepted'。
202 A kiszolgáló elfogadta a kérést, de még nem dolgozta fel. Ahogyan az is előfordulhat, hogy a kérés elutasításra kerül, úgy az is előfordulhat, hogy végül nem kerül végrehajtásra. Aszinkron műveletek esetén nincs kényelmesebb, mint ennek az állapotkódnak a küldése. A 202-es válasz visszaküldésének célja, hogy a kiszolgáló más folyamatoktól (például egy naponta csak egyszer végrehajtott kötegelt művelettől) származó kéréseket fogadhasson anélkül, hogy az ügyfélnek a kötegelt művelet befejezéséig kapcsolatot kellene fenntartania a kiszolgálóval. A feldolgozásra irányuló kérést elfogadó és 202-es státuszkódot visszaküldő válasznak a visszaküldött entitásban tartalmaznia kell 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ó meg tudja becsülni, hogy a művelet befejeződött-e vagy sem.
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 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 adhat vissza entitásfejlécek formájában. Ha ezek a fejlécek léteznek, akkor meg kell felelniük a kért változóknak. Ha az ügyfél egy böngésző, a felhasználó böngészőjének a dokumentum nézetének módosítása nélkül KELL megtartania azt az oldalt, amelyen a kérést elküldték, még akkor is, ha az új vagy frissített metainformációkat a specifikáció szerint 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 kezeli a kérést, és nem küld vissza semmit. Azonban a 204-es választól eltérően 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. Ez a válasz elsősorban arra szolgál, hogy a felhasználói bemenet elfogadása után azonnal visszaállítsa 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 nagyméretű fájl egyidejűleg több letöltésre való felosztá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, vagy több részből álló letöltések esetén, amelyek Content-Type-ja multipart/byteranges, egy Content-Range mezőt minden egyes többrészes szegmensben az adott szegmensben lévő tartalom terjedelmének jelzésére. Ha a válasz Content-Length mezőt tartalmaz, akkor annak értékének meg kell egyeznie a visszaküldött tartalomtartományban található bájtok valódi számával. Expires, Cache-Control és/vagy Vary, ha értékeik eltérhetnek az azonos változókkal rendelkező korábbi válaszok értékeitől. Ez a válasz nem tartalmazhat más entitásfejlécet, ha a kérés erős If-Range gyorsítótár-érvényesítést használ, és nem tartalmazhat más entitásfejlécet, ha a kérés gyenge If-Range 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 a 200-as válaszban kellett volna visszakü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 a 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 által kiterjesztett állapotkódok(RFC 2518) A WebDAV á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álasza van, mindegyik saját egyedi címmel és böngészővezérelt tárgyalási információval. A felhasználó vagy a böngésző feladata, hogy kiválassza 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, hogy ezt az automatikus kiválasztást hogyan kell elvégezni. Ha maga a kiszolgáló már rendelkezik egy preferált válaszadási lehetőséggel, akkor a Location-ben meg kell adni a válasz URI-jét; a böngészők ezt a Location-értéket használhatják az automatikus átirányítás címeként. Ezen kívül a válasz 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 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 a jövőben is az eredeti címre kell küldenie a kéréseket. A válasz csak a Cache-Control vagy az Expires beállítások megadása 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 az átirányítás során megváltoztassa a kérés módszerét, 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 script-aktivált POST-kérés kimenetének átirányítását egy új erőforrásra. Ez az új URI nem helyettesítő hivatkozás az eredeti erőforrásra. Továbbá a 303-as választ nem szabad 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: Sok HTTP/1.1 előtti böngésző nem érti megfelelően a 303 állapotot. Ha ezekkel a böngészőkkel való interakciót kell figyelembe venni, a 302-es állapotkódnak működnie kell, mivel a legtöbb böngésző a 302-es választ pontosan úgy kezeli, ahogy a fenti specifikáció szerint az ügyfélnek a 303-as választ kell kezelnie.
304 Ezt az állapotkódot a kiszolgálónak akkor kell visszaküldenie, ha az ügyfél feltételes GET-kérést küld, és a kérés engedélyezett, és a dokumentum tartalma nem változott (sem a legutóbbi látogatás óta, sem a kérés feltételeinek megfelelően). 304-es válaszok nem tartalmazhatnak üzenettörzset, ezért mindig az üzenet fejlécét követő első üres sorral végződnek. A válasznak a következő fejlécadatokat kell tartalmaznia: Dátum, kivéve, ha a kiszolgáló nem rendelkezik órával. Ha az órával nem rendelkező kiszolgáló követi ezeket a szabályokat, akkor a proxy-kiszolgáló és az ügyfél a bejövő válasz fejlécéhez a Date mezőt 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 ugyanennek a kérésnek 200-as választ kellett volna adnia. Expires, Cache-Control és/vagy Vary, ha értékeik eltérhetnek az azonos változókkal rendelkező korábbi válaszok értékeitől. Ha a válaszkérelem erős gyorsítótár-érvényesítést használ, akkor a válasz nem tartalmazhat további entitásfejléceket; ellenkező esetben (pl. egy feltételes GET-kérelem gyenge gyorsítótár-érvényesítést használ) a válasz nem tartalmazhat további entitásfejléceket; 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. 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 egy megadott proxy-n keresztül kell elérni. A Location mező információt ad a megadott proxy URI-járól, és 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ó tud 305-ös választ létrehozni. 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ó hozhatja létre. 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ások mostantól ideiglenesen válaszolnak a különböző URI-kről érkező kérésekre. Mivel ez az átirányítás ideiglenes, 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, szükséges a fenti információkat hozzá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, az aktuális kérést a kiszolgáló nem érti. Hacsak nem módosul, az ügyfél nem ismételheti meg a kérést. 2, a kérés paraméterei helytelenek.
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 újra elküldheti a kérést a megfelelő Authorisation fejléc információival. 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 a hitelesítő adatok elutasításra kerültek. 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 egy hitelesítési kísérletet tett, 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ényekre 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 a kérést nem szabad újra benyújtani. Ha ez nem HEAD kérés, és a kiszolgáló meg akarja tudni mondani, hogy a kérés miért nem hajtható végre, akkor az elutasítás okát az entitásban kell leírni. Természetesen a kiszolgáló 404-es választ is adhat vissza, ha nem akarja, hogy az ügyfél bármilyen információt kapjon.
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 kiszolgá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, amikor a kiszolgáló nem akarja elárulni, hogy miért utasították el a kérést, vagy amikor 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. Mivel a PUT és DELETE módszerek a kiszolgálón lévő erőforrásba írnak, a legtöbb webkiszolgáló alapértelmezés szerint nem támogatja vagy engedélyezi ezeket, é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 tartalmazza a legmegfelelőbb entitás jellemzőket és egy címlistát, amelyből a felhasználó vagy a böngésző választhat. Az entitás formátumát a Content-Type fejlécben meghatározott médiatípus határozza meg. A böngésző a formátum és a saját képességei alapján tudja a legjobb választást meghozni. A specifikáció azonban nem határoz meg semmilyen kritériumot az ilyen automatikus választáshoz.
407 Hasonló a 401-es válaszhoz, azzal a különbséggel, hogy az ügyfélnek hitelesítenie kell magát a proxykiszolgálónál. A proxykiszolgálónak egy Proxy-Authenticate-t kell visszaküldenie a személyazonosság lekérdezéséhez. Az ügyfél a hitelesítéshez egy Proxy-Authorisation fejlécet küldhet vissza. Lásd RFC 2617.
408 Kérési időkorlát. Az ügyfél nem fejezte be a kérést a szerver á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 PUT kérések feldolgozása során gyakran fordulnak elő konfliktusok. Például egy verzióellenőrző környezetben egy olyan PUT, amelyet egy adott erőforrás módosítására küldtek be olyan verzióinformációval, amely ütközik egy korábbi (harmadik féltől származó) kéréssel, 409-es hibaüzenetet kell küldenie, amely tájékoztatja a felhasználót, hogy a kérést 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, így a felhasználó újra elküldheti az új, összevont 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ím. Az ilyen helyzetet véglegesnek 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 az állapot állandó-e, akkor 404-es állapotkódot kell használni. Eltérő rendelkezés hiányában ez a válasz gyorsítótárba helyezhető. A 410-es válasz célja elsősorban az, hogy segítse a webmestert a webhely karbantartásában, mivel tájékoztatja a felhasználót, 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 törlődne. 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 ügyfelet arról, hogy egy egyénhez tartozó erőforrás már nem elérhető az aktuális kiszolgálóhelyen. Természetesen az is fontos kérdés, hogy minden tartósan elérhetetlenné vált erőforrást meg kell-e jelölni, és mennyi ideig kell így tartani.'410 Gone'， És hogy ezt meddig kell fenntartani, az teljesen a kiszolgáló tulajdonosán múlik.
411 A szerver nem fogadja el a Content-Length fejléc meghatározása nélküli kéréseket. Az ügyfél újra elküldheti a kérést, miután hozzáad egy érvényes Content-Length fejlécet, amely jelzi a kérés üzenettestének hosszát.
412 A kiszolgáló a kérés érvényesítésénél nem teljesítette a kérés fejléc mezőjében megadott egy vagy több előfeltételt. Ez az állapotkód lehetővé teszi az ügyfél számára, hogy a kérés metainformációjában (a kérés fejléc mezőjének adataiban) előfeltételeket állítson be az erőforrás megszerzésekor, így megakadályozza, hogy a kérési módszert a 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, mert az több fizikai adatot küld, mint amennyit a kiszolgáló kezelni akar vagy képes. Ebben az esetben a kiszolgáló lezárhatja a kapcsolatot, hogy megakadályozza az ügyfelet a kérés további elküldésében. Ha a helyzet átmeneti, a kiszolgálónak vissza kell küldenie egy Retry-After fejlécet, hogy tájékoztassa az ügyfelet, mennyi ideje van az újbóli próbálkozásra.
414 A kérés URI-je hosszabb, mint amit a kiszolgáló értelmezni tud, ezért a kiszolgáló megtagadja a kérés kiszolgálását. Ez ritka, és általában akkor fordul elő, amikor egy űrlapküldés, amelynek POST-módszert kellett volna használnia, GET-módszerré változik, 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ért URI olvasásához vagy manipulálásához, ami puffer túlcsordulást eredményezhet, ha a GET paraméter meghalad egy bizonyos értéket, 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, és 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 esnek egybe az aktuális erőforráshoz rendelkezésre álló tartományokkal, és a kérés nem definiál If-Tartomány kérés fejlécet, akkor a kiszolgálónak 416 státuszkódot kell visszaküldenie. Ha a Range bájt-tartományokat használ, akkor ez azt jelenti, hogy a kérésben megadott összes adattartomány első bájtja 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 Az Expect kérésfejlécben megadott elvárt tartalom nem teljesíthető a kiszolgáló által, vagy 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 Az aktuális ügyfél IP-címéről a kiszolgálóhoz érkező kapcsolatok 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 proxykiszolgálójának címét). Ebben az esetben egynél több végfelhasználó is részt vehet a kapcsolatszámlálásban.
422 Az aktuális ügyfél IP-címéről a kiszolgálóra irányuló kapcsolatok 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 egynél több végfelhasználó is részt vehet a kapcsolatszámlálásban.
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) 423 Zárolt
424 Az aktuális kérés egy korábbi kérés, például PROPPATCH hibája miatt sikertelen volt. (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ítve, 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 előre nem látható 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ámogatja az aktuális kérés által megkövetelt funkciót. Amikor a kiszolgáló nem ismeri fel a kért módszert, és nem tudja támogatni a kérését semmilyen erőforrásra vonatkozóan.
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 milyen protokollokat támogat a kiszolgáló.
506 Az Átlátszó tartalomtárgyalási protokoll (RFC 2295) által kiterjesztve, hogy a kiszolgáló belső hibás konfigurációját jelezze: a kért Tárgyalási változat erőforrása úgy van konfigurálva, hogy önmagát használja az Átlátszó 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 teljesült. (RFC 2774)
Hozzáférés a nyilvántartásokhoz: