Ingyenes HTTP-státuszkód-referencia

Expect: 100-continue fejléccel rendelkező kérésekhez használható. A kiszolgáló elismeri, hogy hajlandó a törzs fogadására, mielőtt az ügyfél elküldi. Ritkán látható a modern webalkalmazásokban.

Leggyakrabban a WebSocket frissítésekhez használatos — az ügyfél Upgrade: websocket kérést küld, a kiszolgáló pedig 101-gyel válaszol a protokoll váltáshoz.

WebDAV köztes válasz, amely megakadályozza az ügyfél időtúllépését hosszú műveletek során. Elavult — a modern kiszolgálók nem szabad, hogy küldjék.

Lehetővé teszi a kiszolgálók számára, hogy Link fejléceket (előterhelés/előcsatlakozás) küldjenek, amíg a végső válasz még előkészítés alatt van, így a böngészők korábban kezdhetik el a kritikus objektumok lehívását.

A szokásos sikeres válasz. A jelentés az HTTP módszertől függ: GET → erőforrás visszaadva, POST/PUT → műveletet végrehajtva.

Gyakori POST után. A válasznak tartalmaznia kell egy Location fejléc, amely az új erőforrás URL-jére mutat.

Aszinkron műveletek esetén — a kiszolgáló sorbafogadja a munkát. Az ügyfélnek egy státusz végponton kell lekérdezni vagy később visszanézni.

A kérés sikeres volt, de egy közvetítő (például gyorsítótárazó vagy alakító proxy) módosította a terhet az origó kiszolgálótól — például a képek újra tömörítésével. Ritkán fordul elő a gyakorlatban.

Gyakran használatos DELETE műveleteknél vagy PUT frissítéseknél, amelyeknek nem kell törzsöt visszaadniuk. Az ügyfél nem szabad, hogy az aktuális oldalról eltérjen.

Hasonlóan a 204-hez, nincs törzs visszaadva — de az ügyfélnek azt is közlik, hogy állítsa vissza az űrlapot vagy nézetet, amely a kérést előidézte (pl. törölje az űrlap mezőit a következő bejegyzéshez).

Válasz Range kérésre. A videólejátszók és letöltési menedzserek használják az meg nem szakított letöltések folytatásához vagy nagyméretű fájlok streameléshez.

WebDAV: egy XML törzs több részműveletre vonatkozó kimenetel független jelentéséről tudósít — például egy tömeges mozgatás, ahol néhány elem sikeres, mások pedig sikertelenek voltak.

WebDAV: 207 Multi-Status válaszokon belül használatos, hogy elkerüljük az ugyanabban a gyűjteményben lévő tagok ismételt felsorolását, amikor a kötések hurkokat hoznak létre.

Delta kódolás: a kiszolgáló egy korábbi verziójú diffet ad vissza az erőforrás helyett, mentésével sávszélességgel. Nagyon ritkán valósítanak meg.

A kiszolgáló több lehetőséget kínál (például különféle formátumok vagy nyelvek), és az ügyfélnek egyet kell választania. Ritkán használatos, mert az automatikus tartalomegyeztetés általában ezt kezeli.

Használjon állandó URL-módosítások esetén — a keresőmotorok frissítik indexüket. A SEO tekintély az új URL-re adódik át.

Azt jelzi, hogy az átirányítás nem állandó. A gyorsítótárazás kevésbé agresszív, mint a 301. Használjon olyan dolgokhoz, mint az 'bejelentkezés szükséges, átirányítás a /login-re'.

POST beküldés után használatos — a válasz azt mondja, hogy 'a POST-od működött, lásd ezt a GET URL-t az eredményért'. A böngészők mindig GET-et végeznek az új URL-en.

Válasz feltételes kérésre (If-None-Match vagy If-Modified-Since fejlécekkel). Megkímél sávszélességet — nincs törzs visszaadva.

Ha az eredeti POST volt, az átirányítás is POST-ot használ. Modern alternatíva a 302-hez, ha a módszer megőrzése fontos.

