HTTP állapotkódok listája

A HTTP állapotkód a HTTP kérésekre adott szerverválasz első sorának része .  Ez egy háromjegyű decimális szám. Az első számjegy az állapotosztályt jelöli . A válaszkódot általában egy szóközzel elválasztott magyarázó mondat követi angolul, amely elmagyarázza a személynek, hogy mi a válasz oka. Példák:

• 201 Létrehozva .
• 401 Jogosulatlan .
• 507 Elégtelen tárhely .

Az ügyfél a válaszkódból értesül a kérésének eredményéről, és meghatározza, hogy milyen lépéseket tegyen ezután. Az állapotkódok készlete szabványos, és leírásuk a vonatkozó RFC dokumentumokban található . Az új kódok bevezetése csak az IETF -fel folytatott konzultációt követően történhet . Azonban két ismert kód van használatban, amelyeket az RFC nem említ: 449 Retry With. A Microsoft Developer Network WebDAV specifikációjában a Microsoft által bevezetett és a cPanel -ben bevezetett „Reply With” [1] magyarázó kifejezés is szerepel . 509 Bandwidth Limit Exceeded

Előfordulhat, hogy a kliens nem ismeri az összes állapotkódot, de a kódosztálynak megfelelően válaszolnia kell. Jelenleg az állapotkódok öt osztálya létezik.

Az Internet Information Services webszervere naplófájljaiban a szabványos állapotkódokon kívül alkódokat is használ, a fő után egy ponttal írva azokat. Ugyanakkor ez az alkód nem kerül a szerver válaszaiba - a szerver rendszergazdájának szüksége van rá, hogy pontosabban meghatározhassa a problémák forrását.

Véleménylista

Az alábbiakban az ebben a cikkben leírt válaszkódok áttekintő listája található:

• 1xx: Tájékoztató
  • 100 Folytatás [ 2] [3] ;
  • 101 Switching Protocols [ 2] [3] ;
  • 102 Feldolgozás ("feldolgozás");
  • 103 Early Hints ("korai metainformáció");
• 2xx: Siker
  • 200 OK ("jó") [2] [3] ;
  • 201 Létrehozva [ 2] [3] [4] ;
  • 202 Elfogadva [ 2] [3] ;
  • 203 Nem hiteles információ [ 2] [3] ;
  • 204 Nincs tartalom [ 2] [3] ;
  • 205 Tartalom visszaállítása [ 2] [3] ;
  • 206 Résztartalom [ 2] [3] ;
  • 207 Multi-Status ("multi-status") [5] ;
  • 208 Már jelentették [ 6] ;
  • 226 IM Használt .
• 3xx: Átirányítás :
  • 300 többszörös választás [ 2] [7] ;
  • 301 Véglegesen elköltözött [2] [7] ;
  • 302 Ideiglenesen elköltözött [ 2] [7] , 302 Megtalálva [ 7] ;;
  • 303 Lásd: Egyéb („lásd egyéb”) [2] [7] ;
  • 304 Nem módosítva [ 2] [7] ;
  • 305 Proxy használata [ 2] [7] ;
  • 306  - fenntartva (a kódot csak a korai specifikációkban használták) [7] ;
  • 307 Ideiglenes átirányítás ("ideiglenes átirányítás") [7] ;
  • 308 Állandó átirányítás [ 8] .
• 4xx: Ügyfélhiba :
  • 400 Bad Request ("helytelen, helytelen kérés") [2] [3] [4] ;
  • 401 Jogosulatlan ("nem jogosult (nem mutatkozott be)") [2] [3] ;
  • 402 Befizetés szükséges [ 2] [3] ;
  • 403 Tilos ("tilos (nem engedélyezett)") [2] [3] ;
  • 404 Nem található [ 2] [3] ;
  • 405 Method Not Allowed [2] [3] ;
  • 406 Nem elfogadható [ 2] [3] ;
  • 407 Proxy hitelesítés szükséges [ 2] [3] ;
  • 408 Kérelem időtúllépése [ 2] [3] ;
  • 409 Konfliktus ("konfliktus") [2] [3] [4] ;
  • 410 Eltűnt [ 2] [3] ;
  • 411 Szükséges hossz [ 2] [3] ;
  • 412 Előfeltétel sikertelen [ 2] [3] [9] ;
  • 413 Túl nagy rakomány [2] [3] ;
  • 414 URI túl hosszú (" URI túl hosszú") [2] [3] ;
  • 415 Nem támogatott médiatípus [ 2] [3] ;
  • 416 Tartomány nem kielégítő [3] ;
  • 417 A várakozás meghiúsult [ 3] ;
  • 418 Teáskanna vagyok ("Teáskanna vagyok");
  • 419 Authentication Timeout (nem az RFC 2616-ban) ("általában a CSRF ellenőrzése sikertelen");
  • 421 Rosszul irányított kérés [10] ;
  • 422 Feldolgozhatatlan entitás
  • 423 Lezárva ("zárva");
  • 424 Sikertelen függőség
  • 425 Túl korán ("túl korán");
  • 426 Frissítés szükséges
  • 428 Előfeltétel szükséges [ 11] ;
  • 429 Túl sok kérés [ 11] ;
  • 431 Kérelem fejléc mezői túl nagyok [ 11] ;
  • 449 Újra az [ 1] gombbal ;
  • 451 Jogi okokból nem elérhető [ 12] .
  • 499 Client Closed Request (az ügyfél lezárta a kapcsolatot);
