Liste over HTTP-statuskoder

HTTP - statuskoden er en del af den første linje i serversvaret for HTTP -anmodninger .  Det er et trecifret decimaltal. Det første ciffer angiver statusklassen . Svarkoden efterfølges normalt af en mellemrumsadskilt forklarende sætning på engelsk, som forklarer personen årsagen til et sådant svar. Eksempler:

Klienten lærer af svarkoden om resultaterne af hans anmodning og bestemmer, hvilke handlinger der skal tages derefter. Sættet af statuskoder er en standard, og de er beskrevet i de relevante RFC- dokumenter . Indførelse af nye koder bør kun ske efter samråd med IETF . Der er dog to kendte koder i brug, som ikke er nævnt i RFC: 449 Retry With. Også nævnt er den forklarende sætning "Svar med" [1] i specifikationen for WebDAV i Microsoft Developer Network introduceret af Microsoft og 509 Bandwidth Limit Exceededintroduceret i cPanel .

Klienten kender måske ikke alle statuskoder, men den skal svare i henhold til kodeklassen. Der er i øjeblikket fem klasser af statuskoder.

Internet Information Services -webserveren i sine logfiler, ud over standardstatuskoder, bruger underkoder og skriver dem med en prik efter den primære. Samtidig er denne underkode ikke placeret i svar fra serveren - den er nødvendig af serveradministratoren, så han mere præcist kan bestemme kilderne til problemer.

Anmeldelsesliste

Følgende er en oversigt over alle svarkoder beskrevet i denne artikel:

Beskrivelse af koder

Oplysende

Denne klasse indeholder koder, der informerer om transmissionsprocessen. Når du arbejder gennem protokolversion 1.0, skal meddelelser med sådanne koder ignoreres. I version 1.1 skal klienten være forberedt på at acceptere denne beskedklasse som et normalt svar, men serveren behøver ikke at sende noget. Beskederne fra selve serveren indeholder kun svarstartlinjen og om nødvendigt nogle få svarspecifikke overskriftsfelter. Proxyservere bør sende sådanne meddelelser videre fra serveren til klienten.

Succes

Meddelelser fra denne klasse informerer om tilfælde af vellykket accept og behandling af en klientanmodning. Afhængigt af status kan serveren også sende headers og en meddelelsestekst.

Omdirigering

Koder i denne klasse fortæller klienten, at der skal foretages en anden anmodning for at operationen skal lykkes, normalt ved en anden URI . Af denne klasse refererer fem koder 301, 302, 303, 305og 307direkte til omdirigeringer. Adressen, som klienten skal sende en anmodning til, angives af serveren i Location. Dette gør det muligt at bruge fragmenter i mål-URI'en.

Ifølge de nyeste standarder kan klienten kun omdirigere uden at spørge brugeren, om den anden ressource er anmodet om ved hjælp af GETeller metoden HEAD[7] . Tidligere specifikationer sagde, at for at undgå rundrejser, skal brugeren spørges efter den 5. omdirigering i træk [16] . For alle omdirigeringer, hvis anmodningsmetoden ikke var HEAD, så skal en kort hypertekstmeddelelse med destinationsadressen inkluderes i svarteksten, så brugeren i tilfælde af fejl kan navigere selv.

HTTP-udviklere bemærker, at mange klienter, når de omdirigerer med koder 301og 302fejlagtigt anvender metoden GETtil den anden ressource, på trods af at den første anmodning var med en anden metode (oftest PUT) [17] . For at undgå misforståelser introducerede HTTP/1.1 koder 303, og 307og anbefales at blive brugt i stedet for 302. Du behøver kun at ændre metoden, hvis serveren svarede 303. I andre tilfælde foretages den næste anmodning med den oprindelige metode.

Klienters adfærd for forskellige omdirigeringer er beskrevet i tabellen:

Svarstatus caching Hvis metoden ikke er GET eller HEAD
301 Moved Permanently Det kan du som sædvanlig. Bed brugeren om bekræftelse og anmod om en anden ressource ved hjælp af den oprindelige metode.
307 Temporary Redirect Kun muligt hvis en titel Cache-Controleller Expires.
302 Found(HTTP/1.1)
302 Moved Temporarily(HTTP/1.0)
303 See Other Det er forbudt. Gå automatisk, men ved hjælp af GET.

Klientfejl

Klassen af ​​koder 4xxer beregnet til at indikere fejl på klientsiden. Når du bruger alle metoder undtagen HEAD, skal serveren returnere en hypertekstforklaring til brugeren i meddelelsens brødtekst.

Serverfejl

Koderne 5xxer dedikeret til tilfælde af ubehandlede undtagelser, når der udføres operationer på serversiden. For alle andre situationer end at bruge metoden HEADSKAL serveren inkludere en forklaring i brødteksten af ​​meddelelsen, som klienten vil vise til brugeren.

Se også

Noter

  1. 1 2 2.2.6 449 "Prøv igen med statuskode" // Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions. Arkiveret 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 og juni 31 32 35 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 . Dato for adgang: 29. juli 2009. Arkiveret fra originalen den 7. marts 2011.
  4. 1 2 3 IETF Draft WebDAV Advanced Collections Protocol  - S.4.2.5 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 9. juli 2012.
  5. IETF Draft WebDAV Advanced Collections Protocol  - S.10 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 9. juli 2012.
  6. rfc5842 . Hentet 12. september 2017. Arkiveret fra originalen 10. oktober 2017.
  7. 1 2 3 4 5 6 7 8 9 10 RFC 2616 "10.3 Omdirigering 3xx" (s. 61) . Dato for adgang: 29. juli 2009. Arkiveret fra originalen den 7. marts 2011.
  8. rfc7538 . Hentet 12. september 2017. Arkiveret fra originalen 16. april 2015.
  9. IETF Draft WebDAV Advanced Collections Protocol  - S.4.3.1.1 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 9. juli 2012.
  10. rfc7540 . Hentet 12. september 2017. Arkiveret fra originalen 23. juni 2015.
  11. 1 2 3 4 RFC 6585
  12. 1 2 IETF udarbejder en ny HTTP-statuskode for at rapportere juridiske hindringer . Hentet 6. marts 2013. Arkiveret fra originalen 22. maj 2013.
  13. RFC 2295 Transparent Content Negotiation i HTTP  - S.8.1 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 8. juni 2012.
  14. IETF Draft WebDAV Advanced Collections Protocol  - S.7.1 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 9. juli 2012.
  15. 1 2 3 4 5 6 7 Fejlsider - CloudFlare Support . Hentet 18. april 2016. Arkiveret fra originalen 4. marts 2016.
  16. RFC 2068 "10.3 Redirection 3xx" (s. 56) Arkiveret 7. juni 2018 på Wayback Machine .
  17. RFC 2616 , afsnit "10.3.3 302 fundet", side 63 Arkiveret 7. marts 2011 på Wayback Machine .
  18. Josh Cohen HTTP/1.1 305 og 306 svarkoder Arkiveret 8. september 2014 på Wayback Machine  // Netscape Communications Corp., 25. december 1996
  19. Hvad betyder 403 Forbudt? Arkiveret 21. februar 2014 på Wayback Machine .
  20. Årsager til en 404 ikke fundet fejl Arkiveret 21. februar 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. Hentet 22. december 2015. Arkiveret fra originalen 23. december 2015.
  23. Beskrivelse af 500 intern serverfejl arkiveret 21. februar 2014 på Wayback-maskinen .
  24. Ressourcegrænse nået . www.cloudlinux.com _ Hentet 21. juni 2022. Arkiveret fra originalen 15. maj 2021.

Links

HTTP-kernedokumenter (faldende efter udgivelsesdato) Dokumenter om HTTP-protokoludvidelser og -opdateringer (faldende efter udgivelsesdato) Yderligere materialer