Lista över HTTP-statuskoder

HTTP -statuskoden är en del av den första raden i serversvaret för HTTP -förfrågningar .  Det är ett tresiffrigt decimaltal. Den första siffran anger statusklassen . Svarskoden följs vanligtvis av en mellanslagsseparerad förklarande fras på engelska, som förklarar för personen orsaken till ett sådant svar. Exempel:

Kunden lär sig av svarskoden om resultatet av sin förfrågan och bestämmer vilka åtgärder som ska vidtas härnäst. Uppsättningen av statuskoder är en standard och de beskrivs i relevanta RFC- dokument . Införandet av nya koder bör endast ske efter samråd med IETF . Det finns dock två kända koder som används som inte nämns i RFC: 449 Retry With. Också nämnt är den förklarande frasen "Svara med" [1] i specifikationen för WebDAV i Microsoft Developer Network introducerad av Microsoft och 509 Bandwidth Limit Exceededintroducerad i cPanel .

Klienten kanske inte känner till alla statuskoder, men den måste svara enligt kodklassen. Det finns för närvarande fem klasser av statuskoder.

Internet Information Services webbserver i sina loggfiler, förutom standardstatuskoder, använder underkoder, skriver dem med en prick efter den huvudsakliga. Samtidigt placeras inte denna underkod i svar från servern - den behövs av serveradministratören så att han mer exakt kan fastställa källorna till problem.

Granskningslista

Följande är en översiktslista över alla svarskoder som beskrivs i den här artikeln:

Beskrivning av koder

Informationsinformation

Denna klass innehåller koder som informerar om överföringsprocessen. När du arbetar genom protokollversion 1.0 bör meddelanden med sådana koder ignoreras. I version 1.1 måste klienten vara beredd att acceptera denna meddelandeklass som ett normalt svar, men servern behöver inte skicka något. Meddelanden från själva servern innehåller endast svarsstartraden och, om så krävs, några svarsspecifika rubrikfält. Proxyservrar bör skicka sådana meddelanden vidare från servern till klienten.

Framgång

Meddelanden från denna klass informerar om fall av framgångsrikt godkännande och bearbetning av en kundförfrågan. Beroende på status kan servern även skicka rubriker och en meddelandetext.

Omdirigering

Koder i den här klassen talar om för klienten att ytterligare en begäran måste göras för att operationen ska lyckas, vanligtvis vid en annan URI . Av den här klassen hänvisar fem koder 301, 302, 303, 305och 307direkt till omdirigeringar. Adressen som klienten ska göra en begäran till anges av servern i Location. Detta gör att fragment kan användas i mål-URI.

Enligt de senaste standarderna kan klienten endast omdirigera utan att fråga användaren om den andra resursen begärs med hjälp av metoden GETeller HEAD[7] . Tidigare specifikationer sa att för att undvika rundresor bör användaren tillfrågas efter den 5:e omdirigeringen i följd [16] . För alla omdirigeringar, om förfrågningsmetoden inte var HEAD, bör ett kort hypertextmeddelande med destinationsadressen inkluderas i svarskroppen, så att användaren kan navigera själv i händelse av ett fel.

HTTP-utvecklare noterar att många klienter, när de omdirigerar med koder 301och 302felaktigt tillämpar metoden GETpå den andra resursen, trots att den första begäran var med en annan metod (oftast PUT) [17] . För att undvika missförstånd introducerade HTTP/1.1 koder 303och 307och rekommenderas att användas istället för 302. Du behöver bara ändra metoden om servern svarade 303. I andra fall görs nästa begäran med den ursprungliga metoden.

Beteendet hos klienter för olika omdirigeringar beskrivs i tabellen:

Svarsstatus cachelagring Om metoden inte är GET eller HEAD
301 Moved Permanently Du kan som vanligt. Be användaren om bekräftelse och begär en annan resurs med den ursprungliga metoden.
307 Temporary Redirect Endast möjligt om en titel Cache-Controleller Expires.
302 Found(HTTP/1.1)
302 Moved Temporarily(HTTP/1.0)
303 See Other Det är förbjudet. Gå automatiskt, men med hjälp av GET.