• 5xx: Szerverhiba :
  • 500 Belső szerverhiba [ 2] [3] ;
  • 501 Nincs végrehajtva [ 2] [3] ;
  • 502 Bad Gateway [ 2] [3] ;
  • 503 A szolgáltatás nem elérhető [ 2] [3] ;
  • 504 Gateway Timeout [ 2] [3] ;
  • 505 HTTP-verzió nem támogatott [ 2] [3] ;
  • 506 Változat is tárgyal [ 13] ;
  • 507 Insufficient Storage ("tárhely túlcsordulás");
  • 508 hurok észlelve [ 14] ;
  • 509 Sávszélesség-korlát túllépve („csatorna sávszélessége kimerült”);
  • 510 Nem kiterjesztett ("nem kiterjesztett");
  • 511-es hálózati hitelesítés szükséges [ 11] ;
  • 520 Ismeretlen hiba ("ismeretlen hiba") [15] ;
  • 521 A webszerver nem működik [ 15] ;
  • 522 Connection Timed Out ("a kapcsolat nem válaszol") [15] ;
  • 523 Az eredet elérhetetlen [ 15] ;
  • 524 Időtúllépés történt [ 15] ;
  • 525 SSL kézfogás sikertelen [ 15] ;
  • 526 Érvénytelen SSL-tanúsítvány [ 15] .

A kódok leírása

Tájékoztató

Ez az osztály olyan kódokat tartalmaz, amelyek az átviteli folyamatról tájékoztatnak. Amikor az 1.0-s protokollverzióval dolgozik, az ilyen kódokat tartalmazó üzeneteket figyelmen kívül kell hagyni. Az 1.1-es verzióban a kliensnek fel kell készülnie arra, hogy normál válaszként elfogadja ezt az üzenetosztályt, de a szervernek nem kell küldenie semmit. Maguk a szervertől érkező üzenetek csak a válasz kezdősorát és szükség esetén néhány válaszspecifikus fejlécmezőt tartalmaznak. A proxyszervereknek az ilyen üzeneteket tovább kell küldeniük a szerverről a kliensnek.

• 100 Folytatás - A szerver elégedett a kéréssel kapcsolatos kezdeti információkkal, a kliens folytathatja a fejlécek küldését. Bevezetve a HTTP/1.1-ben.
• 101 Switching Protocols - A szerver teljesíti a kliens kérését és a fejlécben megadott jelzés szerint protokollt vált Upgrade. A szerver válaszfejlécet küld, amely Upgradejelzi, hogy melyik protokollra váltott. Bevezetve a HTTP/1.1-ben.
• 102 Feldolgozás – A kérelmet elfogadták, de a feldolgozása sokáig tart. A szerver arra használja, hogy megakadályozza, hogy a kliens időkorlát miatt megszakítsa a kapcsolatot. A kliensnek, ha ilyen választ kap, vissza kell állítania az időzítőt, és normál módban várnia kell a következő parancsra. Megjelent a WebDAV -ban .
• 103 Korai tippek – A fejlécek egy részének korai visszaadására szolgál, amikor a teljes válaszfejléc nem alakítható ki gyorsan.

Siker

Ennek az osztálynak az üzenetei tájékoztatnak az ügyfélkérelmek sikeres elfogadásának és feldolgozásának eseteiről. Az állapottól függően a szerver fejléceket és üzenettörzset is küldhet.

• 200 OK – sikeres kérés. Ha bármilyen adatot kért az ügyfél, az az üzenet fejlécében és/vagy törzsében szerepel. Bevezetve a HTTP/1.0-ban.
• 201 Létrehozva – Egy sikeres kérés eredményeként új erőforrás jött létre. A szerver megadhatja a létrehozott erőforrás címeit (több is lehet) a válasz törzsében, a preferált cím feltüntetésével Location. A szervernek javasolt a választörzsben feltüntetni a létrehozott erőforrás jellemzőit és címét, a választörzs formátumát a fejléc határozza meg Content-Type. Egy kérés feldolgozása során egy új erőforrást kell létrehozni, mielőtt a választ elküldi az ügyfélnek, ellenkező esetben kóddal rendelkező választ 202. Bevezetve a HTTP/1.0-ban.
• 202 Elfogadva – A kérelmet elfogadták feldolgozásra, de nem fejezték be. A kliensnek nem kell megvárnia az üzenet végső továbbítását, hiszen nagyon hosszú folyamat indulhat el. Bevezetve a HTTP/1.0-ban.
• 203 Nem hiteles információ - hasonló a -hoz 200, de ebben az esetben a továbbított információ nem az elsődleges forrásból származik (mentés, másik szerver stb.), ezért előfordulhat, hogy nem naprakész. Bevezetve a HTTP/1.1-ben.
• 204 Nincs tartalom – A szerver sikeresen feldolgozta a kérést, de csak fejléceket küldtek a válaszban üzenettörzs nélkül. Az ügyfélnek nem kell frissítenie a dokumentum tartalmát, de a kapott metaadatokat alkalmazhatja rá . Bevezetve a HTTP/1.0-ban.
• 205 Tartalom visszaállítása - A szerver kötelezi a klienst a felhasználó által bevitt adatok visszaállítására. A szerver nem továbbítja az üzenet törzsét, és a dokumentumot nem kell frissíteni. Bevezetve a HTTP/1.1-ben.
• 206 Részleges tartalom – A szerver sikeresen teljesített egy részleges GET kérést , és az üzenetnek csak egy részét adta vissza. A fejlécben a Content-Rangeszerver megadja a tartalom bájttartományát . Amikor ilyen válaszokkal dolgozik, különös figyelmet kell fordítani a gyorsítótárazásra. Bevezetve a HTTP/1.1-ben. ( tovább… )
• 207 Multi-Status - a szerver egyszerre több független művelet eredményét továbbítja. Magában az üzenettörzsben vannak elhelyezve XML -dokumentumként egy multistatus. Ebben az objektumban nem ajánlott a sorozatból származó állapotokat elhelyezni 1xxaz értelmetlenség és a redundancia miatt. Megjelent a WebDAV -ban .
• 208 Már jelentett – A DAV-összerendelési tagok már szerepelnek a válasz előző részében (többállapotú), és nem szerepelnek újra.
• 226 IM Used - a fejléc A-IMsikeresen érkezett a klienstől, és a szerver visszaküldi a tartalmat, figyelembe véve a megadott paramétereket. Az RFC 3229 -ben bevezetve a HTTP protokoll kiegészítéseként támogatja a delta kódolást .

Átirányítás

