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:
- 201 Oprettet .
- 401 Uautoriseret .
- 507 Utilstrækkelig opbevaring .
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.
- 100 Fortsæt - Serveren er tilfreds med de indledende oplysninger om anmodningen, klienten kan fortsætte med at sende overskrifter. Introduceret i HTTP/1.1.
- 101 Switching Protocols - Serveren opfylder anmodningen fra klienten og skifter protokoller i henhold til indikationen givet i header-feltet Upgrade. Serveren sender en svarheader Upgrade, der angiver den protokol, den har skiftet til. Introduceret i HTTP/1.1.
- 102 Behandling - Anmodningen blev accepteret, men det vil tage lang tid at behandle den. Bruges af serveren til at forhindre klienten i at afslutte forbindelsen på grund af en timeout. Klienten skal, efter at have modtaget et sådant svar, nulstille timeren og vente på den næste kommando i normal tilstand. Dukkede op i WebDAV .
- 103 Tidlige tip - Bruges til at returnere en del af overskrifterne tidligt, når fulde svaroverskrifter ikke kan dannes hurtigt.
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.
- 200 OK - vellykket anmodning. Hvis nogen data blev anmodet om af klienten, er det i overskriften og/eller brødteksten i meddelelsen. Introduceret i HTTP/1.0.
- 201 Oprettet - En ny ressource blev oprettet som et resultat af en vellykket anmodning. Serveren KAN angive adresserne (der kan være mere end én) på den oprettede ressource i brødteksten i svaret, med den foretrukne adresse angivet i Location. Serveren anbefales at angive karakteristikaene for den oprettede ressource og dens adresse i svarteksten, formatet på svarlegemet bestemmes af overskriften Content-Type. Ved behandling af en anmodning skal der oprettes en ny ressource før svaret sendes til klienten, ellers et svar med kode 202. Introduceret i HTTP/1.0.
- 202 Accepteret - Anmodningen blev accepteret til behandling, men den blev ikke gennemført. Klienten skal ikke vente på den endelige transmission af beskeden, da en meget lang proces kan startes. Introduceret i HTTP/1.0.
- 203 Ikke-autoritativ information - ligner 200, men i dette tilfælde blev den information, der transmitteres, ikke taget fra den primære kilde (backup, en anden server osv.) og er derfor muligvis ikke opdateret. Introduceret i HTTP/1.1.
- 204 Intet indhold - Serveren behandlede anmodningen med succes, men kun overskrifter blev sendt i svaret uden en meddelelsestekst. Klienten behøver ikke at opdatere indholdet af dokumentet, men kan anvende de modtagne metadata på det . Introduceret i HTTP/1.0.
- 205 Nulstil indhold - Serveren forpligter klienten til at nulstille de data, som brugeren har indtastet. Serveren transmitterer ikke meddelelsens brødtekst, og dokumentet skal ikke opdateres. Introduceret i HTTP/1.1.
- 206 Delvist indhold - Serveren fuldførte en delvis GET-anmodning og returnerede kun en del af meddelelsen. I overskriften angiver Content-Rangeserveren indholdets byteområder . Når du arbejder med sådanne svar, skal der lægges særlig vægt på caching. Introduceret i HTTP/1.1. ( mere... )
- 207 Multi-Status - serveren transmitterer resultaterne af flere uafhængige operationer på én gang. De placeres i selve beskedteksten som et XML- dokument med en multistatus. Det anbefales ikke at placere statusser fra serien i dette objekt på grund 1xxaf meningsløsheden og redundansen. Dukkede op i WebDAV .
- 208 Allerede rapporteret - DAV-bindende medlemmer er allerede opført i den foregående del (multistatus) af svaret og er ikke inkluderet igen.
- 226 IM brugt - headeren A-IMblev modtaget fra klienten, og serveren returnerer indholdet under hensyntagen til de angivne parametre. Introduceret i RFC 3229 for at udvide HTTP-protokollen med understøttelse af delta-kodning .
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:
- 300 Multiple Choices - På den angivne URI er der flere muligheder for at levere en ressource efter MIME -type , efter sprog eller efter andre karakteristika. Serveren sender en liste over alternativer med beskeden, så valget kan foretages automatisk af klienten eller brugeren. Introduceret i HTTP/1.0.
- 301 Flyttet permanent - Det anmodede dokument er blevet permanent flyttet til den nye URI, der er angivet i Locationoverskriftsfeltet. Nogle klienter opfører sig forkert, når de behandler denne kode. Introduceret i HTTP/1.0.
- 302 fundet, 302 flyttet midlertidigt - Det ønskede dokument er midlertidigt tilgængeligt på en anden URI, der er angivet i overskriften i Location. Denne kode kan f.eks. bruges i serverdrevet indholdsforhandling . Nogle[ hvad? ] klienter opfører sig forkert, når de behandler denne kode. Introduceret i HTTP/1.0.
- 303 Se Andet - Dokumentet på den anmodede URI skal rekvireres på adressen i Locationoverskriftsfeltet ved hjælp af metoden GET, selvom den første blev anmodet med en anden metode. Denne kode blev introduceret sammen med koden 307for at undgå tvetydighed, så serveren kan være sikker på, at den næste ressource vil blive anmodet af GET. For eksempel har en webside et tekstindtastningsfelt til hurtig navigation og søgning. Efter at have indtastet dataene, foretager browseren en anmodning ved hjælp af metoden POST, herunder den indtastede tekst i meddelelsens brødtekst. Hvis et dokument med det indtastede navn findes, svarer serveren med koden 303, der angiver Locationdens permanente adresse i overskriften. Så vil browseren med garanti anmode om det med en metode GETtil at få indholdet. Ellers vil serveren blot returnere søgeresultatsiden til klienten. Introduceret i HTTP/1.1.
- 304 Ikke ændret - Serveren returnerer denne kode, hvis klienten anmodede om dokumentet ved hjælp af eller GEToverskriften , og dokumentet ikke er ændret siden det angivne tidspunkt. I dette tilfælde må servermeddelelsen ikke indeholde et brødtekst. Introduceret i HTTP/1.0.If-Modified-SinceIf-None-Match
- 305 Brug proxy - Anmodningen om den anmodede ressource skal foretages via en proxyserver, hvis URI er angivet i Locationoverskriftsfeltet. Denne svarkode kan kun bruges af oprindelses-HTTP-servere (ikke proxyer). Introduceret i HTTP/1.1.
- 306 (Reserveret) - Brugt i tidligere versioner af specifikationen, er svarkoden i øjeblikket reserveret. Nævnt i RFC 2616 (HTTP/1.1-opdatering). Ifølge tidlige udkast betød koden Switch Proxy, der fortalte klienten at ændre proxyen i brug til den, der er angivet af serveren i svaroverskriften [18] .
- 307 Midlertidig omdirigering - Den anmodede ressource er kortvarigt tilgængelig på en anden URI angivet i Locationoverskriftsfeltet. Anmodningsmetoden (GET/POST) må ikke ændres. For eksempel skal en POST-anmodning sendes til en ny URI ved hjælp af den samme POST-metode. Denne kode blev introduceret sammen med 303 i stedet for 302 for at undgå tvetydighed. Introduceret i RFC 2616 (HTTP/1.1-opdatering).
- 308 Permanent omdirigering - Den anmodede ressource er blevet permanent flyttet til den nye URI, der er angivet i Locationoverskriftsfeltet. Anmodningsmetoden (GET/POST) må ikke ændres. For eksempel skal en POST-anmodning sendes til en ny URI ved hjælp af den samme POST-metode. Denne kode blev indført i stedet for 301 for at undgå tvetydighed. Introduceret i RFC 7238 ( RFC 7538 ).
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.
- 400 Bad Request - Serveren stødte på en syntaksfejl i klientens anmodning. Introduceret i HTTP/1.0.
- 401 Uautoriseret - Godkendelse er påkrævet for at få adgang til den anmodede ressource . Svarhovedet skal indeholde et felt WWW-Authenticatemed en liste over godkendelsesbetingelser. Med andre ord, for at få adgang til den anmodede ressource, skal klienten præsentere sig selv ved at sende en forespørgsel, og samtidig inkludere et felt Authorizationmed de data, der kræves til autentificering i meddelelseshovedet. Hvis anmodningen allerede indeholder autorisationsdata, betyder et 401-svar, at godkendelse med den afvises.
- 402 Betaling påkrævet - beregnet til at blive brugt i fremtiden[ hvornår? ] . På nuværende tidspunkt[ hvornår? ] bruges ikke. Denne kode er til betalte brugertjenester, ikke til hostingfirmaer . Det betyder, at denne fejl ikke vil blive udstedt af hostingudbyderen i tilfælde af forsinket betaling for sine tjenester. Reserveret siden HTTP/1.1.
- 403 Forbidden [19] - Serveren forstod anmodningen, men den nægter at opfylde den på grund af begrænsninger i adgangen for klienten til den specificerede ressource. Med andre ord er klienten ikke autoriseret til at udføre operationer på den anmodede ressource. Hvis adgang til en ressource kræver HTTP-godkendelse, vil serveren returnere et svar 401, eller 407når der bruges en proxy. Ellers er grænserne blevet sat af serveradministratoren eller udvikleren af webapplikationen og kan variere afhængigt af den software , der bruges . Under alle omstændigheder SKAL serveren informeres om årsagerne til at nægte at behandle anmodningen. De mest sandsynlige årsager til begrænsningen kan være et forsøg på at få adgang til systemressourcerne på webserveren (f.eks. filer .htaccesseller .htpasswd) eller filer, som blev nægtet adgang til ved hjælp af konfigurationsfiler, kravet om anden godkendelse end HTTP, f.eks. få adgang til indholdsstyringssystemet eller sektionen for registrerede brugere, eller serveren er ikke tilfreds med klientens IP-adresse , for eksempel når den er blokeret. Introduceret i HTTP/1.0.
- 404 Ikke fundet [20] er den mest almindelige fejl ved brug af internettet, hovedårsagen er en fejl ved at skrive adressen på en webside. Serveren forstod anmodningen, men fandt ikke en matchende ressource på den angivne URL. Hvis serveren ved, at der var et dokument på denne adresse, så er det ønskeligt at bruge koden 410 . Svaret 404kan bruges i stedet 403for, hvis du omhyggeligt vil skjule visse ressourcer for nysgerrige øjne. Introduceret i HTTP/1.0.
- 405 Metode ikke tilladt - Metoden specificeret af klienten kan ikke anvendes på den aktuelle ressource. I svaret skal serveren angive de tilgængelige metoder i overskriften Allow, adskilt af et komma. Serveren skal returnere denne fejl, hvis metoden er kendt af den, men den er ikke anvendelig specifikt til den ressource, der er angivet i anmodningen, men hvis den angivne metode ikke er anvendelig på hele serveren, skal klienten returnere koden 501( Ikke implementeret). Introduceret i HTTP/1.1.
- 406 Ikke acceptabel - Den anmodede URI kan ikke opfylde de karakteristika, der er givet i overskriften. Hvis metoden ikke var HEAD, så skulle serveren returnere en liste over gyldige karakteristika for den givne ressource. Introduceret i HTTP/1.1.
- 407 Proxy-godkendelse påkrævet - Svaret ligner koden 401, bortset fra at godkendelse udføres for en proxyserver. Mekanismen ligner godkendelse på oprindelsesserveren. Introduceret i HTTP/1.1.
- 408 Request Timeout - Serveren fik timeout og ventede på en overførsel fra klienten. Klienten kan til enhver tid gentage anmodningen svarende til den foregående. For eksempel kan en sådan situation opstå, når en stor fil uploades til serveren ved hjælp af POSTeller PUT. På et tidspunkt i overførslen holdt datakilden op med at reagere, for eksempel på grund af en beskadiget cd eller tab af kommunikation med en anden computer på det lokale netværk. Så længe klienten ikke transmitterer noget og venter på et svar fra den, opretholdes forbindelsen til serveren. Efter nogen tid kan serveren lukke forbindelsen på sin side for at tillade andre klienter at lave en anmodning. Dette svar returneres ikke, når klienten tvangsstoppede overførslen på brugerens kommando, eller forbindelsen blev afbrudt af en anden årsag, da svaret ikke længere kan sendes. Introduceret i HTTP/1.1.
- 409 Konflikt - Anmodningen kunne ikke gennemføres på grund af en ressourcekonflikt. Dette kan for eksempel ske, når to klienter forsøger at ændre en ressource ved hjælp af PUT. Introduceret i HTTP/1.1.
- 410 Borte - serveren sender et sådant svar, hvis ressourcen plejede at være på den angivne URL, men blev slettet og nu ikke er tilgængelig. I dette tilfælde kender serveren heller ikke placeringen af det alternative dokument (f.eks. en kopi). Introduceret i HTTP/1.1.
- 411 Længde påkrævet - For den angivne ressource skal klienten angive Content-Lengthi anmodningshovedet. Uden at angive dette felt, bør du ikke prøve anmodningen til serveren for denne URI igen. Et sådant svar er naturligt for forespørgsler som POSTog PUT. For eksempel, hvis filer downloades på den angivne URI, og der er en grænse for deres volumen på serveren. Så ville det være klogere at tjekke overskriften helt i begyndelsen Content-Lengthog straks nægte at downloade, end at fremprovokere en meningsløs belastning ved at bryde forbindelsen, når klienten virkelig sender en besked, der er for stor. Introduceret i HTTP/1.1.
- 412 Forudsætning mislykkedes - Returneres, hvis ingen af de betingede overskriftsfelter (If-Match, etc., se RFC 7232 ) i anmodningen er blevet udfyldt. Introduceret i HTTP/1.1.
- 413 Payload Too Large - Returneres, hvis serveren nægter at behandle anmodningen, fordi anmodningens tekst er for stor. Serveren KAN lukke forbindelsen for at stoppe yderligere transmission af anmodningen. Hvis problemet er midlertidigt, anbefales det at inkludere en header i serversvaret, der Retry-Afterangiver det tidspunkt, hvorefter en lignende anmodning kan gentages. Introduceret i HTTP/1.1. Tidligere kaldt "Request Entity Too Large".
- 414 URI for lang - Serveren kan ikke behandle anmodningen, fordi den angivne URI er for lang. En sådan fejl kan for eksempel fremkaldes, når klienten forsøger at sende lange parametre gennem metoden GETi stedet for POST. Introduceret i HTTP/1.1. Tidligere kaldt "Request-URI Too Long".
- 415 Ikke-understøttet medietype - af en eller anden grund nægter serveren at arbejde med den angivne datatype med denne metode. Introduceret i HTTP/1.1.
- 416 Range Not Satisfiable - Et Rangeområde uden for ressourcen blev angivet i anmodningsheaderfeltet, og feltet mangler If-Range. Hvis klienten sendte et byteinterval, så MÅ serveren returnere den faktiske størrelse i Content-Rangeheader-feltet. Dette svar bør ikke bruges ved beståelse af typemultipart/byteranges . Introduceret i RFC 2616 (HTTP/1.1-opdatering). Tidligere kaldt "Requested Range Not Satisfiable".
- 417 Forventning mislykkedes - Af en eller anden grund kan serveren ikke opfylde værdien af Expectanmodningshovedfeltet. Introduceret i RFC 2616 (HTTP/1.1-opdatering).
- 418 I'm a teapot - Denne kode blev introduceret i 1998 som en af de traditionelle IETF aprilsnar i RFC 2324 , Hyper Text Coffee Pot Control Protocol . Denne kode forventes ikke at blive understøttet af rigtige servere [21] .
- 419 Authentication Timeout (ikke i RFC 2616 ) - Denne kode er ikke i RFC 2616 , brugt som et alternativ til 401-koder, der er godkendt, men nægtet adgang til visse serverressourcer. Normalt gives koden, hvis CSRF-tokenet er forældet eller viser sig at være forkert.
- 421 Misdirected Request - Anmodningen blev omdirigeret til en server, der ikke var i stand til at svare.
- 422 Unprocessable Entity - serveren accepterede anmodningen med succes, kan arbejde med den angivne type data (forespørgselslegemet indeholder f.eks. et XML - dokument, der har den korrekte syntaks), men der er en form for logisk fejl, på grund af hvilken det er umuligt at udføre en operation på ressourcen. Introduceret i WebDAV .
- 423 Låst - Målressourcen fra anmodningen er blokeret fra at anvende den angivne metode på den. Introduceret i WebDAV .
- 424 Mislykket afhængighed - Implementeringen af den aktuelle anmodning kan afhænge af succesen af en anden operation. Hvis den ikke udføres, og på grund af dette er det umuligt at udføre den aktuelle anmodning, vil serveren returnere denne kode. Introduceret i WebDAV .
- 425 for tidligt - Serveren er ikke klar til at acceptere risiciene ved at behandle "tidlig information". Introduceret i RFC 8470 for at beskytte mod replay-angreb ved brug af 0-RTT i TLS 1.3.
- 426 Opgradering påkrævet - Serveren instruerer klienten om at opgradere protokollen. Svaroverskriften skal indeholde veludformet Upgradeog felter Connection. Introduceret i RFC 2817 for at muliggøre overgang til TLS over HTTP.
- 428 Forudsætning påkrævet - Serveren fortæller klienten at bruge betingelsesoverskrifter som If-Match. Introduceret i udkast til RFC 6585 .
- 429 Too Many Requests - Klienten forsøgte at sende for mange anmodninger på kort tid, hvilket kan indikere for eksempel et forsøg på DDoS-angreb. Kan være ledsaget af en Retry-After-overskrift, der angiver, hvor længe anmodningen kan prøves igen. Introduceret i udkast til RFC 6585 .
- 431 Anmodningshovedfelter er for store - Den tilladte længde af overskrifter er blevet overskredet. Serveren er ikke forpligtet til at svare med denne kode, i stedet kan den blot nulstille forbindelsen. Introduceret i udkast til RFC 6585 .
- 434 Request host unavailable - Den anmodede adresse er ikke tilgængelig .
- 449 Prøv igen med - Returneres af serveren, hvis der ikke blev modtaget nok information fra klienten til at behandle anmodningen. I dette tilfælde placeres feltet i svarhovedet Ms-Echo-Request. Introduceret af Microsoft til WebDAV . På nuværende tidspunkt[ hvornår? ] bruges af mindst Microsoft Money .
- 451 Utilgængelig af juridiske årsager - adgangen til ressourcen er lukket af juridiske årsager, for eksempel efter anmodning fra offentlige myndigheder eller efter anmodning fra indehaveren af ophavsretten i tilfælde af krænkelse af ophavsretten. Introduceret i et IETF-udkast af Google [12] , hvor fejlkoden er en reference til Ray Bradburys roman Fahrenheit 451 . Det blev tilføjet til standarden den 21. december 2015 [22] .
- 499 Client Closed Request er en ikke-standard kode foreslået og brugt af nginx til tilfælde, hvor klienten lukkede forbindelsen, mens nginx behandlede anmodningen.
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.
- 500 Intern serverfejl [23] Enhver intern serverfejl, der ikke er dækket af resten af klassefejlene. Introduceret i HTTP/1.0.
- 501 Ikke implementeret - Serveren understøtter ikke de nødvendige funktioner til at behandle anmodningen. Et typisk svar i tilfælde, hvor serveren ikke forstår den metode, der er angivet i anmodningen. Hvis metoden er kendt af serveren, men den ikke er anvendelig for denne ressource, skal du returnere svaret 405. Introduceret i HTTP/1.0.
- 502 Bad Gateway - Serveren, der fungerede som en gateway eller proxyserver, modtog en ugyldig svarmeddelelse fra en upstream-server. Introduceret i HTTP/1.0.
- 503 Service Utilgængelig - serveren er midlertidigt ude af stand til at behandle anmodninger af tekniske årsager (vedligeholdelse, overbelastning osv.). I Retry-Afteroverskriftsfeltet kan serveren angive den tid, hvorefter det anbefales, at klienten gentager anmodningen. Selvom det virker oplagt at afslutte forbindelsen med det samme under overbelastning, kan det være mere effektivt at indstille feltet til en stor værdi Retry-Afterfor at reducere hyppigheden af redundante anmodninger. Introduceret i HTTP/1.0.
- 504 Gateway Timeout - Serveren, der fungerede som en gateway eller proxy, ventede ikke på et svar fra upstream-serveren for at fuldføre den aktuelle anmodning. Introduceret i HTTP/1.1.
- 505 HTTP-version ikke understøttet - Serveren understøtter ikke eller nægter at understøtte den version af HTTP-protokollen, der er angivet i anmodningen. Introduceret i HTTP/1.1.
- 506 Variant forhandler også - Som følge af en fejlagtig konfiguration peger den valgte variant på sig selv, på grund af hvilken linkingsprocessen afbrydes. Eksperimentel. Introduceret i RFC 2295 for at udvide HTTP-protokollen med Transparent Content Negotiation -teknologi .
- 507 Utilstrækkelig lagerplads - Der er ikke plads nok til at fuldføre den aktuelle anmodning. Problemet kan være midlertidigt. Introduceret i WebDAV .
- 508 løkke detekteret - Operation annulleret pga serveren stødte på en uendelig løkke under behandling af en anmodning uden dybdebegrænsning. Introduceret i WebDAV .
- 508 Resource Limit Reached er en variant af fejl 508 i CloudLinux , der opstår, når hostinggrænserne er nået [24] .
- 509 Båndbreddegrænse overskredet - bruges, når webstedet overskrider grænsen for trafikforbrug, der er tildelt det. I dette tilfælde skal webstedsejeren kontakte deres hostingudbyder. I øjeblikket er denne kode ikke beskrevet i nogen RFC og bruges kun af "bw/limited"-modulet inkluderet i cPanel -hosting-kontrolpanelet , hvor den blev introduceret.
- 510 Not Extended - Serveren har ikke en udvidelse, som klienten ønsker at bruge. Serveren kan eventuelt sende oplysninger om tilgængelige udvidelser. Introduceret i RFC 2774 for at udvide HTTP-protokollen med understøttelse af udvidelser.
- 511 Network Authentication Required - dette svar sendes ikke af den server, som anmodningen var beregnet til, men af en mellemliggende server - for eksempel udbyderens server - hvis klienten først skal logge på netværket, skal du f.eks. indtaste en adgangskode for et betalt internetadgangspunkt. Det antages, at selve svaret returnerer en webautorisationsformular eller en omdirigering til den. Introduceret i udkast til RFC 6585 .
- 520 Ukendt fejl, opstår, når CDN -serveren ikke var i stand til at behandle webserverfejlen; brugerdefineret CloudFlare kode .
- 521 Web Server Is Down, opstår, når CDN -forbindelser afvises af webserveren; brugerdefineret CloudFlare kode .
- 522 Forbindelse timet ud, opstår, når CDN'et ikke kunne oprette forbindelse til webserveren; brugerdefineret CloudFlare kode .
- 523 Origin Is Unreachable, opstår, når webserveren ikke er tilgængelig; brugerdefineret CloudFlare kode .
- 524 A Timeout Opstod, opstår, når forbindelsen timeout mellem CDN -serveren og webserveren. brugerdefineret CloudFlare kode .
- 525 SSL-håndtryk mislykkedes, opstår, når SSL - håndtrykket mellem CDN -serveren og webserveren fejler; brugerdefineret CloudFlare kode .
- 526 Ugyldigt SSL-certifikat, opstår når webserverens krypteringscertifikat ikke kan valideres; brugerdefineret CloudFlare kode .
Se også
Noter
- ↑ 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
- ↑ 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
- ↑ 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. (ubestemt)
- ↑ 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. (ubestemt)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.10 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 9. juli 2012. (ubestemt)
- ↑ rfc5842 . Hentet 12. september 2017. Arkiveret fra originalen 10. oktober 2017. (ubestemt)
- ↑ 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. (ubestemt)
- ↑ rfc7538 . Hentet 12. september 2017. Arkiveret fra originalen 16. april 2015. (ubestemt)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.4.3.1.1 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 9. juli 2012. (ubestemt)
- ↑ rfc7540 . Hentet 12. september 2017. Arkiveret fra originalen 23. juni 2015. (ubestemt)
- ↑ 1 2 3 4 RFC 6585
- ↑ 1 2 IETF udarbejder en ny HTTP-statuskode for at rapportere juridiske hindringer . Hentet 6. marts 2013. Arkiveret fra originalen 22. maj 2013. (ubestemt)
- ↑ RFC 2295 Transparent Content Negotiation i HTTP - S.8.1 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 8. juni 2012. (ubestemt)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.7.1 . Dato for adgang: 18. maj 2012. Arkiveret fra originalen 9. juli 2012. (ubestemt)
- ↑ 1 2 3 4 5 6 7 Fejlsider - CloudFlare Support . Hentet 18. april 2016. Arkiveret fra originalen 4. marts 2016. (ubestemt)
- ↑ RFC 2068 "10.3 Redirection 3xx" (s. 56) Arkiveret 7. juni 2018 på Wayback Machine .
- ↑ RFC 2616 , afsnit "10.3.3 302 fundet", side 63 Arkiveret 7. marts 2011 på Wayback Machine .
- ↑ Josh Cohen HTTP/1.1 305 og 306 svarkoder Arkiveret 8. september 2014 på Wayback Machine // Netscape Communications Corp., 25. december 1996
- ↑ Hvad betyder 403 Forbudt? Arkiveret 21. februar 2014 på Wayback Machine .
- ↑ Årsager til en 404 ikke fundet fejl Arkiveret 21. februar 2014 på Wayback Machine .
- ↑ RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) .
- ↑ draft-ietf-httpbis-legaly-restricted-status-04 . datatracker.ietf.org. Hentet 22. december 2015. Arkiveret fra originalen 23. december 2015. (ubestemt)
- ↑ Beskrivelse af 500 intern serverfejl arkiveret 21. februar 2014 på Wayback-maskinen .
- ↑ Ressourcegrænse nået . www.cloudlinux.com _ Hentet 21. juni 2022. Arkiveret fra originalen 15. maj 2021. (ubestemt)
Links
HTTP-kernedokumenter (faldende efter udgivelsesdato)
- Hypertext Transfer Protocol ( HTTP ) statuskoderegister . IANA (17. oktober 2007). - HTTP-statuskoderegistrering. Dato for adgang: 30. juli 2009. Arkiveret fra originalen den 17. februar 2012.
- RFC 2616 Udkast til standard " Hypertext Transfer Protocol - HTTP/1.1 " ( engelsk ) IETF , juni 1999; Fielding Roy ( UC Irvine), Gettys Jim ( Compaq / W3C ), Mogul J. ( Compaq ), Frystyk Henrik( MIT / W3C ), Masinter L. ( Xerox ), Leach P. ( Microsoft ), Berners-Lee Tim ( W3C / MIT ) - opdatering af HTTP-protokollen version 1.1.
- RFC 2068 Foreslået standard " Hypertext Transfer Protocol - HTTP/1.1 " (engelsk) (fra engelsk - "Hypertext Transfer Protocol - HTTP/1.1"); IETF , januar 1997; Fielding Roy ( UC Irvine), Gettys Jim ( DEC ), Mogul J. ( DEC ), Frystyk Henrik( MIT /LCS), Berners-Lee Tim ( MIT /LCS) er en tidlig specifikation for HTTP version 1.1.
- RFC 1945 informativ " Hypertext Transfer Protocol - HTTP / 1.0 " IETF , maj 1996; Berners-Lee Tim ( MIT /LCS), Fielding Roy ( UC Irvine), Frystyk Henrik( MIT /LCS) er den allerførste specifikation for HTTP-protokollen. Indeholder også en beskrivelse af HTTP/0.9.
Dokumenter om HTTP-protokoludvidelser og -opdateringer (faldende efter udgivelsesdato)
- RFC 4918 foreslåede standard " HTTP -udvidelser til webdistribueret forfatterskab og versionering ( WebDAV ) " IETF , juni 2007; Dusseault Ed. L. ( CommerceNet) er en sen specifikation for WebDAV-protokollen, der erstatter RFC 2518 .
- RFC 3229 Foreslået standard " Delta-kodning i HTTP " (engelsk) (fra engelsk - "Delta-kodning i HTTP"); IETF , januar 2002; Mogul J. ( Compaq WRL), Krishnamurthy B. ( AT&T ), Douglis F. ( AT&T ), Feldmann A. ( Univ. of Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA) .
- RFC 2817 foreslået standard " Opgradering til TLS inden for HTTP / 1.1 " IETF , maj 2000; Khare Rohit(4K Associates/ UC Irvine), Lawrence S. (Agranat Systems, Inc.) - opdatering til RFC 2616 for at beskrive, hvordan HTTP og TLS fungerer .
- RFC 2774 Experimental " An HTTP Extension Framework " (engelsk) (fra engelsk - "HTTP Extension Framework"); IETF , februar 2000; Nielsen H. ( Microsoft ), Leach P. ( Microsoft ), Lawrence S. (Agranat Systems) .
- Internet Draft " WebDAV Advanced Collections Protocol " (fra engelsk - "WebDAV Advanced Collections Protocol "); IETF , 18. juni 1999; Slein J. ( Xerox ), Whitehead Jr. EJ ( UC Irvine), Davis J. (CourseNet), Clemm G. ( Rational ), Fay C. ( FileNet), Crawford J. ( IBM ), Chihaya T. (DataChannel) - samlingsstyring i WebDAV; udløb 18. december 1999.
- RFC 2518 Proposed Standard " HTTP Extensions for Distributed Authoring - WEBDAV " IETF , februar 1999; Goland Y. ( Microsoft ), Whitehead E. ( UC Irvine), Faizi A. ( Netscape ), Carter S. ( Novell ), Jensen D. ( Novell ) - den første specifikation for WebDAV-protokollen (afløst af RFC 4918 ).
- RFC 2295 Eksperimentel Transparent Content Negotiation i HTTP IETF , marts 1998; Holtman K. (TUE), Mutz A. ( Hewlett-Packard ) .
Yderligere materialer
Web og hjemmesider |
---|
globalt |
|
---|
Lokalt |
|
---|
Typer af websteder og tjenester |
|
---|
Oprettelse og vedligeholdelse |
|
---|
Typer af layout, sider, websteder |
|
---|
Teknisk |
|
---|
Markedsføring |
|
---|
Samfund og kultur |
|
---|