Keressen meg bármely HTTP státuszkódot: mit jelent, mikor küldik a szerverek, és melyik specifikáció határozza meg. Keresés szám vagy kulcsszó alapján, szűrés osztály szerint, és közvetlen hivatkozás egy kódra.
A szerver megkapta a kérésfejléceket, és a kliens elküldheti a törzset. Akkor fordul elő, amikor a kliens nagy törzs feltöltése előtt „Expect: 100-continue” fejlécet küld.
A végső válasz előtt küldik, hogy a böngésző megkezdhesse a Link fejlécekben felsorolt erőforrások előbetöltését. A CDN-ek és a szerverek a lapok betöltésének gyorsítására használják.
A kérés sikeres volt, és új erőforrást hozott létre, amelyet általában a Location fejléc azonosít. Jellemzően sikeres, rekordot létrehozó POST után fordul elő.
A kérést feldolgozásra elfogadták, de még nem fejeződött be. A munkát sorba állító API-k használják, például exportálásoknál vagy kötegelt feladatoknál.
A kérés sikeres volt, és nincs visszaadandó tartalom. Gyakori DELETE-kéréseknél, valamint adatok mentésekor, ha a kliensnek nincs szüksége választörzsre.
A szerver csak a kliens által kért bájttartományt adja vissza. Akkor látható, amikor videók streamelnek, letöltések folytatódnak, vagy a kliens Range fejlécet küld.
Az erőforrás véglegesen a Location fejlécben megadott URL-re költözött. A böngészők és a keresőmotorok frissítik a hivatkozásaikat; egyes kliensek a követés során a POST-ot GET-re cserélik.
Az erőforrás átmenetileg a Location fejlécben megadott másik URL-en található. Gyakori bejelentkezések után és rövid távú átirányításoknál; a böngészők általában GET metódussal követik.
A kliensnek GET metódussal kell lekérnie az eredményt egy másik URL-ről. Űrlap POST elküldése után használatos, hogy átirányítson egy megerősítő oldalra (Post/Redirect/Get minta).
A gyorsítótárazott másolat még érvényes, ezért a szerver nem küld törzset. Akkor látható, amikor a böngésző If-None-Match vagy If-Modified-Since fejléccel újra ellenőriz egy gyorsítótárazott fájlt.
Az erőforrás átmenetileg egy másik URL-en található, és a kliensnek ugyanazzal a metódussal és törzzsel kell megismételnie a kérést. A böngészők belső HSTS-átirányításokhoz is használják HTTPS-re.
Az erőforrás véglegesen átkerült, és a kliensnek ugyanazt a metódust és törzset kell használnia az új URL-en. A 307 végleges megfelelője, biztonságos POST-kérések átirányításához.
A kérésből hiányoznak az érvényes hitelesítési adatok. A neve ellenére „nem hitelesített” állapotot jelent; a szerver egy WWW-Authenticate fejlécet küld, amely leírja a bejelentkezés módját.
A szerver megértette a kérést, de elutasítja, és az újbóli bejelentkezés sem segít. Akkor fordul elő, ha hiányoznak a jogosultságok, le van tiltva a könyvtárlistázás, vagy egy tűzfal blokkolja a klienst.
Az erőforrás létezik, de nem támogatja az alkalmazott HTTP-metódust, például POST egy csak olvasható URL-en. A válasz az Allow fejlécben sorolja fel az engedélyezett metódusokat.
A kérés fejlécében megadott feltétel, például az If-Match, nem teljesült. Arra szolgál, hogy megakadályozza egy erőforrás felülírását, ha az megváltozott a kliens utolsó olvasása óta.
A kérés törzse nagyobb, mint amit a szerver elfogad. Akkor fordul elő, ha a feltöltött fájl meghaladja a korlátot, például az nginx client_max_body_size értékét.
Az URL hosszabb, mint amit a szerver feldolgoz. Általában az okozza, ha egy űrlap túl sok adatot küld GET módszerrel, vagy egy átirányítási hurok folyamatosan paramétereket fűz hozzá.
Áprilisi tréfa az 1998-as Hyper Text Coffee Pot Control Protocolból: egy teáskanna, amely nem hajlandó kávét főzni. A HTTP a kódot nem használtként tartja nyilván, de egyes szerverek húsvéti tojásként vagy nem kívánt botok elutasítására adják vissza.
A kérés formailag helyes, de a tartalma érvénytelen, például egy űrlap, amely nem felelt meg az érvényesítési szabályoknak. Az API-k széles körben használják érvényesítési hibákhoz.
A kliens túl sok kérést küldött egy adott idő alatt. Az API-k sebességkorlátozásra használják, és gyakran Retry-After fejlécet is küldenek, amely megadja, mikor érdemes újra próbálkozni.
Nem szabványos kód. Az nginx belsőleg arra használja, hogy válasz küldése nélkül lezárja a kapcsolatot, gyakran a nem kívánt forgalom eldobására; a kliensek valójában soha nem kapják meg.
Nem szabványos kód. Az nginx akkor naplózza, ha a kliens a szerver válasza előtt lezárta a kapcsolatot, például a felhasználó megszakított egy lassú oldalt, vagy kliensoldali időtúllépés történt.
A szerver váratlan hibába ütközött, és nem tudta teljesíteni a kérést. Általános hiba programhibából, összeomlásból vagy hibás konfigurációból; a részletek a szervernaplóban vannak.
Egy átjáró vagy proxy érvénytelen választ kapott a felsőbb szervertől. Gyakori, ha az nginx vagy egy terheléselosztó mögötti alkalmazás összeomlott vagy éppen újraindul.
A szerver átmenetileg nem tudja kezelni a kérést, mert túlterhelt vagy karbantartás miatt leállt. A Retry-After fejléc jelezheti, mikor érdemes újra próbálni.
Egy átjáró vagy proxy nem kapott időben választ a felsőbb szervertől. Akkor fordul elő, ha egy háttérkérés túl lassú, például egy hosszú adatbázis-lekérdezés.
A kliensnek hitelesítenie kell magát a hálózati hozzáféréshez. Ezt a kódot a szállodai, repülőtéri vagy kávézói Wi-Fi beléptető portáljai küldik bejelentkezés előtt.
Nem szabványos kód. A Cloudflare akkor adja vissza, ha az origin szerver elutasította a kapcsolatot, általában azért, mert a webkiszolgáló nem elérhető, vagy blokkolja a Cloudflare IP-címeit.
Nem szabványos kód. A Cloudflare akkor adja vissza, ha csatlakozott az origin szerverhez, de nem kapott HTTP-választ az időtúllépési határidőn belül (alapértelmezés szerint 100 másodperc).
Nem szabványos kód. A Cloudflare akkor adja vissza, ha az origin SSL-tanúsítványa érvénytelen, és a Full (strict) SSL mód engedélyezve van.
Definiálva: Cloudflare
Használata
Gépeljen be egy kódszámot (például 404 vagy csak 5 az összes szerverhibához) vagy egy kulcsszót, például „átirányítás” vagy „időtúllépés”.
Szűkítse a listát az osztályszűrővel: információs, sikeres, átirányítás, klienshiba vagy szerverhiba.
Használja a „Link másolása” lehetőséget bármelyik kódnál, hogy közvetlen hivatkozást osszon meg rá, például hibajelentésben.
Hogyan működik
Minden HTTP-válasz egy háromjegyű státuszkóddal kezdődik. Az első számjegy határozza meg az osztályt: 1xx információs válaszok, 2xx siker, 3xx átirányítás, 4xx a kérés által okozott hibák, 5xx pedig szerveroldali hibák. Azok a kliensek, amelyek egy adott kódot nem ismernek, az osztály x00 kódjaként kezelik, így egy ismeretlen 4xx kódot 400-asként kezelnek.
Az alapvető kódokat az RFC 9110 (HTTP Semantics, 2022) határozza meg, amely a régebbi RFC 7231 helyébe lépett. A többi kód kiterjesztésekből származik: WebDAV (RFC 4918), a 428, 429, 431 és 511 kódokhoz az RFC 6585, a 451-hez az RFC 7725, a 425-höz pedig az RFC 8470. Az RFC 9110 két kódot is átnevezett: a 413 mostantól „Content Too Large”, a 422 pedig „Unprocessable Content”, bár még találkozhatunk a régi „Payload Too Large” és „Unprocessable Entity” elnevezésekkel.
Néhány, a naplókban előforduló kód egyáltalán nem szabvány. Az nginx belsőleg használja a 444-et és a 494–499-et (a 499 azt jelzi, hogy a kliens feladta a várakozást), a Cloudflare pedig 520–526-ot ad vissza, ha nem tud megfelelő választ kapni az eredeti kiszolgálótól. Ezek a listában „Nem szabványos” jelöléssel szerepelnek. A státuszszövegek (például „Not Found”) angolul jelennek meg, ahogy a specifikációkban szerepelnek; a HTTP/2 és HTTP/3 csak a számot küldi.
Példák
301 vagy 308 webhely költöztetésekor
Mindkettő végleges. Használja a 301-et az egyszerű oldaláthelyezésekhez; 308-at akkor használjon, ha a klienseknek meg kell ismételniük a POST vagy PUT kérést az új URL-re, mert egyes kliensek 301 után a POST-ot GET-re cserélik.
401 kontra 403
Az API 401-et ad vissza, ha nem küldenek tokent vagy lejárt tokent küldenek, ezért a kliensnek be kell jelentkeznie. Akkor ad 403-at, ha a token érvényes, de a felhasználónak nincs jogosultsága, így az újbóli bejelentkezés nem segít.
502-es hiba diagnosztizálása nginx mögött
Az nginx 502 Bad Gateway hibája azt jelenti, hogy a mögötte lévő alkalmazás nem válaszolt megfelelően. Ellenőrizze, hogy az alkalmazásfolyamat fut-e, és mit naplózott; az 504-es ezzel szemben azt jelzi, hogy túl lassan válaszolt.
Gyakori kérdések
Mi a különbség a 404-es és a 410-es között?
A 404-es azt jelenti, hogy a szerver nem találja az erőforrást, és semmit sem mond a jövőről. A 410-es azt jelzi, hogy az erőforrást szándékosan távolították el, és nem fog visszatérni, ami segít a keresőmotoroknak, hogy hamarabb eltávolítsák az URL-t.
A validációs hiba 400-at vagy 422-t adjon vissza?
Mindkettőt használják. A 400 olyan kérésekhez illik, amelyeket a szerver nem tud értelmezni, például hibás JSON. A 422 olyan kérésekhez illik, amelyek helyesen értelmezhetők, de érvénytelen értékeket tartalmaznak, például egy e-mail mező @ nélkül.
A 418 „I'm a teapot” valódi státuszkód?
Egy 1998-as április elsejei RFC-ből származik. Az RFC 9110 a 418-at nem használtként tartja nyilván, így semmi máshoz nincs hozzárendelve, és néhány szerver viccből adja vissza, de nincs szabványos jelentése.
Honnan származik a 499?
A 499 nginx-specifikus. Az nginx naplókban jelenik meg, amikor a kliens bezárja a kapcsolatot, mielőtt a szerver választ küldene. A kliens soha nem kap 499-et; ez általában lassú válaszokra vagy kliensoldali időtúllépésekre utal.
A keresőmotorok a 302-t úgy kezelik, mint a 301-et?
A 302 ideiglenes áthelyezést jelez, ezért a keresőmotorok általában először az eredeti URL-t tartják indexelve. Ha a 302 hosszú ideig megmarad, a Google állandó átirányításként kezelheti. Állandó áthelyezéshez használjon 301-et vagy 308-at.
Adatvédelem
A lista az oldal része. A keresés és a szűrés a böngészőjében történik; a keresőkifejezéseket nem küldjük sehova, és nem szerepelnek az analitikában.