Az ebben az osztályban lévő kódok azt mondják az ügyfélnek, hogy a művelet sikerességéhez egy másik kérést kell benyújtani, általában egy másik URI -n . Ebből az osztályból öt kód 301, 302, 303és 305közvetlenül 307utal az átirányításokra. Azt a címet, amelyre a kliensnek kérést kell benyújtania, a szerver jelzi a Location. Ez lehetővé teszi a töredékek használatát a cél URI-ban.

A legújabb szabványok szerint a kliens csak a felhasználó megkérdezése nélkül tud átirányítani, ha a GETvagy metódussal kéri-e a második erőforrást HEAD[7] . A korábbi specifikációk szerint az oda-vissza utak elkerülése érdekében a felhasználót az 5. egymást követő átirányítás után kell megkérdezni [16] . Minden átirányításnál, ha a kérés metódusa nem volt HEAD, akkor a válasz törzsébe egy rövid hiperszöveges üzenetet kell beilleszteni a cél címével, hogy hiba esetén a felhasználó maga navigálhasson.

A HTTP fejlesztők megjegyzik, hogy sok kliens kódokkal történő átirányításkor 301hibásan 302alkalmazza a metódust GETa második erőforrásra, annak ellenére, hogy az első kérés más metódussal (leggyakrabban PUT) érkezett [17] . A félreértések elkerülése érdekében a HTTP/1.1 bevezette a és a és kódokat 303a 307helyett 302. Csak akkor kell módosítania a módszert, ha a szerver válaszolt 303. Más esetekben a következő kérés az eredeti módszerrel történik.

Az ügyfelek viselkedését a különböző átirányításoknál a táblázat írja le:

Válasz állapota	gyorsítótárazás	Ha a módszer nem GET vagy HEAD
301 Moved Permanently	Megteheti, mint általában.	Kérjen megerősítést a felhasználótól, és kérjen másik erőforrást az eredeti módszerrel.
307 Temporary Redirect	Csak akkor lehetséges, ha egy cím Cache-Controlvagy Expires.
302 Found(HTTP/1.1) 302 Moved Temporarily(HTTP/1.0)
303 See Other	Ez tiltott.	Menjen automatikusan, de a GET.

• 300 Több választási lehetőség – A megadott URI-n több lehetőség is rendelkezésre áll az erőforrások MIME -típus , nyelv vagy egyéb jellemzők szerint történő biztosítására. A szerver az üzenettel együtt elküldi az alternatívák listáját, lehetővé téve, hogy a kliens vagy a felhasználó automatikusan döntsön. Bevezetve a HTTP/1.0-ban.
• 301 Véglegesen áthelyezve  – A kért dokumentum véglegesen át lett helyezve a Locationfejlécben megadott új URI-ra. Egyes kliensek helytelenül viselkednek a kód feldolgozása során. Bevezetve a HTTP/1.0-ban.
• 302 Megtalált, 302 Ideiglenes áthelyezés – A kért dokumentum átmenetileg elérhető a fejlécben megadott másik URI-n Location. Ez a kód felhasználható például a szerver által vezérelt tartalomegyeztetésben . Néhány[ mi? ] ügyfelek helytelenül viselkednek a kód feldolgozása során. Bevezetve a HTTP/1.0-ban.
• 303 Lásd Egyéb - A kért URI-n lévő dokumentumot a Locationfejléc mezőjében lévő címen kell lekérni a metódus használatával GET, még akkor is, ha az elsőt más módszerrel kérték. Ezt a kódot a kóddal együtt vezették be, 307hogy elkerüljék a félreértéseket, így a szerver biztos lehet benne, hogy a következő erőforrást a GET. Például egy weboldal szövegbeviteli mezővel rendelkezik a gyors navigációhoz és kereséshez. Az adatok megadása után a böngésző kérést küld a metódussal POST, a beírt szöveget az üzenet törzsébe beépítve. Ha talál egy dokumentumot a megadott névvel, a szerver a kóddal válaszol, és a fejlécben 303jelzi Locationállandó címét. Ekkor a böngésző garantáltan GETlekéri a tartalom beszerzésének módszerével. Ellenkező esetben a szerver egyszerűen visszaküldi a keresési eredményoldalt az ügyfélnek. Bevezetve a HTTP/1.1-ben.
• 304 Nem módosítva – A szerver akkor adja vissza ezt a kódot, ha az ügyfél a vagy GETfejléc használatával kérte a dokumentumot, és a dokumentum nem változott a megadott idő óta. Ebben az esetben a szerverüzenet nem tartalmazhat törzset. Bevezetve a HTTP/1.0-ban.If-Modified-SinceIf-None-Match
• 305 Proxy használata – A kért erőforrás kérését egy olyan proxyszerveren keresztül kell megtenni, amelynek URI-je a Locationfejlécben van megadva. Ezt a válaszkódot csak az eredeti HTTP-kiszolgálók használhatják (proxyk nem). Bevezetve a HTTP/1.1-ben.
• 306 (Fenntartva) – A specifikáció korábbi verzióiban használt válaszkód jelenleg le van foglalva. Az RFC 2616 (HTTP/1.1 frissítés) említi. A korai vázlatok szerint a kód azt jelentette, hogy Switch Proxy, azaz a kliens azt mondta, hogy változtassa meg a használt proxyt a szerver által a válaszfejlécben [18] megadottra .
• 307 Ideiglenes átirányítás – A kért erőforrás rövid ideig elérhető a Locationfejlécben megadott másik URI-n. A kérési mód (GET/POST) nem módosítható. Például egy POST kérést kell elküldeni egy új URI-ra ugyanazzal a POST módszerrel. Ezt a kódot a 302 helyett a 303-mal együtt vezették be a félreértések elkerülése érdekében. Bevezetve az RFC 2616 -ban (HTTP/1.1 frissítés).
• 308 Állandó átirányítás – A kért erőforrás véglegesen át lett helyezve a Locationfejlécben megadott új URI-ra. A kérési mód (GET/POST) nem módosítható. Például egy POST kérést kell elküldeni egy új URI-ra ugyanazzal a POST módszerrel. Ezt a kódot vezették be a 301 helyett a félreértések elkerülése érdekében. Az RFC 7238 -ban ( RFC 7538 ) vezették be.

Ügyfélhiba