A 301 modern helyettesítője, amikor azt szeretné, hogy a POST kérések POST maradjanak az átirányítás után.

Gyakori okok: hibás JSON a törzshöz, érvénytelen lekérdezési paraméterek vagy hiányzó szükséges mezők. Ellenőrizze a kérés törzsét és fejléceit.

Az ügyfélnek hitelesítési hitelesítő adatokat kell tartalmaznia (Authorization fejléc, cookie, token). Az 'Unauthorized' egy félrevezető — valójában 'nem hitelesített'.

Eredetileg digitális kifizetésekhez szántak. Modern használat: az API-k néha 402-t adnak vissza, amikor a felhasználó túllépte az ingyenes kvótáját.

Eltér a 401-től — a felhasználó BEjelentkezett, de a fiók nem rendelkezik engedéllyel ehhez az erőforráshoz. Ellenőrizze a szerep- és engedélylogikát.

Az URL hibás, az erőforrás törlésre került, vagy soha nem létezett. A kiszolgálók néha 404-et adnak vissza annak elrejtésére, hogy a 403 pontosabb lenne.

Például egy GET kérés egy végpontra, amely csak POST-ot fogad el. A válasznak tartalmaznia kell egy Allow fejléc, amely az érvényes módszereket sorolja fel.

Az ügyfél egy tartalomtípust, nyelvet vagy kódolást kért (az Accept, Accept-Language, Accept-Encoding fejléceken keresztül), amelyet a kiszolgáló nem tud teljesíteni. Sok kiszolgáló kihagyja a szigorú egyeztetést, és helyette alapértelmezést ad vissza.

Hasonló a 401-hez, de egy proxy által kiadva: az ügyfélnek Proxy-Authorization hitelesítő adatokat kell küldenie. Vállalati hálózatokon látható, hitelesítő proxyval.

Az ügyfél túl sokáig várt a kérés törzse elküldésével, vagy nyitva tartotta a kapcsolatot. Próbálja meg újra a kérést.

Általában párhuzamos szerkesztési ütközések vagy duplikált erőforrások létrehozása miatt kerül vissza (például olyan felhasználó létrehozása, akinek az e-mail címe már létezik).

Erősebb, mint a 404 — a szerver kifejezetten tudja, hogy az erőforrás KORÁBBAN létezett, de véglegesen eltávolításra került. A keresőmotorok eltávolítják az indexből.

A kérés elutasításra került, mert hiányzott a Content-Length fejléc, és a szerver nem fogadja el az ismeretlen méretű törzsöket. Adja hozzá a fejlécet, és próbálja meg újra.

Akkor kerül vissza, amikor az If-Match vagy If-Unmodified-Since típusú feltételes fejlécek meghiúsulnak — általában optimista zárolás: valaki más módosította az erőforrást az Ön verziója óta. Kérje le újra és próbálja meg újra.

Gyakori nagy fájlok feltöltésekor. A szerver konfigurációja (nginx, apache) maximális törzsméretet állít be. Ellenőrizze a szerver konfigurációját.

Általában nagyon hosszú lekérdezési karakterláncok okozzák (például adatok kódolása GET-ben). Váltson POST törzset, vagy emelje meg a szerver korlátját, ha Ön irányítja.

Például application/xml küldése egy olyan szervernek, amely csak application/json-t fogad. Állítsa be helyesen a Content-Type fejlécet.

A Range fejléc a fájl olyan részét kéri, amely nem létezik — például letöltés folytatása a fájl vége után. A válasz tartalmaznia kell a Content-Range fejlécet a tényleges mérettel.

Akkor küldik, amikor a szerver nem támogatja az Expect: 100-continue fejlécet. Egyes ügyfelek alapértelmezésben ezt a fejlécet küldik nagy POST-ekben; letiltása általában megoldja a hibát.

Az 1998-as április 1-jei tréfa (RFC 2324). Egyes valódi API-k tréfákra vagy elavult végpontok jelölésére használják. Nem éles használatra.

