Seznam stavových kódů HTTP

Stavový kód HTTP je součástí prvního řádku odpovědi serveru na požadavky HTTP .  Je to třímístné desetinné číslo. První číslice označuje třídu stavu . Po kódu odpovědi obvykle následuje mezerou oddělená vysvětlující fráze v angličtině, která dané osobě vysvětluje důvod takové odpovědi. Příklady:

Klient se z kódu odpovědi dozví o výsledcích svého požadavku a určí, jaké kroky podnikne dále. Sada stavových kódů je standardem a je popsána v příslušných dokumentech RFC . Zavedení nových kodexů by mělo být provedeno pouze po konzultaci s IETF . Existují však dva známé používané kódy, které nejsou uvedeny v RFC: 449 Retry With. Zmíněna je také vysvětlující fráze „Reply With“ [1] ve specifikaci pro WebDAV v Microsoft Developer Network představené společností Microsoft a 509 Bandwidth Limit Exceededpředstavené v cPanel .

Klient nemusí znát všechny stavové kódy, ale musí reagovat podle třídy kódu. V současnosti existuje pět tříd stavových kódů.

Webový server Internet Information Services ve svých souborech protokolu kromě standardních stavových kódů používá podkódy a zapisuje je s tečkou za hlavním. Zároveň se tento subkód neumisťuje do odpovědí ze serveru - potřebuje ho administrátor serveru, aby mohl přesněji určit zdroje problémů.

Seznam recenzí

Následuje přehledný seznam všech kódů odpovědí popsaných v tomto článku:

Popis kódů

Informační

Tato třída obsahuje kódy, které informují o procesu přenosu. Při práci s protokolem verze 1.0 by zprávy s takovými kódy měly být ignorovány. Ve verzi 1.1 musí být klient připraven přijmout tuto třídu zpráv jako normální odpověď, ale server nemusí nic odesílat. Samotné zprávy ze serveru obsahují pouze počáteční řádek odpovědi a v případě potřeby několik polí záhlaví specifických pro odpověď. Proxy servery by takové zprávy měly odesílat dále ze serveru klientovi.

Úspěch

Zprávy této třídy informují o případech úspěšného přijetí a zpracování požadavku klienta. V závislosti na stavu může server odesílat také záhlaví a tělo zprávy.

Přesměrování

Kódy v této třídě sdělují klientovi, že pro úspěšnou operaci musí být proveden další požadavek, obvykle na jiném URI . Z této třídy pět kódů 301, 302, 303a odkazuje 305přímo 307na přesměrování. Adresa, na kterou má klient zažádat, je uvedena serverem v souboru Location. To umožňuje použití fragmentů v cílovém URI.

Podle nejnovějších standardů může klient pouze přesměrovat, aniž by se uživatele zeptal, zda je druhý zdroj požadován pomocí metody GETnebo HEAD[7] . Předchozí specifikace říkaly, že aby se uživatel vyhnul zpáteční cestě, měl by být dotázán po 5. po sobě jdoucím přesměrování [16] . U všech přesměrování, pokud metoda požadavku nebyla HEAD, pak by měla být v těle odpovědi zahrnuta krátká hypertextová zpráva s cílovou adresou, aby se uživatel v případě chyby mohl sám navigovat.

Vývojáři HTTP poznamenávají, že mnoho klientů při přesměrování pomocí kódů chybně 301aplikuje 302metodu GETna druhý zdroj, přestože první požadavek byl s jinou metodou (nejčastěji PUT) [17] . Aby se předešlo nedorozuměním, HTTP/1.1 zavedlo kódy 303a 307doporučuje se používat místo 302. Metodu musíte změnit pouze v případě, že server odpověděl 303. V ostatních případech je další požadavek podán původní metodou.

Chování klientů pro různá přesměrování je popsáno v tabulce:

Stav odpovědi ukládání do mezipaměti Pokud metoda není GET nebo HEAD
301 Moved Permanently Můžete jako obvykle. Požádejte uživatele o potvrzení a vyžádejte si jiný zdroj pomocí původní metody.
307 Temporary Redirect Možné pouze v případě názvu Cache-Controlnebo Expires.
302 Found(HTTP/1.1)
302 Moved Temporarily(HTTP/1.0)
303 See Other Je to zakázáno. Přejít automaticky, ale pomocí GET.