A kódok osztálya 4xxaz ügyféloldali hibák jelzésére szolgál. Ha az összes módszert használja, kivéve HEADa kiszolgálót, a kiszolgálónak hiperszöveges magyarázatot kell adnia a felhasználó számára az üzenet törzsében.

• 400 Hibás kérés – A szerver szintaktikai hibát észlelt az ügyfél kérésében. Bevezetve a HTTP/1.0-ban.
• 401 Jogosulatlan – A kért erőforrás eléréséhez hitelesítés szükséges . A válaszfejlécnek tartalmaznia kell egy mezőt WWW-Authenticatea hitelesítési feltételek listájával. Vagyis a kért erőforrás eléréséhez a kliensnek egy kéréssel kell megjelennie, miközben Authorizationaz üzenet fejlécébe bele kell foglalnia a hitelesítéshez szükséges adatokat tartalmazó mezőt. Ha a kérés már tartalmaz engedélyezési adatokat, a 401-es válasz azt jelenti, hogy a hozzá tartozó engedélyezés megtagadva.
• 402 Fizetés szükséges – a jövőbeni felhasználásra szánják[ mikor? ] . Jelenleg[ mikor? ] nincs használatban. Ez a kód fizetős felhasználói szolgáltatásokra vonatkozik, nem pedig hosting cégekre. Ez azt jelenti, hogy ezt a hibát a tárhelyszolgáltató nem adja ki szolgáltatásai késedelmes fizetése esetén. HTTP/1.1 óta fenntartva.