Gyakori HTTP/2 kapcsolat újrafelhasználásakor: a kérés olyan szerverhez érkezet, amely nincs konfigurálva a cél állomásnévhez. Az ügyfélnek új kapcsolaton kell újrapróbálkoznia.

Például a JSON helyesen lett feldolgozva, de hiányzott egy kötelező mező, vagy egy mező értéke tartományon kívül volt. A REST API validációs válaszokban gyakori.

WebDAV: a forrás vagy cél erőforrást egy másik ügyfél zárolta, így az operáció nem folytatható. Várjon, amíg a zár feloldódik, vagy törölje azt a megfelelő tokennel.

WebDAV: a függő műveletek láncolatában egy korábbi akcó meghiúsult, így ez nem hajtódott végre. Az előző hibára keresve találja meg az alapvető okot.

A TLS 1.3 0-RTT-hez (korai adatok) kapcsolódik: a szerver nem kockáztat meg egy lehetséges ismétlődő kérés feldolgozását. Az ügyfélnek újra kell próbálkoznia a kézfogás befejezése után.

A szerver megtagadja a kérés kiszolgálását az aktuális protokollon, de után fog — a válasz tartalmaz egy Upgrade fejlécet, amely az szükséges protokollt nevezi meg.

A szerver feltételes fejléceket követel meg (például If-Match) az elveszett frissítés ütközések megelőzésére. Kérje le az erőforrást, rögzítse az ETag-et, és küldje el újra az If-Match-del.

Lassítson. A válasznak tartalmaznia kell egy Retry-After fejlécet, amely jelzi, hogy mikor lehet újra próbálkozni. Gyakori az olyan API-k esetében, amelyeknek van kérés kvótája.

Egy fejléc vagy a fejlécek teljes mérete meghaladja a korlátot — leggyakrabban túl nagy sütik okozzák ezt. Törölje a sütiket, vagy csökkentse azt, amit az alkalmazás tárol bennük.

Az erőforrás jogi okok miatt blokkolva van — cenzúra, bírósági parancsok vagy regionális előírások. A szám a Fahrenheit 451 regényre utal.

Egy általános felhasználási eset szerver oldali hibákra. Ellenőrizze a szerver naplóit az igazi ok megtalálásához: kezeletlen kivétel, adatbázis hiba stb.

Például a szerver nem ismeri fel a HTTP metódust. A gyakorlatban ritka — gyakrabban a 405-et fog látni.

Gyakori mikro-szolgáltatás architektúrában. A terheléselosztó vagy fordított proxy rosszul formázott választ kapott a backend szolgáltatástól.

Vagy karbantartás alatt van, vagy túlterhelt. A válasznak tartalmaznia kell egy Retry-After fejlécet. Gyakran visszaadva az üzembe helyezések során.

A backend szolgáltatás nem válaszolt időben. Ellenőrizze az upstream szolgáltatás egészségét és időtúllépési konfigurációit.

A kérés fő HTTP verziója nem támogatott a szerver által. Szinte soha nem látható modern ügyfelekkel.

Az átlátszó tartalomegyeztetés végtelen ciklushá vált: a kiválasztott változat saját maga tartalomegyeztetésre van konfigurálva. Szerver konfigurációs hibát jelez.

WebDAV-specifikus eredeti azonban néha általános szerverek is használják. A szerver nem tudja menteni a kérést a tárolási korlátok miatt.

WebDAV: a Depth: infinity kérés feldolgozása során ciklus jött létre (például kör alakú kötések). A műveletet leállították.

Az elavult HTTP Extension Framework-ből: a szerver több információt igényel a kérés teljesítése előtt. Hatékonyan fel van függesztve a modern webtől.

Az elfogó portálok (szállodai/repülőtéri WiFi) által használva annak jelzésére, hogy a felhasználónak be kell jelentkeznie a hálózatra, mielőtt külső helyekre lépne.