| HTTP állapotkód | Állapotkód jelentése |
|---|
| 100 | A kliensoldalnak folytatnia kell a kérések küldését. Ez a átmeneti válasz arra szolgál, hogy tájékoztassa a kliensoldalt, hogy néhány kérése elérte a kiszolgálót és nem lett elutasítva. A kliensoldalnak folytatnia kell a többi kérés küldését, vagy figyelmen kívül kell hagynia a választ, ha a kérés befejeződött. A kiszolgálónak végül egy végleges választ kell küldenie a kliensoldalnak a kérés befejezése után. |
| 101 | A szervert megértette a kliens kérése, és a kliens oldalt az Ugrade fejlécen keresztül értesíti arról, hogy egy másik protokollt kell használni a kérés befejezéséhez. A válasz utolsó üres sorának elküldése után a szervert az Ugrade fejlécben meghatározott protokollok váltják fel. Csak akkor kell ilyen intézkedéseket tenni, ha a új protokoll váltása előnyösebb. Például az új HTTP verzió váltása előnyösebb egy régi verzióhoz képest, vagy a valós-idő és szinkron protokoll, amely lehetővé teszi az ilyen jellegű funkciókat kihasználó források szállítását. |
| 102 | A WebDAV által bővített állapotkód (RFC 2518) azt jelzi, hogy a feldolgozás folytatódik. |
| 200. | A kérés sikeres volt, és a kívánt válaszfejléceket vagy adatokat a válaszban adták vissza. |
| 201 | A kérés teljesült, és egy új forrás lett létrehozva a kérés követelményei alapján, és az URI-t a Location fejlécvel adták vissza. Ha a szükséges forrás nem hozható létre időben,'202 Accepted' visszaadása célja. |
| 202 | A szervert a kérés elfogadta, de még nem dolgozta fel. Ahogy elutasítható, a kérés végül is lehet, hogy végrehajtott vagy nem végrehajtott. Az aszinkron műveletek esetében nincs ennél kényelmesebb módja ennek, mint hogy ezt az állapotkódot küldjék el. Az 'Accepted' visszaadása célja. 202 állapotkód válasz célja, hogy lehetővé tegye a szervert más folyamatok (például tömeges) kérések fogadására.-naponta egyszer végrehajtott alapvető művelet, amelyet csak egyszer hajtanak végre) anélkül, hogy a kliens oldalt a szerverhez csatlakoztatva kellene tartani a tömeges művelet befejezéséig. A kérés feldolgozásának és visszaadása érdekében adott állapotkód válasz célja, hogy lehetővé tegye a szervert más folyamatok (például tömeges) kérések fogadására. 202 státusz kód, a visszaküldött entitásnak tartalmaznia kell néhány információt, amely jelezzi a folyamat jelenlegi állapotát, valamint egy utalást a folyamat állapotának monitorozására vagy előrejelzésére, hogy a felhasználó meg tudja állapítani, hogy a művelet befejeződött-e. |
| 203 | A szerver sikeresen feldolgozta a kérést, de a visszaküldött entitás fejléc meta információ nem egy érvényes determinisztikus halmaz az eredeti szerveren, hanem egy helyi vagy harmadik-party másolat. A jelenlegi információ lehet egy rész vagy egy teljesítősorozat az eredeti verzióhoz képest. Például a források tartalmazó metaadatok lehetővé teszik, hogy az eredeti szerver ismerje a meta super-t. Ez a státusz kód nem szükséges, és csak akkor megfelelő, ha a válasz visszaadja 200 OK állapot kód nélkül. |
| 204 | A szerver sikeresen feldolgozta a kérést, de nem kell visszaküldenie semmilyen fizikai tartalmat, és szeretné visszaküldeni az újra vagy frissített meta információkat. A válasz egy entitás fejléc formájában érhetők el, amely új vagy frissített meta információkat tartalmaz. Ha ez a fejléc információ létezik, akkor meg kell felelnie a kért változóknak. Ha a kliens oldalon egy böngésző van, akkor a felhasználó böngészője meg kell tartsa a kérést küldő oldalt anélkül, hogy bármilyen változtatást végrehajtana a dokumentum nézetén, még akkor is, ha az új vagy frissített meta információkat az utasításnak megfelelően alkalmazni kellene a felhasználó böngészőjének aktív nézetében. Mivel a 204 válasz nem tartalmazhat semmilyen üzenettestet, mindig a fejléc után az első üres sorral ér véget. |
| 205 | szerver sikeresen feldolgozta a kérést és semmit nem adott vissza. De ellentétben a 204 válasz, amely ezzel a státusz kóddal visszaadja, hogy a kérőt a dokumentum nézetét vissza kell állítania. Ez a válasz elsősorban arra szolgál, hogy azonnal visszaállítsa a űrlapot az utasítás fogadása után, hogy a felhasználó könnyen újabb bevitelt kezdjen. Mint a 204 response, this response is also prohibited from including any message body and ends with the first blank line after the header. |
| 206 | The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Xunlei use this type of response to implement a breakpoint continuation or to break up a large document into multiple download segments to download simultaneously. The request must contain a Range header to indicate the range of content the client side wants, and may include If-válasz, e válasz is megtiltva van, hogy bármilyen üzenettest tartalmazzon, és a fejléc első üres sorával ér véget.-A szerver sikeresen feldolgozta a GET kérés részét. Az FlashGet vagy Xunlei stílusú HTTP letöltő eszközök ezt a típusú választ használják egy megszakításos folytatáshoz vagy egy nagy dokumentum több letöltési szakaszra történő felosztásához egyszerre történő letöltéshez. A kérésnek tartalmaznia kell egy Range fejlécet, hogy megjelölje a kliensoldali kívánt tartalom tartományát, és tartalmazhat If-Range a kérés feltételként. A válasznak tartalmaznia kell a következő fejléc mezőket: Content-szakasz letöltésével tartalmazza a tartalom tartományát, amelyet e válaszban visszatérít; ha több részből álló tartalom van, akkor a/Type multipart-byteranges, minden több részből álló szakasz tartalmaznia kell egy Content-Range mező a tartalom tartományának megjelölésére ebben a szakaszban. Ha a válasz tartalmazza a Content/vagy Content-Location, ha ugyanaz a kérés vissza kellett volna térnie egy 200 válasz. Expires, Cache-Control, és/Length használatával, akkor értéke meg kell egyeznie a visszatérített tartalom tartományban lévő valós byte számával. Dátum ETag és-vagy Vary használatával, ha értéke különbözhet az ugyanahhoz a változóhoz tartozó más válaszok értékétől. Ha e válasz kérése If-Range erős gyűjtő validációja esetén, akkor e válasz nem tartalmazhat más entitás fejléceket; ha e válasz kérése If 2Range gyenge gyűjtő validációja esetén, akkor e válasz nem tartalmazhat más entitás fejléceket; ez elkerüli a gyűjtött entitás tartalma és az aktualizált entitás fejléc információi közötti inkonzisztenciákat. Esetleg, e válasz tartalmazza az összes entitás fejléc mezőt, amelyeket egy-00 válaszban. Ha az ETag vagy Last 206 Modified fejléceket, amelyek nem pontosan egyeznek meg, a kliensoldali gyűjtőnek meg kell tiltania a válaszban visszatérített tartalom kombinálását a-A Range fejléc nem tárolhatja a válasz által visszatérített tartalmat bármilyen előzőleg tárolt tartalommal. Bármely olyan gyűjtő, amely nem támogatja a Range és a Content 206 válasz. |
| 207 | WebDAV által bővített állapotkód (RFC 2518) represents that the body of the subsequent message will be an XML message, and may contain a series of independent response codes depending on the number of previous sub-requests. |
| 300 | ) azt jelenti, hogy a következő üzenet test része egy XML üzenet lesz, és lehet, hogy több független válasz kódot tartalmaz a korábbi alárendelt kérések számától függően.-kérések.-A kért erőforrás több visszajelzési lehetőséget kínál, mindegyiknek megvan a saját specifikus címe és böngésző 2616 Típus. A böngésző automatikusan megteheti a legmegfelelőbb választást a válasz formátumának és a böngésző saját képességei alapján. Természetesen, az RFC által irányított tárgyalási információk. A felhasználó vagy a böngésző kiválaszthat egy előnyben részesített címet az átirányításra. Hacsak ez nem egy HEAD kérés, a válasz tartalmaznia kell egy entitást, amely tartalmazza a forrás attribútumait és címét, amelyek közül a felhasználó vagy a böngésző kiválaszthatja a legmegfelelőbb átirányítási címet. Ez az entitás formátuma a Content által meghatározott formátum. |
| 301 | A kért erőforrás állandóan áthelyezésre került egy új helyre, és a jövőbeli hivatkozások a forrásra ezt az egyetlen URI-t kell, hogy használják, amelyet a válasz visszaad. Ha lehetséges, a kliens oldal link szerkesztési képességgel rendelkező része automatikusan megváltoztathatja a kért címet a szerver által visszaadott címmel. Hacsak másképp nem van meghatározva, ez a válasz is tárolható. Az új állandó URI-t vissza kell adni a válasz Location mezőjében. Hacsak ez nem egy HEAD kérés, a válasz entitása tartalmaznia kell egy hivatkozást az új URI-ra és egy rövid leírást. Ha nem GET vagy HEAD kérés, a böngésző nem automatikusan irányíthat át, hacsak a felhasználó nem erősíti meg, mivel a kérés feltételei megváltozhatnak ennek következtében. Megjegyzés: Néhány böngésző esetében az HTTP specifikáció nem határozza meg, hogyan kell ilyen automatikus kiválasztást végrehajtani. Ha a szerver már rendelkezik egy előnyben részesített visszajelzési kiválasztással, a visszajelzés URI-ját a Location mezőben kell meghatározni; a böngészők használhatják ezt az Location értéket az automatikus átirányítás címeként. Továbbá, hacsak másképp nem van meghatározva, a válasz is tárolható./1.0 protokoll, amikor POST kérést küldenek és választ kapnak 301 válaszban van meghatározva, a következő átirányítási kérés GET lesz. |
| 302 | A kérdezett forrás most ideiglenesen válaszol a kérésre egy másik URI-ról. Mivel ilyen átirányítások ideiglenesek, a kliens oldalnak folytatnia kell a jövőbeli kérések küldését az eredeti címre. Ez a válasz csak akkor tárolható, ha a Cache-Vezérlés vagy Expiration. Az új ideiglenes URI-t vissza kell adni a válasz Location mezőjében. Hacsak ez nem egy HEAD kérés, a válasz entitása tartalmaznia kell egy hivatkozást az új URI-ra és egy rövid leírást. Ha ez nem egy GET vagy HEAD kérés, a böngésző automatikus átirányítást tilt, hacsak a felhasználó nem erősíti meg, mivel a kérés feltételei megváltozhatnak ennek eredményeként. Megjegyzés: Bár az RFC 1945 és RFC 2068 szabványok nem teszik lehetővé a kliens oldal számára, hogy megváltoztassa a kérés módszerét átirányítás közben, sok meglévő böngésző 302 válasz 303 válasz és használja a GET-et a Location mezőben megadott URI hozzáféréséhez, figyelmen kívül hagyva az eredeti kérés módszerét. Állapotkódok 303 és 307 hozzákadásaival tisztázni, hogy a kiszolgáló mire vár a kliens oldaltól. |
| 303 | a jelen kérés válasza megtalálható egy másik URI-n, és a kliens oldalnak GET hozzáférést kell biztosítania ehhez a forráshoz. Ez a módszer főként a szkript-aktiválva a POST kérés kimenetét, hogy átirányítsa egy új forráshoz. Ez az új URI nem helyettesítő hivatkozás az eredeti forráshoz. Továbbá, 303 válaszokat nem szabad gyorsítótárazni. Természetesen egy második kérés (átirányítás) gyorsítható. Az új URI-t vissza kell adni a válasz Location mezőjében. Hacsak ez nem egy HEAD kérés, a válasz entitása tartalmaznia kell egy hiperlinket az új URI-hoz és egy rövid leírást. Megjegyzés: sok böngésző az HTTP előtti években/1.1 nem értik 303 státuszt. Ha szükséges, hogy figyelembe vegye ezekkel a böngészőkkel való interakciót, a 302 státusz kód elegendő, mert a legtöbb böngésző jól kezeli 302 válaszokat pontosan úgy kell kezelni, ahogy az alábbi specifikációkban a kliens oldal számára meg van határozva 303 válaszokat. |
| 304 | Ha a kliens oldal feltételes GET kérést küld, és a kérés engedélyezve lett, és a dokumentum tartalma nem változott (az utolsó látogatás óta vagy a kérés feltételei szerint), akkor a szervernek ezt a státusz kódot kell visszaadnia. 304 válaszok nem tartalmazhatnak üzenettesteket, így mindig véget kell vetniük a fejléc első üres sorával. A válasznak tartalmaznia kell a következő fejlécinformációkat: Date, hacsak ez a szerver nincs órával.
Ha a szerver, amely nincs órával, is betartja ezek szabályait, akkor a proxy szerver és a kliens oldal saját maga hozzáadhatja a Date mezőt a kapott válaszfejléchez (ahogy az RFC-ben meg van határozva) 2068), és a gyorsítótárhely mechanizmus jól fog működni. ETag és/vagy Content-Location, ha ugyanaz a kérés vissza kellett volna térnie egy 200 válasz. Expires, Cache-Control, és/vagy Vary, ha értéke eltérhet a más válaszokhoz tartozó értéktől, amelyek ugyanahhoz a változóhoz kapcsolódnak.
Ha a válasz kérés erős gyorsítótárhely-ellenőrzést használ, akkor a válasz nem tartalmazhat más entitásfejléceket; ellenkező esetben (például egy feltételes GET kérés gyenge gyorsítótárhely-ellenőrzést használ), a válasz nem tartalmazhat más entitásfejléceket; ez elkerüli az egyesített entitás tartalom és az aktualizált entitásfejléc információk közötti inkonzisztenciát. Ha egy 304 válasz azt jelzi, hogy egy entitás jelenleg nem tárolt, a tárolórendszernek figyelmen kívül kell hagynia a választ, és korlátlan számú ismételt kérést kell küldenie.
Ha egy 304 válasz megkapása után kell frissíteni a tárolt bejegyzést, a tárolórendszernek az egész bejegyzést kell frissítenie, hogy tükrözze az összes mező értékeit, amelyeket a válaszban frissítettek. |
| 305 | A kért erőforrás csak a megadott proxyon keresztül érhető el. A megadott proxy URI-információi a Location mezőben találhatók. A címzettnek ismételten külön kérést kell küldenie, hogy elérje az ezen keresztül a megfelelő erőforrást. Csak az eredeti kiszolgáló állhat fel egy 305 válaszban. Megjegyzés: Nincs kifejezett 305 válaszban az RFC-ben 2068 egyetlen kérés átirányítására, és csak az eredeti kiszolgáló állhat fel. Ezek korlátozások figyelmen kívül hagyása súlyos biztonsági következményekhez vezethet. |
| 306 | A specifikáció legújabb verziójában a 306 á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 ilyen átirányítások ideiglenesek, a kliens oldalnak továbbra is küldenie kell a jövőbeli kéréseket az eredeti címre. Ez a válasz csak akkor tárolható, ha a Cache-Vezérlés vagy Lejárat. Az új ideiglenes URI-t vissza kell adni a válasz Location mezőjében. Hacsak ez nem HEAD kérés, a válaszadó entitás tartalmaznia kell egy hiperlinket, amely az új URI-ra mutat, és egy rövid leírást. Mivel néhány böngésző nem ismeri fel a 307 válaszhoz, az alábbi információkat kell hozzáadni, hogy a felhasználó megértse és hozzáférhessen az új URI-hoz.
Ha ez nem GET vagy HEAD kérés, akkor a böngésző nem engedélyezi az automatikus átirányítást, hacsak a felhasználó nem erősíti meg, mivel a kérés feltételei megváltozhatnak ennek eredményeként. |
| 400 | 1. A szemintrum helytelen, és a jelenlegi kérés nem értelmezhető a kiszolgáló számára. Hacsak nem módosítják, a kliensoldal nem szabad ismételten benyújtani a kérést. 2. A kérés paraméterei helytelenek. |
| 401 | A jelenlegi kérés felhasználói autentikációt igényel. A válasznak tartalmaznia kell egy WWW-Authenticate fejlécet a kérdezett erőforrás számára, hogy kérje a felhasználó információit. A kliensoldal újra megteheti a kérést a megfelelő Authorization fejléc információkkal. Ha a jelenlegi kérés már tartalmazza az Authorization tanúsítványokat, akkor a 401 válasz azt jelenti, hogy a kiszolgáló elutasította azokat a tanúsítványokat. Ha a 401 válasz tartalmazza ugyanazt az autentikációs lekérdezést, mint az előző válasz, és a böngésző legalább egyszer próbálkozott autentikációval, akkor a böngészőnek meg kell mutatnia a válaszban található entitás információkat, mivel ez az entitás információ tartalmazhat releváns diagnózis információkat. Lásd az RFC 2617. |
| 402 | Ez a status code a lehetséges jövőbeli igényekre fenntartott. |
| 403 | A kiszolgáló megértette a kérést, de elutasította annak végrehajtását. Ellentétben egy 401 válasz, az autentikáció nem segíti, és a kérést nem szabad ismételni. Ha ez nem HEAD kérés, és a kiszolgáló szeretné magyarázni, miért nem hajtható végre a kérés, akkor az elutasítás oka leírása meg kell, hogy jelenjen meg az entitásban. Természetesen a kiszolgáló is visszaadhat egy 404 válasz, ha nem akarja, hogy a kliensoldal bármilyen információt kapjon. |
| 404 | A kérés meghiúsult, és a kívánt erőforrás nem található a kiszolgálón. Nincs információ a felhasználó számára, hogy a helyzet ideiglenes vagy hosszantartó. Ha a kiszolgáló tudja a helyzetet, a 410 A status code-ot kell használni az régi erőforrás értesítésére, hogy hosszantartóan nem érhető el valamilyen belső konfigurációs mechanizmus miatt, és nincs cím, amelyre áthelyezkedhet. A 404 A status code széles körben használatos, amikor a kiszolgáló nem akarja elárulni, miért lett elutasítva a kérés, vagy nincs más megfelelő válasz elérhető. |
| 405 | A kérés sorban megadott metódusa nem használható a megfelelő erőforrás kérésekor. A válasznak egy Allow fejlécet kell visszaadnia, amely egy listát tartalmaz arról, hogy mely kérésmódokat fogadhat el a jelenlegi erőforrás. Mivel a PUT és DELETE módszerek írják az erőforrásokat a szerverre, a legtöbb web szerver nem támogatja vagy alapértelmezés szerint nem engedélyezi az említett kérésmódot, és visszaad egy 405 hibát ad vissza ilyen kérések esetén. |
| 406 | A kért erőforrás tartalmi jellemzői nem felelnek meg a kérés fejlécben feltett feltételeknek, így nem tud válasz entitást létrehozni. Hacsak ez nem egy HEAD kérés, a válasznak egy entitást kell visszaadnia, amely lehetővé teszi a felhasználó vagy a böngésző számára, hogy kiválassza a legmegfelelőbb entitás jellemzőit és címlistát. Az entitás formátuma a Content-Típus fejléchez. A böngésző a legjobb választást tehet a formátum és saját képességei alapján. Azonban a specifikáció nem definiál semmilyen kritériumot az ilyen automatikus kiválasztásokhoz. |
| 407 | Hasonló a 401 választ, kivéve, hogy a kliens oldalnak azonosítania kell a proxy szerveren. A proxy szervernek egy Proxy-Hitelesítsd az azonosításhoz. A kliens oldal visszaadhat egy Proxy-Hitelesítési fejléc az azonosításhoz. Lásd az RFC-t 2617. |
| 408 | A kérés időtúllépésre került. A kliens oldal nem fejezte be a kérés küldését azzal az idővel, amíg a szerver várta. A kliens oldal bármikor újra elküldheti a kérést anélkül, hogy bármilyen változtatást volna szükség. |
| 409 | A kérés nem tud teljesülni, mivel van konfliktus a kért erőforrás jelenlegi állásával. Ez a kód csak akkor használható, ha feltételezzük, hogy a felhasználó képes megoldani a konfliktust és új kérést fog benyújtani. A válasznak elég információt kell tartalmaznia a felhasználó számára, hogy felfedezze a konfliktus forrását. A konfliktusok általában a PUT kérések feldolgozásakor fordulnak elő. Például egy verzióban-ellenőrzött környezetben, ha a PUT-hoz csatolt verzióinformációk-beküldött módosítási kérést egy adott erőforráshoz konfliktusos egy előző (harmadik)-oldal) kérés esetén, a szervernek vissza kell adnia egy 409 hiba értesítése, hogy a kérés nem hajtható végre.
Ebben a pillanatban a válasz entitása valószínűleg tartalmazza a két konfliktusos verzió közötti különbségek összehasonlítását, hogy a felhasználó újra el tudja küldeni a összeolvasztott verziót. |
| 410 | A kérdezett erőforrás már nem érhető el a szerveren, és nincs ismert továbbítási cím. Ez az állapot állandónak kell tekinteni. Ha lehetséges, a link szerkesztési képességgel rendelkező kliens oldal eltávolítsa ezt az címet a felhasználó hozzájárulása nélkül. Ha a szerver nem ismeri vagy nem tudja megállapítani, hogy ez az állapot állandó, akkor egy 404 állapotkódot kell használni. Hacsak másként nem van meghatározva, ez a válasz gyűjthető. Az 410 válasz elsősorban a webmester webhelyének karbantartásában segíti, hogy értesítse a felhasználót, hogy az erőforrás már nem érhető el, és hogy a szerver tulajdonosa azt szeretné, hogy minden távoli kapcsolatot töröljenek ezen erőforráshoz.
Ez a típusú esemény gyakori az idő-korlátozott, érték-hozzáadott szolgáltatások. Hasonlóan, a 410 válasz használata a kliens oldal értesítésére, hogy az eredetileg egyéni tulajdonban lévő erőforrások már nem érhetők el a jelen szerveroldalon. Természetesen a szerver tulajdonosának teljesen a döntése, hogy mindegyik állandóan elérhetetlen erőforrást milyen jelzővel jelöljön meg 410 Elérhetetlen ', és mennyi ideig kell megőrizni ezt a jelzőt. |
| 411 | A szerver elutasítja a kérést, ha nem definiálja a tartalmat-Hosszúságfejléc. Miután hozzáadtak egy érvényes tartalmat-Hosszúságfejléc, amely jelzi a kéréskönyvtár hosszát, a kliens oldal ismételten elérheti a kérést. |
| 412 | A kiszolgáló nem felelt meg egy vagy több előfeltételnek, amikor ellenőrizte, hogy ezek a kérés fejléc mezőjében lettek-e megadva. Ez az állapotkód lehetővé teszi a kliens oldalon, hogy előfeltételeket állítson be a kért metaadatokban (kérés fejléc mező adatok) források lekérdezésekor, így megakadályozva, hogy a kérés módszere alkalmazásra kerüljön más forrásokra, mint amit szeretne. |
| 413 | A kiszolgáló elutasítja az aktuális kérés kezelését, mert a kérés több entitás adatot küld, mint amennyit a kiszolgáló szívesen vagy képes kezelni. Ebben az esetben a kiszolgáló lezárhatja a kapcsolatot, hogy megakadályozza a kliens oldalt abban, hogy tovább küldje a kérését. Ha ez a helyzet ideiglenes, a kiszolgálónak újra próbálkozást kellene visszaadnia.-válaszfejléc után tájékoztatja a kliens oldalt arról, hogy mennyi ideig próbálhat újra. |
| 414 | A kért URI hosszabb, mint amit a kiszolgáló értelmezni tud, így a kiszolgáló elutasítja a kérés kezelését. Ez ritka, és gyakori esetek közé tartozik: Egy űrlap beküldése, amelynek POST módszert kellett volna használnia, helyett GET módszert használ, ami miatt a lekérdezési karakterlánc (Query String) túl hosszú lesz. Redirect URI "fekete lyukak", mint például minden redirect az új URI részeként használja az régi URI-t, ami miatt a URI túl hosszú lesz több redirect után. A kliens a kiszolgálóval való támadásra próbálkozik biztonsági hibákkal, amelyek néhány kiszolgálón léteznek.
Ez a típusú kiszolgáló egy fix-hosszúságú buffer olvasására vagy a kért URI manipulálására. Ha a GET paraméterek meghaladják egy bizonyos értéket, buffer overflow történhet, amely véletlenszerű kód futtatásához vezethet [1]. Az ilyen gyengeségekkel nem rendelkező kiszolgálók vissza kellene adják egy 414 állapotkódot. |
| 415 | Az aktuális kérés módszere és a kért forrás esetében a kérésben küldött entitás nem egy a kiszolgáló által támogatott formátumban, így a kérés elutasítva lett. |
| 416 | Ha a kérés tartalmaz egy Range fejlécet, és a Range-ben meghatározott adatmezők nem egyeznek meg az aktuális forrás elérhető tartományával, és az If-A kérésben nincs meghatározva a Range fejléc, a kiszolgálónak vissza kellene adnia egy 416 állapotkód. Ha a Range byte tartományt használ, akkor ez a helyzet azt jelenti, hogy a kérés által megadott összes adat tartomány első bájt pozíciója meghaladja az aktuális erőforrás hosszát. A kiszolgálónak is bele kellene foglalnia a Content-Range entitás fejlécével együtt a 416 állapotkódot jelzi a jelenlegi erőforrás hosszát. Ez a válasz nem használhat több részből álló tartalmat is./byteranges mint tartalom-Típus. |
| 417 | A kérés fejlécében megadott várt tartalom a kiszolgáló számára nem teljesíthető, vagy a kiszolgáló egy proxy kiszolgáló, amelynek egyértelmű bizonyítéka van arra, hogy a várt tartalom nem teljesíthető a jelenlegi útvonal következő lépésén. |
| 421 | A jelenlegi kliens oldali IP-címről a kiszolgálóhoz érkező csatlakozások száma meghaladja a kiszolgáló által engedélyezett maximális számot. Általában az IP-cím itt a kliens oldal címét jelenti a kiszolgáló szempontjából (például a felhasználó gateway vagy proxy kiszolgáló címe). Ebben az esetben a csatlakozási szám több mint egy végfelhasználót is érinthet. |
| 422 | A jelenlegi kliens oldali IP-címről a kiszolgálóhoz érkező csatlakozások száma meghaladja a kiszolgáló által engedélyezett maximális számot. Általában az IP-cím itt a kliens oldal címét jelenti a kiszolgáló szempontjából (például a felhasználó gateway vagy proxy kiszolgáló címe). Ebben az esetben a csatlakozási szám több mint egy végfelhasználót is érinthet. |
| 422 | A kérés helyesen formázott, de sematikus hiba miatt nem lehetett válaszolni. (RFC 4918 WebDAV) 423 Zárolt A jelenlegi erőforrás zárolt. (RFC 4918 WebDAV) |
| 424 | A jelenlegi kérés hibát követően sikertelen volt, például PROPPATCH. (RFC 4918 WebDAV) |
| 425 | A WebDav Advanced Collections tervezetben definiált, de nem a WebDAV Soros Set Protokollban (RFC 3658). |
| 426 | A kliens oldalnak átváltania kell a TLS-re/1.0. (RFC 2817) |
| 449 | A Microsoft által kibővített kérések újra meg kell próbálják végrehajtani a megfelelő művelet elvégzése után. |
| 500 | A kiszolgáló váratlan helyzetet tapasztalt, amely megakadályozta a kérés befejezését. Általában ez a probléma akkor fordul elő, amikor a kiszolgáló kód hibát ejt. |
| 501 | A kiszolgáló nem támogatja a jelenlegi kérés által igényelt funkciót. Amikor a kiszolgáló nem ismeri fel a kért módszert és nem tudja támogatni bármely erőforrás kérését. |
| 502 | Amikor egy gateway vagy proxyként működő kiszolgáló kísérli meg kérés végrehajtását, érvénytelen választ kap az alsóbb szintű kiszolgálótól. |
| 503 | A szerver jelenleg nem képes kéréseket feldolgozni ideiglenes szerver karbantartás vagy túlterhelés miatt. Ez a feltétel ideiglenes és néhány idő múlva helyreáll. Ha a késleltetési idő előre jelezhető, a válaszban meg kell tartalmaznia a Retry-fejléc, hogy jelezze a késleltetési időt. Ha a Retry-Információ hiányában a kliensoldalnak úgy kell kezelnie, mintha az lenne egy 500 válasz. Megjegyzés: A 503 állapotkód nem jelenti azt, hogy a szervernek használnia kell azt az áramlási terhelés esetén. Néhány szerver egyszerűen csak meg akarja tiltani a kliens kapcsolatát. |
| 504 | Amikor egy gateway vagy proxy szolgáltatású szerver megpróbál kérést végrehajtani, nem kap időben választ az előírt felfelé vezető szervertől (például HTTP, FTP, LDAP) vagy másodlagos szervertől (például DNS). Megjegyzés: Néhány proxy szerver visszatérési 400 vagy 500 hiba, amikor a DNS lekérdezés lejáratodik |
| 505 | A szerver nem támogatja, vagy nem támogatja a kérésben használt HTTP verziót. Ez azt jelenti, hogy a szerver nem használhatja ugyanazt a verziót, mint a kliensoldal. A válaszban egy entitásnak le kell írnia, miért nem támogatja a verziót, és mely protokollokat támogat a szerver. |
| 506 | Bővítve az Átlátszó Tartalmi Tárgyalási Protokollal (RFC 2295), ez a szerver belső konfigurációs hibát jelent: a kért tárgyalási változó erőforrás átlátszó tartalmi tárgyalásban önmagát használja, és így nem megfelelő fókusz a tárgyalási folyamatban. |
| 507 | A szerver nem tudja tárolni a kérést befejezéséhez szükséges tartalmat. Ez a feltétel ideiglenesnek tekintendő. WebDAV (RFC 4918) |
| 509 | A szerver elérte a sávszélesség határát. Ez nem hivatalos állapotkód, de széles körben használják. |
| 510 | Az erőforrások megszerzéséhez szükséges politikák nem teljesülnek. (RFC 2774) |