• 403 Tiltott [19]  – A szerver megértette a kérést, de megtagadja annak teljesítését, mert a kliens hozzáférése korlátozott a megadott erőforráshoz. Más szavakkal, az ügyfél nem jogosult műveletek végrehajtására a kért erőforráson. Ha egy erőforráshoz való hozzáférés HTTP-hitelesítést igényel, akkor a szerver választ ad vissza 401, vagy 407ha proxyt használ. Egyébként a korlátokat a szerver rendszergazdája vagy a webalkalmazás fejlesztője állította be, és a használt szoftver képességeitől függően változhatnak . A szervert mindenesetre tájékoztatni KELL a kérés feldolgozásának megtagadásának okairól. A korlátozás legvalószínűbb oka a webszerver rendszererőforrásainak (például fájlok .htaccessvagy .htpasswd) elérésének kísérlete lehet, vagy olyan fájlok, amelyekhez konfigurációs fájlokkal megtagadták a hozzáférést, például a HTTP-n kívüli hitelesítés követelménye, hogy a regisztrált felhasználók számára elérheti a tartalomkezelő rendszert vagy szakaszt, vagy a szerver nem elégedett az ügyfél IP-címével , például blokkolva. Bevezetve a HTTP/1.0-ban.
• A 404 Not Found [20]  a leggyakoribb hiba az internet használatakor, ennek fő oka a weblap címének megírása. A szerver megértette a kérést, de nem talált megfelelő erőforrást a megadott URL-címen. Ha a szerver tudja, hogy ezen a címen volt egy dokumentum, akkor célszerű a 410 -es kódot használni . A válasz 404használható ahelyett 403, hogy bizonyos erőforrásokat gondosan el akar rejteni a kíváncsi szemek elől. Bevezetve a HTTP/1.0-ban.
• 405 Method Not Allowed – Az ügyfél által megadott metódus nem alkalmazható az aktuális erőforrásra. A válaszban a szervernek Allowvesszővel elválasztva a fejlécben fel kell tüntetnie az elérhető metódusokat. A szervernek vissza kell adnia ezt a hibát, ha a metódus ismert, de nem alkalmazható kifejezetten a kérésben megadott erőforrásra, de ha a megadott módszer nem alkalmazható a teljes szerveren, akkor a kliensnek vissza kell adnia a kódot 501( Nincs implementálva). Bevezetve a HTTP/1.1-ben.
• 406 Nem elfogadható – A kért URI nem felel meg a fejlécben megadott jellemzőknek. Ha a metódus nem HEAD, akkor a szervernek vissza kell adnia az adott erőforrás érvényes jellemzőinek listáját. Bevezetve a HTTP/1.1-ben.
• 407 Proxy hitelesítés szükséges – A válasz hasonló a kódhoz 401, azzal az eltéréssel, hogy a hitelesítés egy proxyszervernél történik. A mechanizmus hasonló az eredeti kiszolgálón történő hitelesítéshez. Bevezetve a HTTP/1.1-ben.
• 408 Kérelem időtúllépése – A kiszolgáló időtúllépést ért el az ügyféltől érkező átvitelre várva. Az ügyfél az előzőhöz hasonló kérést bármikor megismételheti. Ilyen helyzet fordulhat elő például akkor, ha nagy fájlt tölt fel a szerverre a POSTvagy a segítségével PUT. Az átvitel egy bizonyos pontján az adatforrás nem válaszol, például egy sérült CD vagy a helyi hálózat másik számítógépével való kommunikáció megszakadása miatt. Amíg a kliens nem továbbít semmit, válaszra vár, a kapcsolat a szerverrel megmarad. Egy idő után a szerver lezárhatja a kapcsolatot saját oldalán, hogy a többi kliens kérést intézhessen. Ez a válasz nem érkezik vissza, ha a kliens a felhasználó parancsára erőszakkal leállította az átvitelt, vagy a kapcsolat más okból megszakadt, mivel a válasz már nem küldhető el. Bevezetve a HTTP/1.1-ben.
• 409 Ütközés – A kérést nem lehetett teljesíteni erőforrás-ütközés miatt. Ez megtörténhet például akkor, amikor két kliens megpróbál módosítani egy erőforrást a PUT. Bevezetve a HTTP/1.1-ben.
• 410 Eltűnt – a szerver akkor küld ilyen választ, ha az erőforrás korábban a megadott URL-en volt, de törölték, és most nem érhető el. Ebben az esetben a szerver sem tudja az alternatív dokumentum (például egy másolat) helyét. Bevezetve a HTTP/1.1-ben.
• 411 Kötelező hossz – A megadott erőforráshoz az ügyfélnek meg kell adnia Content-Lengtha kérés fejlécében. A mező megadása nélkül ne próbálja meg újra kérni a szervert ehhez az URI-hoz. Az ilyen válasz természetes az olyan lekérdezéseknél, mint POSTés PUT. Például, ha a fájlok a megadott URI-n vannak letöltve, és a kiszolgálón korlátozott a kötetük. Akkor bölcsebb lenne már az elején ellenőrizni a fejlécet Content-Lengthés azonnal megtagadni a letöltést, mint értelmetlen terhelést provokálni a kapcsolat megszakításával, amikor a kliens valóban túl nagy üzenetet küld. Bevezetve a HTTP/1.1-ben.
• 412 Előfeltétel sikertelen – Visszaküldve, ha a kérés egyik feltételes fejlécmezője (If-Match stb., lásd RFC 7232 ) sem teljesült. Bevezetve a HTTP/1.1-ben.
• 413 Túl nagy rakomány – Visszaküldik, ha a szerver megtagadja a kérés feldolgozását, mert a kérés törzse túl nagy. A szerver lezárhatja a kapcsolatot a kérés további továbbításának leállítása érdekében. Ha a probléma átmeneti, ajánlott egy fejlécet a szerver válaszában Retry-Afterfeltüntetni, amely jelzi, hogy mennyi idő után ismételhető meg egy hasonló kérés. Bevezetve a HTTP/1.1-ben. Korábban "Túl nagy kérelmet kérő entitás" volt.
• 414 Túl hosszú URI – A szerver nem tudja feldolgozni a kérést, mert a megadott URI túl hosszú. GETIlyen hiba például akkor fordulhat elő, ha a kliens a metódus helyett hosszú paramétereket próbál átadni POST. Bevezetve a HTTP/1.1-ben. Korábban „A kérés-URI túl hosszú”.
• 415 Nem támogatott médiatípus – valamilyen oknál fogva a szerver nem hajlandó a megadott adattípussal dolgozni ezzel a módszerrel. Bevezetve a HTTP/1.1-ben.
• 416 Tartomány nem teljesíthető – Az Rangeerőforráson kívüli tartomány került megadásra a kérelem fejlécében, és a mező hiányzik If-Range. Ha a kliens egy bájttartományt küldött, akkor a szerver a Content-Rangefejlécben a tényleges méretet adhatja vissza. Ezt a választ nem szabad a típus átadásakor használnimultipart/byteranges . Bevezetve az RFC 2616 -ban (HTTP/1.1 frissítés). Korábban "A kért tartomány nem teljesíthető".
• 417 Várakozás sikertelen – Valamilyen oknál fogva a szerver nem tudja kielégíteni a Expectkérés fejléc mezőjének értékét. Bevezetve az RFC 2616 -ban (HTTP/1.1 frissítés).
• 418 Teáskanna vagyok – Ezt a kódot 1998-ban vezették be, mint az egyik hagyományos IETF áprilisi tréfát az RFC 2324 -ben, a Hyper Text Coffee Pot Control Protocol -ban . Ezt a kódot valós szerverek várhatóan nem támogatják [21] .
• 419-es hitelesítési időtúllépés (nem az RFC 2616 -ban ) – Ez a kód nem szerepel az RFC 2616 -ban, hanem olyan 401-es kódok alternatívájaként használatos, amelyek hitelesítettek, de megtagadják a hozzáférést bizonyos szervererőforrásokhoz. Általában a kódot akkor adják meg, ha a CSRF token elavult vagy hibásnak bizonyult.
• 421 Rosszul irányított kérés – A kérést egy olyan kiszolgálóra irányították át, amely nem tud válaszolni.
• 422 Feldolgozhatatlan entitás - a szerver sikeresen elfogadta a kérést, tud dolgozni a megadott típusú adatokkal (például a kérés törzse tartalmaz egy XML dokumentumot, amely megfelelő szintaxissal rendelkezik), de valamilyen logikai hiba van, ami miatt lehetetlen műveletet végrehajtani az erőforráson. Bevezetve a WebDAV -ban .
• 423 Zárolva – A kérelemből származó célerőforrás le van tiltva a megadott metódus alkalmazásában. Bevezetve a WebDAV -ban .
• 424 Sikertelen függőség – Az aktuális kérés végrehajtása egy másik művelet sikerétől függhet. Ha nem kerül végrehajtásra, és emiatt nem lehet végrehajtani az aktuális kérést, akkor a szerver ezt a kódot adja vissza. Bevezetve a WebDAV -ban .
• 425 Túl korai – A szerver nem áll készen a „korai információk” feldolgozásával járó kockázatok elfogadására. Az RFC 8470 -ben bevezetve , hogy megvédje a visszajátszási támadásokat, ha 0-RTT-t használ a TLS 1.3-ban.
• 426 Frissítés szükséges – A szerver utasítja az ügyfelet a protokoll frissítésére. A válaszfejlécnek jól formázott Upgradeés mezőket kell tartalmaznia Connection. Az RFC 2817 -ben bevezetve lehetővé teszi a HTTP -n keresztüli TLS -re való átállást .
• 428 Előfeltétel szükséges – A szerver utasítja a klienst, hogy használjon feltételfejléceket, például If-Match. Bevezetve az RFC 6585 tervezetben .
• 429 Túl sok kérés – Az ügyfél túl sok kérést próbált rövid időn belül elküldeni, ami például DDoS támadási kísérletet jelezhet. Egy Retry-After fejléc kísérheti, amely jelzi, mennyi ideig lehet újra próbálkozni a kéréssel. Bevezetve az RFC 6585 tervezetben .
• 431 Fejlécmezők kérése túl nagy – A fejlécek megengedett hosszát túllépték. A szervernek nem kell válaszolnia ezzel a kóddal, ehelyett egyszerűen visszaállíthatja a kapcsolatot. Bevezetve az RFC 6585 tervezetben .
• 434 A kért gazdagép nem érhető el – A kért cím nem érhető el .
• 449 Retry With – A kiszolgáló visszaküldi, ha nem kapott elegendő információt az ügyféltől a kérés feldolgozásához. Ebben az esetben a mező a válaszfejlécbe kerül Ms-Echo-Request. A Microsoft bevezette a WebDAV számára . Jelenleg[ mikor? ] legalább a Microsoft Money használja .
• 451 Jogi okokból  nem elérhető - az erőforráshoz való hozzáférés jogi okokból le van zárva, például hatóságok kérésére vagy szerzői jogok megsértése esetén a szerzői jog tulajdonosának kérésére. A Google által bevezetett IETF-tervezetben [12] , a hibakód Ray Bradbury Fahrenheit 451 című regényére utal . 2015. december 21-én került a szabványba [22] .
• A 499 Client Closed Request egy nem szabványos kód, amelyet az nginx javasolt és használ olyan esetekben, amikor az ügyfél lezárta a kapcsolatot, miközben az nginx feldolgozta a kérést.