Chyba klienta

Třída kódů 4xxje určena k označení chyb na straně klienta. Při použití všech metod kromě HEAD, server musí vrátit hypertextové vysvětlení pro uživatele v těle zprávy.

Chyba serveru

Kódy 5xxjsou vyhrazeny pro případy neošetřených výjimek při provádění operací na straně serveru. Pro všechny situace jiné než použití metody HEADMUSÍ server zahrnout vysvětlení do těla zprávy, kterou klient zobrazí uživateli.

Viz také

Poznámky

  1. 1 2 2.2.6 449 "Opakovat se stavovým kódem" // Protokol WebDAV (Web Distributed Authoring and Versioning): Klientská rozšíření. Archivováno 5. října 2009 na Wayback Machine na MSDN
  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 353 Stav 31 32 353 36. června _ _ 7, 2018 na Wayback Machine » v RFC 2068
  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 32 613 RFC . Datum přístupu: 29. července 2009. Archivováno z originálu 7. března 2011.
  4. 1 2 3 IETF Draft WebDAV Advanced Collections Protocol  - S.4.2.5 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012.
  5. IETF Draft WebDAV Advanced Collections Protocol  - S.10 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012.
  6. rfc5842 . Získáno 12. září 2017. Archivováno z originálu 10. října 2017.
  7. 1 2 3 4 5 6 7 8 9 10 RFC 2616 „10.3 Přesměrování 3xx“ (str. 61) . Datum přístupu: 29. července 2009. Archivováno z originálu 7. března 2011.
  8. rfc7538 . Získáno 12. září 2017. Archivováno z originálu 16. dubna 2015.
  9. IETF Draft WebDAV Advanced Collections Protocol  - S.4.3.1.1 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012.
  10. rfc7540 . Získáno 12. září 2017. Archivováno z originálu 23. června 2015.
  11. 1 2 3 4 RFC 6585
  12. 1 2 IETF navrhuje nový stavový kód HTTP pro hlášení právních překážek . Získáno 6. března 2013. Archivováno z originálu dne 22. května 2013.
  13. RFC 2295 Transparent Content Negotiation v HTTP  - S.8.1 . Datum přístupu: 18. května 2012. Archivováno z originálu 8. června 2012.
  14. IETF Draft WebDAV Advanced Collections Protocol  - S.7.1 . Datum přístupu: 18. května 2012. Archivováno z originálu 9. července 2012.
  15. 1 2 3 4 5 6 7 Error Pages – CloudFlare Support . Získáno 18. dubna 2016. Archivováno z originálu 4. března 2016.
  16. RFC 2068 "10.3 Redirection 3xx" (str. 56) Archivováno 7. června 2018 na Wayback Machine .
  17. RFC 2616 , sekce „10.3.3 302 Found“, strana 63 Archivováno 7. března 2011 na Wayback Machine .
  18. Kódy odpovědí Josh Cohen HTTP/1.1 305 a 306 Archivovány 8. září 2014 na Wayback Machine // Netscape Communications Corp., 25. prosince 1996  
  19. Co znamená 403 Forbidden? Archivováno 21. února 2014 na Wayback Machine .
  20. Příčiny chyby 404 Nenalezeno Archivováno 21. února 2014 na Wayback Machine .
  21. RFC 2324 – Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) .
  22. draft-ietf-httpbis-legally-restricted-status-04 . datatracker.ietf.org. Získáno 22. prosince 2015. Archivováno z originálu dne 23. prosince 2015.
  23. Popis 500 interní chyby serveru Archivováno 21. února 2014 na Wayback Machine .
  24. Bylo dosaženo limitu zdrojů . www.cloudlinux.com _ Získáno 21. června 2022. Archivováno z originálu 15. května 2021.

Odkazy

Základní dokumenty HTTP (sestupně podle data vydání) Dokumenty o rozšířeních a aktualizacích protokolu HTTP (sestupně podle data publikace) Doplňkové materiály