Klientfel

Klassen av koder 4xxär avsedd att indikera fel på klientsidan. När du använder alla metoder utom HEAD, måste servern returnera en hypertextförklaring för användaren i meddelandets brödtext.

Serverfel

Koderna 5xxär dedikerade till fall av obehandlade undantag när man utför operationer på serversidan. För alla andra situationer än att använda metoden HEADMÅSTE servern inkludera en förklaring i meddelandets brödtext som klienten kommer att visa för användaren.

Se även

Anteckningar

  1. 1 2 2.2.6 449 "Försök igen med statuskod" // Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions. Arkiverad 5 oktober 2009 på Wayback Machine på 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 35 34 och 36 31 32 33 36 . 7, 2018 på Wayback Machine » i 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 2 . Datum för åtkomst: 29 juli 2009. Arkiverad från originalet den 7 mars 2011.
  4. 1 2 3 IETF-utkast till WebDAV Advanced Collections Protocol  - S.4.2.5 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012.
  5. IETF utkast till WebDAV Advanced Collections Protocol  - S.10 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012.
  6. rfc5842 . Hämtad 12 september 2017. Arkiverad från originalet 10 oktober 2017.
  7. 1 2 3 4 5 6 7 8 9 10 RFC 2616 "10.3 Omdirigering 3xx" (sid. 61) . Datum för åtkomst: 29 juli 2009. Arkiverad från originalet den 7 mars 2011.
  8. rfc7538 . Hämtad 12 september 2017. Arkiverad från originalet 16 april 2015.
  9. IETF Draft WebDAV Advanced Collections Protocol  - S.4.3.1.1 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012.
  10. rfc7540 . Hämtad 12 september 2017. Arkiverad från originalet 23 juni 2015.
  11. 1 2 3 4 RFC 6585
  12. 1 2 IETF utarbetar en ny HTTP-statuskod för att rapportera juridiska hinder . Hämtad 6 mars 2013. Arkiverad från originalet 22 maj 2013.
  13. RFC 2295 Transparent Content Negotiation i HTTP  - S.8.1 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 8 juni 2012.
  14. IETF Draft WebDAV Advanced Collections Protocol  - S.7.1 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012.
  15. 1 2 3 4 5 6 7 Felsidor - CloudFlare Support . Hämtad 18 april 2016. Arkiverad från originalet 4 mars 2016.
  16. RFC 2068 "10.3 Redirection 3xx" (sid. 56) Arkiverad 7 juni 2018 på Wayback Machine .
  17. RFC 2616 , avsnitt "10.3.3 302 Found", sida 63 Arkiverad 7 mars 2011 på Wayback Machine .
  18. Josh Cohen HTTP/1.1 305 och 306 svarskoder Arkiverade 8 september 2014 på Wayback Machine  // Netscape Communications Corp., 25 december 1996
  19. Vad betyder 403 Förbjudet? Arkiverad 21 februari 2014 på Wayback Machine .
  20. Orsaker till ett 404 Not Found Error Arkiverad 21 februari 2014 på Wayback Machine .
  21. RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) .
  22. draft-ietf-httpbis-legaly-restricted-status-04 . datatracker.ietf.org. Hämtad 22 december 2015. Arkiverad från originalet 23 december 2015.
  23. Beskrivning av 500 internt serverfel Arkiverat 21 februari 2014 på Wayback Machine .
  24. Resursgränsen nådd . www.cloudlinux.com _ Hämtad 21 juni 2022. Arkiverad från originalet 15 maj 2021.

Länkar

HTTP-kärndokument (fallande efter publiceringsdatum) Dokument om HTTP-protokolltillägg och uppdateringar (fallande efter publiceringsdatum) Ytterligare material