Szerverhiba

A kódokat 5xxa kiszolgálóoldali műveletek végrehajtása során előforduló kezeletlen kivételek esetére szánják. A módszer használatán kívül minden esetben HEADa szervernek magyarázatot KELL megadnia az üzenet szövegében, amelyet a kliens megjelenít a felhasználónak.

• 500 Belső szerverhiba [23]  Bármilyen belső szerverhiba, amelyet az osztály többi hibája nem fed le. Bevezetve a HTTP/1.0-ban.
• 501 Nincs implementálva – A szerver nem támogatja a kérés feldolgozásához szükséges képességeket. Tipikus válasz olyan esetekre, amikor a szerver nem érti a kérésben megadott metódust. Ha a módszert ismeri a kiszolgáló, de nem alkalmazható erre az erőforrásra, akkor vissza kell adnia a választ 405. Bevezetve a HTTP/1.0-ban.
• 502 Hibás átjáró – Az átjáróként vagy proxyszerverként működő kiszolgáló érvénytelen válaszüzenetet kapott egy upstream szervertől. Bevezetve a HTTP/1.0-ban.
• 503 A szolgáltatás nem elérhető - a szerver technikai okok miatt (karbantartás, túlterhelés stb.) átmenetileg nem tudja feldolgozni a kéréseket. A Retry-Afterfejléc mezőben a szerver megadhatja azt az időt, amely után javasolt a kliensnek megismételni a kérést. Bár kézenfekvőnek tűnik a kapcsolat azonnali megszakítása torlódáskor, hatékonyabb lehet a mezőt nagy értékre Retry-Afterállítani a redundáns kérések gyakoriságának csökkentése érdekében. Bevezetve a HTTP/1.0-ban.
• 504 Gateway Timeout – Az átjáróként vagy proxyként működő kiszolgáló nem várta meg a felfelé irányuló kiszolgáló válaszát az aktuális kérés teljesítéséhez. Bevezetve a HTTP/1.1-ben.
• 505 HTTP-verzió nem támogatott – A szerver nem támogatja vagy megtagadja a HTTP-protokoll kérésben megadott verziójának támogatását. Bevezetve a HTTP/1.1-ben.
• 506 Variant Is Negotiates - Egy hibás konfiguráció eredményeként a kiválasztott változat önmagára mutat, ami miatt az összekapcsolási folyamat megszakad. Kísérleti. Az RFC 2295 -ben bevezetve , hogy a HTTP protokollt Transparent Content Negotiation technológiával egészítse ki .
• 507 Nincs elég tárhely – Nincs elég hely az aktuális kérés teljesítéséhez. A probléma átmeneti lehet. Bevezetve a WebDAV -ban .
• 508 hurok észlelve – A művelet megszakadt, mert a szerver végtelen ciklusba ütközött egy mélységi korlát nélküli kérés feldolgozása közben. Bevezetve a WebDAV -ban .
  • Az 508 Resource Limit Reached a CloudLinux 508-as hibájának egy változata, amely akkor jelentkezik, amikor elérik a tárhelykorlátokat [24] .
• 509 Sávszélesség-korlát túllépve – akkor használatos, ha a webhely túllépi a számára kijelölt forgalmi korlátot. Ebben az esetben a webhely tulajdonosának fel kell vennie a kapcsolatot a tárhelyszolgáltatójával. Jelenleg ezt a kódot egyetlen RFC sem írja le, és csak a „bw/limited” modul használja, amely a cPanel hosting vezérlőpultjában található , ahol bemutatták.
• 510 Nincs kiterjesztve – A kiszolgálónak nincs olyan kiterjesztése, amelyet az ügyfél használni szeretne. A szerver opcionálisan információkat küldhet a számára elérhető bővítményekről. Az RFC 2774 -ben bevezetve a HTTP-protokoll kiegészítéseként támogatja a bővítményeket.
• 511 Hálózati hitelesítés szükséges - ezt a választ nem az a szerver küldi, amelyre a kérést küldték, hanem egy közvetítő szerver - például a szolgáltató szervere -, ha a kliensnek először be kell jelentkeznie a hálózatba, például adjon meg egy jelszót fizetős internet-hozzáférési ponthoz. Feltételezzük, hogy a válasz törzse webes engedélyezési űrlapot vagy átirányítást ad vissza. Bevezetve az RFC 6585 tervezetben .
• 520 Ismeretlen hiba: akkor fordul elő, ha a CDN -kiszolgáló nem tudta feldolgozni a webszerver-hibát; egyéni CloudFlare kód .
• 521 A webszerver nem működik, akkor fordul elő, ha a webszerver elutasítja a CDN -kapcsolatokat; egyéni CloudFlare kód .
• 522 Connection Timed Out, akkor fordul elő, ha a CDN nem tudott csatlakozni a webszerverhez; egyéni CloudFlare kód .
• 523 Origin Is Unreachable, akkor fordul elő, ha a webszerver nem érhető el; egyéni CloudFlare kód .
• 524 Időtúllépés történt, akkor fordul elő, amikor a kapcsolat időtúllépése a CDN -kiszolgáló és a webszerver között. egyéni CloudFlare kód .
• 525 SSL-kézfogás sikertelen, akkor fordul elő, ha a CDN -kiszolgáló és a webszerver közötti SSL - kézfogás meghiúsul; egyéni CloudFlare kód .
• 526 Érvénytelen SSL-tanúsítvány, akkor fordul elő, ha a webszerver titkosítási tanúsítványa nem érvényesíthető; egyéni CloudFlare kód .

Lásd még

• HTTP-fejlécek listája
• Válaszkód

Jegyzetek

1. ↑ 1 2 2.2.6 449 "Újrapróbálkozás állapotkóddal" // Web Distributed Authoring and Versioning (WebDAV) protokoll: Client Extensions. Archiválva : 2009. október 5. a Wayback Machine -nél az MSDN-n
2. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 29 30 31 32 35 36 júni . _ 2018. 7. a Wayback Machine -nél » RFC 2068-ban
3. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 326 36 RFC . Hozzáférés dátuma: 2009. július 29. Az eredetiből archiválva : 2011. március 7.. (határozatlan)
4. ↑ 1 2 3 IETF WebDAV Advanced Collections Protocol -tervezet  - S.4.2.5 . Hozzáférés dátuma: 2012. május 18. Az eredetiből archiválva : 2012. július 9.. (határozatlan)
5. ↑ IETF tervezet WebDAV Advanced Collections Protocol  - S.10 . Hozzáférés dátuma: 2012. május 18. Az eredetiből archiválva : 2012. július 9.. (határozatlan)
6. ↑ rfc5842 . Letöltve: 2017. szeptember 12. Az eredetiből archiválva : 2017. október 10. (határozatlan)
7. ↑ 1 2 3 4 5 6 7 8 9 10 RFC 2616 "10.3 Átirányítás 3xx" (61. oldal) . Hozzáférés dátuma: 2009. július 29. Az eredetiből archiválva : 2011. március 7.. (határozatlan)
8. ↑ rfc7538 . Letöltve: 2017. szeptember 12. Az eredetiből archiválva : 2015. április 16.. (határozatlan)
9. ↑ IETF tervezet WebDAV Advanced Collections Protocol  - S.4.3.1.1 . Hozzáférés dátuma: 2012. május 18. Az eredetiből archiválva : 2012. július 9.. (határozatlan)
10. ↑ rfc7540 . Letöltve: 2017. szeptember 12. Az eredetiből archiválva : 2015. június 23. (határozatlan)
11. ↑ 1 2 3 4 RFC 6585
12. ↑ 1 2 Az IETF új HTTP állapotkód tervezete a jogi akadályok jelentésére . Letöltve: 2013. március 6. Az eredetiből archiválva : 2013. május 22.. (határozatlan)
13. ↑ RFC 2295 Transparent Content Negotiation in HTTP  -S.8.1 . Hozzáférés dátuma: 2012. május 18. Az eredetiből archiválva : 2012. június 8. (határozatlan)
14. ↑ IETF tervezet WebDAV Advanced Collections Protocol  - S.7.1 . Hozzáférés dátuma: 2012. május 18. Az eredetiből archiválva : 2012. július 9.. (határozatlan)
15. ↑ 1 2 3 4 5 6 7 Hibaoldalak – CloudFlare támogatás . Letöltve: 2016. április 18. Az eredetiből archiválva : 2016. március 4.. (határozatlan)
16. ↑ RFC 2068 "10.3 Redirection 3xx" (56. o.) Archiválva : 2018. június 7. a Wayback Machine -nél .
17. ↑ RFC 2616 , "10.3.3 302 Found" szakasz, 63. oldal Archiválva : 2011. március 7. a Wayback Machine -nél .
18. ↑ Josh Cohen HTTP/1.1 305 és 306 válaszkódok archiválva 2014. szeptember 8-án a Wayback Machine -nél  // Netscape Communications Corp., 1996. december 25.
19. ↑ Mit jelent a 403 Tilos? Archiválva : 2014. február 21. a Wayback Machine -nál .
20. ↑ A 404-es nem található hiba okai archiválva 2014. február 21-én a Wayback Machine -nél .
21. ↑ RFC 2324 – Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) .
22. ↑ draft-ietf-httpbis-legally-restricted-status-04 . datatracker.ietf.org. Letöltve: 2015. december 22. Az eredetiből archiválva : 2015. december 23.. (határozatlan)
23. ↑ Az 500-as belső szerverhiba leírása archiválva 2014. február 21-én a Wayback Machine -nél .
24. ↑ Erőforráskorlát elérve . www.cloudlinux.com _ Letöltve: 2022. június 21. Az eredetiből archiválva : 2021. május 15. (határozatlan)

Linkek

HTTP alapdokumentumok (a megjelenés dátuma szerint csökkenő sorrendben)

• Hypertext Transfer Protocol (HTTP) állapotkód-  nyilvántartó . IANA (2007. október 17.). - HTTP állapotkód nyilvántartás. Hozzáférés dátuma: 2009. július 30. Az eredetiből archiválva : 2012. február 17.
• RFC 2616 szabványtervezet "  Hypertext Transfer Protocol  - HTTP/1.1 "  ( angol ) IETF , 1999. június; Fielding Roy ( UC Irvine), Gettys Jim ( Compaq / W3C ), Mogul J. ( Compaq ), Frystyk Henrik( MIT / W3C ), Masinter L. ( Xerox ), Leach P. ( Microsoft ), Berners-Lee Tim ( W3C / MIT )  - a HTTP protokoll 1.1-es verziójának frissítése.
• RFC 2068 Javasolt szabvány " Hypertext Transfer Protocol - HTTP/1.1 "  (angol) (  angol nyelvről  -  "Hypertext Transfer Protocol - HTTP/1.1"); IETF , 1997. január; Fielding Roy ( UC Irvine), Gettys Jim ( DEC ), Mogul J. ( DEC ), Frystyk Henrik( MIT /LCS), Berners-Lee Tim ( MIT /LCS)  a HTTP 1.1-es verziójának korai specifikációja.
• RFC 1945 tájékoztató "  Hypertext Transfer Protocol - HTTP  /  1.0 " IETF , 1996. május; Berners-Lee Tim ( MIT /LCS), Fielding Roy ( UC Irvine ).), Frystyk Henrik( MIT /LCS)  a HTTP protokoll legelső specifikációja. Tartalmazza a HTTP/0.9 leírását is.

A HTTP-protokoll-kiterjesztésekről és -frissítésekről szóló dokumentumok (a megjelenés dátuma szerint csökkenő sorrendben)

• RFC 4918 javasolt szabvány "  HTTP kiterjesztések webes elosztott szerzői és  verziókezeléshez (  WebDAV ) " IETF , 2007. június; Dusseault Szerk. L. ( CommerceNet)  a WebDAV protokoll egy késői specifikációja, amely felváltja az RFC 2518 -at .
• RFC 3229 Javasolt szabvány " Delta kódolás HTTP-ben "  (angol) (  angolból  -  "Delta kódolás HTTP-ben"); IETF , 2002. január; Mogul J. ( Compaq WRL), Krishnamurthy B. ( AT&T ), Douglis F. ( AT&T ), Feldmann A. ( Saarbrückeni Egyetem)), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA) .
• RFC 2817 javasolt szabvány " Frissítés TLS   -re HTTP  / 1.1 -en belül " IETF , 2000. május; Khare Rohit(4K Associates/ UC Irvine), Lawrence S. (Agranat Systems, Inc.)  - frissítés az RFC 2616 -ra a HTTP és a TLS működésének leírásához .
• RFC 2774 Experimental " An HTTP Extension Framework "  (angol) (  angolul  -  "HTTP Extension Framework"); IETF , 2000. február; Nielsen H. ( Microsoft ), Leach P. ( Microsoft ), Lawrence S. (Agranat Systems) .
• Internet Draft " WebDAV Advanced Collections Protocol " (  angolul  - "WebDAV Advanced Collections Protocol  "); IETF , 1999. június 18.; Slein J. ( Xerox ), Whitehead Jr. EJ ( UC Irvine), Davis J. (CourseNet), Clemm G. ( Rational ), Fay C. ( FileNet), Crawford J. ( IBM ), Chihaya T. (DataChannel)  - gyűjteménykezelés a WebDAV-ban; 1999. december 18-án járt le.
• RFC 2518 javasolt szabvány " HTTP -  bővítmények  elosztott tartalomalkotáshoz –  WEBDAV " IETF , 1999. február; Goland Y. ( Microsoft ), Whitehead E. ( UC Irvine), Faizi A. ( Netscape ), Carter S. ( Novell ), Jensen D. ( Novell )  - a WebDAV protokoll első specifikációja (az RFC 4918 helyettesíti ).
•  RFC 2295 Kísérleti  átlátszó tartalom -  tárgyalás HTTP  -ben IETF , 1998. március; Holtman K. (TUE), Mutz A. ( Hewlett-Packard ) .

Kiegészítő anyagok

•  Web Distributed Authoring and Versioning (WebDAV) protokoll : Kliens-bővítmények . Microsoft (2007. március 14.). — Az ügyfélbővítmény támogatásának leírása a WebDAV protokollban. Hozzáférés dátuma: 2009. július 30. Az eredetiből archiválva : 2012. február 17.
• RFC 2324 információs " Hyper Text Coffee Pot Control Protocol (  HTCPCP  /  1.0 ) " IETF , 1998. április 1.; L. mester .
• KB 318380 IIS állapotkódok . Microsoft (2007. december 4.). — a HTTP és FTP protokollok kiterjesztett állapotkódjainak listája. Hozzáférés dátuma: 2010. január 16. Az eredetiből archiválva : 2012. február 17. (Orosz)
• A HTTP állapotkódok kézikönyve . Yandex . - HTTP állapotkódok feldolgozása Yandex robotok által . Letöltve: 2018. május 2. (határozatlan)

Web és weboldalak
globálisan	A világháló Web 1.0 Web 2.0 Web 3.0 szemantikus web Neuronet
Helyileg	Weboldal Portál oldal Szolgáltatás Gyűrű
Webhelyek és szolgáltatások típusai	Virtuális atlasz banner hálózat Könyvtár Blog ( platform ) Videó tárhely Wiki Névjegykártya oldal Kérdés válasz Könyvjelzők társkereső szolgáltatások böngészős játék Erőforrás-könyvtár Online áruház mikroblog híroldal Keresőrendszer pornó oldal Webes levelezés Közösségi háló Tumblelog BitTorrent nyomkövető Fájltárhely Fórum Szolgáltatás Képtábla Fotótárhely Csevegés
Alkotás és karbantartás	Fő Fejlődés Tervezés Elrendezés Programozás használhatóság Interakciós tapasztalat Weboldal promóció Keresőoptimalizálás (SEO) Tárhely Rendszergazda Moderátor fiók Engedélyezés
Elrendezések, oldalak, webhelyek típusai	Statikus Dinamikus Rögzített Radír dinamikusan rugalmas Adaptív
Műszaki	web szerver Böngésző DNS CMF CMS HTTP ( válaszok fejlécek ) SPDY QUIC CGI HTML XHTML css PHP JavaScript DHTML aprósütemény DOM XML AJAX JSON Vaku RSS atom besúgó Mikroformátum favicon.ico _ robots.txt Webhelytérképek az oldal térképe .htaccess
Marketing	Internetes marketing Internetes reklámozás Transzparens kontextuális reklámozás Bevezető Cyberguggolás
Társadalom és kultúra	Blogoszféra Internetes közösség ( kerület ) Hálózati irodalom

HTTP
Általános fogalmak	Állandó kapcsolat HTTP-csővezeték Tömörítés HTTPS HTTP/2 HTTP/3
Mód	LEHETŐSÉGEK KAP FEJ POST PUT TÖRÖL NYOM KAPCSOLAT TAPASZ
Címek	aprósütemény Etag Hivatkozó HTTP hely nyomon X-Forwarded-
Állapotkódok	1xx: Tájékoztató 2xx: Siker 3xx: Átirányítás 301: Véglegesen költözött 4xx: Ügyfélhiba 403 letiltva 404 nem található 451: Jogi okokból nem elérhető 5xx: Szerverhiba