| Http-statuskode | Statuskode Betydning |
|---|
| 100 | Klienten skal fortsætte med at sende anmodninger. Dette midlertidige svar bruges til at informere klienten om, at en del af dens anmodning er blevet modtaget af serveren og ikke er blevet afvist. Klienten skal fortsætte med at sende resten af anmodningen eller ignorere dette svar, hvis anmodningen er færdig. Serveren skal sende et endeligt svar til klienten, når anmodningen er færdig. |
| 101 | Serveren har forstået klientens anmodning og giver klienten besked via Upgrade-meddelelseshovedet om at bruge en anden protokol til at fuldføre anmodningen. Efter at have sendt den sidste tomme linje i dette svar, skifter serveren til de protokoller, der er defineret i Upgrade-meddelelseshovedet. Dette bør kun gøres, hvis det er mere fordelagtigt at skifte til en ny protokol. For eksempel er det mere fordelagtigt at skifte til en ny version af HTTP end en ældre version, eller at skifte til en realtids- og synkronprotokol for at levere ressourcer, der udnytter sådanne funktioner. |
| 102 | Statuskoder, udvidet af WebDAV (RFC 2518), repræsenterer, at behandlingen vil fortsætte. |
| 200 | Anmodningen har været vellykket, og den ønskede svarheader eller data body vil blive returneret med dette svar. |
| 201 | Anmodningen er blevet opfyldt, og en ny ressource er blevet oprettet som krævet af anmodningen, og dens URI er blevet returneret med Location-headeren. Hvis den krævede ressource ikke kan oprettes i tide, skal '202 Accepted' returneres. |
| 202 | Serveren har accepteret anmodningen, men har endnu ikke behandlet den. Ligesom den kan blive afvist, kan anmodningen i sidste ende blive udført eller ikke. I forbindelse med asynkrone operationer er der ikke noget mere praktisk end at sende denne statuskode. Formålet med at returnere et svar med en 202-statuskode er at give serveren mulighed for at acceptere anmodninger fra andre processer (f.eks. en batchbaseret operation, der kun udføres en gang om dagen) uden at skulle holde klienten forbundet med serveren, indtil batchoperationen er helt afsluttet. Et svar, der accepterer en anmodning om behandling og returnerer en 202-statuskode, BØR i den returnerede enhed indeholde nogle oplysninger, der angiver processens aktuelle tilstand, samt en pointer til en behandlingsstatusmonitor eller statusforudsigelse, så brugeren kan vurdere, om operationen er afsluttet. |
| 203 | Serveren har behandlet anmodningen med succes, men den returnerede metainformation i entitetshovedet er ikke et endeligt sæt, der er gyldigt på den oprindelige server, men en kopi fra en lokal eller tredje part. De aktuelle oplysninger kan være en delmængde eller en overmængde af den oprindelige version. For eksempel kan metadata, der indeholder ressourcer, få den oprindelige server til at kende meta-informationens super. Brug af denne statuskode er ikke påkrævet og er kun hensigtsmæssig, hvis svaret ville have returneret 200 OK uden den. |
| 204 | Serveren behandlede anmodningen med succes, men behøver ikke at returnere noget fysisk indhold og ønsker at returnere opdateret metainformation. Svaret kan returnere ny eller opdateret metainformation i form af entitetsoverskrifter. Hvis sådanne headere findes, skal de svare til de ønskede variabler. Hvis klienten er en browser, BØR brugerens browser beholde den side, som anmodningen blev sendt fra, uden ændringer i dokumentvisningen, selvom den nye eller opdaterede meta-information ifølge specifikationen BØR anvendes på dokumentet i den aktive visning i brugerens browser. Da 204-svaret ikke må indeholde nogen meddelelsestekst, slutter det altid med den første tomme linje efter meddelelseshovedet. |
| 205 | Serveren behandlede anmodningen med succes og returnerede intet. I modsætning til 204-svaret beder det svar, der returnerer denne statuskode, dog forespørgeren om at nulstille dokumentvisningen. Dette svar bruges primært til at nulstille formularen umiddelbart efter at have accepteret brugerinput, så brugeren nemt kan starte et nyt input. Ligesom 204-svaret må dette svar ikke indeholde nogen meddelelsestekst og slutter med den første tomme linje efter meddelelseshovedet. |
| 206 | Serveren har behandlet en del af GET-anmodningen med succes. HTTP-downloadværktøjer som FlashGet eller Thunderbolt bruger denne type svar til at udføre periodiske downloads eller til at opdele et stort dokument i flere downloadsegmenter på samme tid. Anmodningen skal indeholde en Range-header for at angive det område af indhold, som klienten ønsker at modtage, og kan indeholde en If-Range som en anmodningsbetingelse. Svaret skal indeholde følgende headerfelter: Content-Range for at angive omfanget af det indhold, der returneres i dette svar; i tilfælde af en download af flere segmenter med en Content-Type på multipart/byteranges skal hvert multipart-segment indeholde et Content-Range-felt, der angiver omfanget af indholdet i det pågældende segment. Hvis svaret indeholder en Content-Length, skal dens værdi matche det sande antal bytes i det indholdsområde, det returnerer. date ETag og/eller Content-Location, hvis den samme anmodning skulle have returneret et 200-svar. Expires, Cache-Control og/eller Vary, hvis deres værdier kan være forskellige fra andre svar med de samme variabler. Expires, Cache-Control og/eller Vary, hvis deres værdier kan være forskellige fra værdierne i andre tidligere svar for de samme variabler. Dette svar BØR IKKE indeholde andre entitetsoverskrifter, hvis anmodningen bruger If-Range stærk cache-validering, og BØR IKKE indeholde andre entitetsoverskrifter, hvis anmodningen bruger If-Range svag cache-validering; dette undgår uoverensstemmelser mellem cachelagret entitetsindhold og opdaterede entitetsoverskriftsoplysninger. Ellers BØR dette svar indeholde alle de entitetsoverskriftsfelter, der skulle have været returneret i alle de 200-svar, der skulle have været returneret. Hvis ETag- eller Last-Modified-overskrifterne ikke stemmer nøjagtigt overens, BØR cachen på klientsiden forbyde at kombinere det indhold, der returneres i svar 206, med noget tidligere cachelagret indhold. Enhver cache, der ikke understøtter Range- og Content-Range-overskrifterne, må ikke cachelagre det indhold, der returneres af 206-svaret. |
| 207 | Statuskoden, som udvidet af WebDAV (RFC 2518), betyder, at den efterfølgende meddelelsestekst vil være en XML-meddelelse og kan indeholde en række separate svarkoder, afhængigt af antallet af tidligere underforespørgsler. |
| 300 | Den ønskede ressource har en række alternative returmeddelelser, hver med sin egen specifikke adresse og browserdrevne forhandlingsoplysninger. Brugeren eller browseren kan selv vælge en foretrukken adresse til omdirigering. Medmindre der er tale om en HEAD-anmodning, skal svaret indeholde en enhed, der er en liste over ressourceegenskaber og adresser, hvorfra brugeren eller browseren kan vælge den mest passende omdirigeringsadresse. Formatet på denne entitet bestemmes af formatet på Content-Type-definitionen. Browseren kan automatisk foretage det mest hensigtsmæssige valg baseret på svarets format og browserens egne muligheder. RFC 2616-specifikationen specificerer selvfølgelig ikke, hvordan et sådant automatisk valg skal foretages. Hvis serveren selv allerede har et foretrukket valg af svar, skal URI'en for dette svar angives i Location; browseren kan bruge denne Location-værdi som adresse for automatisk omdirigering. Derudover kan dette svar også caches, medmindre andet er angivet. |
| 301 | Den ønskede ressource er blevet flyttet permanent til den nye placering, og alle fremtidige henvisninger til den skal bruge en af de mange URI'er, der returneres i dette svar. Hvis det er muligt, bør klienter med linkredigeringsfunktioner automatisk ændre den ønskede adresse til den, der returneres fra serveren. Dette svar kan også caches, medmindre andet er angivet. Den nye permanente URI bør returneres i svarets Location-felt. Medmindre dette er en HEAD-anmodning, bør svarentiteten indeholde et hyperlink til den nye URI og en kort beskrivelse. Hvis dette ikke er en GET- eller HEAD-anmodning, er det derfor forbudt for browseren at omdirigere automatisk, medmindre det bekræftes af brugeren, da vilkårene for anmodningen kan ændre sig som følge heraf. Bemærk: For nogle browsere, der bruger HTTP/1.0-protokollen, når de sender en POST-anmodning og får et 301-svar, vil den næste omdirigeringsanmodning være en GET. |
| 302 | Den anmodede ressource svarer nu midlertidigt på anmodningen fra en anden URI. Da denne omdirigering er midlertidig, bør klienten fortsætte med at sende fremtidige anmodninger til den oprindelige adresse. Dette svar kan kun caches, hvis det er specificeret i Cache-Control eller Expires. Den nye midlertidige URI skal returneres i svarets Location-felt. Medmindre dette er en HEAD-anmodning, skal svarentiteten indeholde et hyperlink til den nye URI og en kort beskrivelse. Hvis dette ikke er en GET- eller HEAD-anmodning, må browseren ikke automatisk omdirigere, medmindre det bekræftes af brugeren, da vilkårene for anmodningen kan ændre sig som følge heraf. Bemærk: Selvom RFC 1945- og RFC 2068-specifikationerne ikke tillader klienten at ændre metoden for anmodningen ved omdirigering, behandler mange eksisterende browsere 302-svaret som et 303-svar og bruger GET til at få adgang til den URI, der er angivet i placeringen, og ignorerer metoden for den oprindelige anmodning. Statuskoderne 303 og 307 er blevet tilføjet for at tydeliggøre, hvilket svar serveren forventer fra klienten. |
| 303 | Svaret på den aktuelle anmodning kan findes på en anden URI, og klienten bør få adgang til den ressource ved hjælp af GET. Denne metode findes primært for at gøre det muligt at omdirigere script-aktiverede POST-anmodninger til en ny ressource. Denne nye URI er ikke en alternativ reference til den oprindelige ressource. Desuden er det forbudt at cachelagre 303-svaret. Den anden anmodning (omdirigering) kan selvfølgelig caches. Den nye URI skal returneres i svarets Location-felt. Medmindre der er tale om en HEAD-anmodning, skal responsentiteten indeholde et hyperlink til den nye URI og en kort beskrivelse. Bemærk: Mange browsere før HTTP/1.1-versioner forstår ikke 303-tilstanden korrekt. Hvis interaktion med disse browsere skal overvejes, bør 302-statuskoden gøre tricket, da de fleste browsere håndterer 302-svaret på nøjagtig samme måde, som ovenstående specifikation kræver, at klienten håndterer 303-svaret. |
| 304 | Serveren BØR returnere denne statuskode, hvis klienten sender en betinget GET-anmodning, der er blevet tilladt, og indholdet af dokumentet (siden sidste besøg eller i henhold til betingelserne for anmodningen) ikke er ændret.304 Svar må ikke indeholde en meddelelsestekst og slutter derfor altid med den første tomme linje efter meddelelsesoverskriften. Svaret SKAL indeholde følgende overskrifter: Dato, medmindre serveren ikke har et ur. Hvis en server uden ur følger disse regler, kan proxyserveren og klienten selv tilføje Date-feltet til den indgående svarheader (som specificeret i RFC 2068), og caching-mekanismen vil fungere korrekt.ETag og/eller Content-Location, hvis den samme anmodning ville have returneret et 200-svar.Expires Expires, Cache-Control og/eller Vary, hvis værdien kan være forskellig fra den værdi, der svarer til andre tidligere svar for den samme variabel. Hvis denne svaranmodning bruger stærk cache-validering, bør dette svar ikke indeholde andre entitetsoverskrifter; ellers (f.eks. hvis en betinget GET-anmodning bruger svag cache-validering) er det forbudt for dette svar at indeholde andre entitetsoverskrifter; dette undgår uoverensstemmelser mellem cachelagret entitetsindhold og opdaterede entitetsoverskriftsoplysninger. Hvis et 304-svar angiver, at en entitet ikke er cachelagret i øjeblikket, skal cachesystemet ignorere svaret og gentage anmodningen uden begrænsningen. Hvis der modtages et 304-svar med anmodning om, at en cache-post opdateres, SKAL cachesystemet opdatere hele posten for at afspejle værdierne for alle felter, der er opdateret i svaret. |
| 305 | Den anmodede ressource skal tilgås via den angivne proxy. feltet Location giver oplysninger om den URI, hvor den angivne proxy er placeret. modtageren skal sende en separat anmodning gentagne gange for at få adgang til ressourcen via denne proxy. Kun den oprindelige server kan oprette et 305-svar. Bemærk: Det fremgår ikke klart af RFC 2068, at et 305-svar er beregnet til at omdirigere en enkelt anmodning og kun kan oprettes af den oprindelige server. Hvis man ignorerer disse begrænsninger, kan det få alvorlige konsekvenser for sikkerheden. |
| 306 | I den seneste version af specifikationen bruges statuskode 306 ikke længere. |
| 307 | Den anmodede ressource svarer nu midlertidigt på anmodningen fra en anden URI. Da sådanne omdirigeringer er midlertidige, bør klienter fortsætte med at sende fremtidige anmodninger til den oprindelige adresse. Dette svar kan kun caches, hvis det er specificeret i Cache-Control eller Expires. Den nye midlertidige URI skal returneres i svarets Location-felt. Medmindre der er tale om en HEAD-anmodning, skal svarentiteten indeholde et hyperlink til den nye URI og en kort beskrivelse. Da nogle browsere ikke genkender 307-svaret, skal ovenstående oplysninger tilføjes, så brugeren kan forstå og anmode om adgang til den nye URI. Hvis dette ikke er en GET- eller HEAD-anmodning, forbyder browseren automatisk omdirigering, medmindre det bekræftes af brugeren, fordi betingelserne for anmodningen kan ændre sig. |
| 400 | 1. Der er en semantisk fejl, og den aktuelle anmodning kan ikke forstås af serveren. Medmindre den er ændret, bør klienten ikke sende denne anmodning gentagne gange. 2. Anmodningsparametrene er forkerte. |
| 401 | Den aktuelle anmodning kræver brugergodkendelse. Svaret skal indeholde en WWW-Authenticate-header for den anmodede ressource for at bede om brugeroplysninger. Klienten kan gentagne gange sende en anmodning, der indeholder de relevante Authorisation-header-oplysninger. Hvis den aktuelle anmodning allerede indeholder autorisationsoplysninger, betyder 401-svaret, at serveren kontrollerer, at disse oplysninger er blevet afvist. Hvis 401-svaret indeholder den samme godkendelsesforespørgsel som det forrige svar, og browseren allerede har forsøgt at godkende mindst én gang, BØR browseren præsentere brugeren for de enhedsoplysninger, der er indeholdt i svaret, da disse enhedsoplysninger kan indeholde relevante diagnostiske oplysninger. Se RFC 2617. |
| 402 | Denne statuskode er reserveret til mulige fremtidige krav. |
| 403 | Serveren har forstået anmodningen, men nægter at udføre den. I modsætning til et 401-svar giver autentificering ingen hjælp, og denne anmodning bør ikke indsendes igen. Hvis dette ikke er en HEAD-anmodning, og serveren ønsker at kunne tale klart om, hvorfor anmodningen ikke kan udføres, bør årsagen til afvisningen beskrives i entiteten. Serveren kan selvfølgelig også returnere et 404-svar, hvis den ikke ønsker at give klienten nogen oplysninger. |
| 404 | Anmodningen mislykkedes, den ønskede ressource blev ikke fundet på serveren. Der er ingen oplysninger, der kan fortælle brugeren, om situationen er midlertidig eller permanent. Hvis serveren er klar over situationen, bør den bruge statuskoden 410 til at informere brugeren om, at den gamle ressource er permanent utilgængelig på grund af en intern konfigurationsmekanisme, og at der ikke er nogen tilgængelig omdirigering. 404 bruges i vid udstrækning, når serveren ikke ønsker at afsløre, hvorfor anmodningen blev afvist, eller når der ikke er noget andet passende svar til rådighed. |
| 405 | Den anmodningsmetode, der er angivet i anmodningslinjen, kan ikke bruges til at anmode om den tilsvarende ressource. Svaret skal returnere en Allow-header, der angiver listen over anmodningsmetoder, der er acceptable for den aktuelle ressource. Da PUT- og DELETE-metoderne skriver til ressourcen på serveren, understøtter de fleste webservere ikke disse anmodningsmetoder eller tillader dem ikke som standard og vil returnere en 405-fejl for sådanne anmodninger. |
| 406 | Indholdsegenskaberne for den anmodede ressource opfylder ikke betingelserne i anmodningens header, og der kan ikke genereres en svarenhed. Medmindre der er tale om en HEAD-anmodning, skal svaret returnere en entitet, der indeholder en liste over entitetsegenskaber og adresser, hvorfra brugeren eller browseren kan vælge den mest passende. Entitetens format bestemmes af den medietype, der er defineret i Content-Type-headeren. Browsere kan træffe deres egne bedste valg baseret på formatet og deres egne muligheder. Men specifikationen definerer ikke nogen kriterier for at foretage sådanne automatiske valg. |
| 407 | Svarer til 401-svaret, bortset fra at klienten SKAL autentificere sig på proxyserveren. Proxyserveren SKAL returnere en Proxy-Authenticate til identitetsafhøring. Klienten KAN returnere en Proxy-Authorization header til autentificering. Se RFC 2617. |
| 408 | Timeout for anmodning. Klienten blev ikke færdig med at sende en anmodning inden for den tid, serveren var parat til at vente. Klienten kan til enhver tid sende anmodningen igen uden at foretage ændringer. |
| 409 | Anmodningen kunne ikke gennemføres på grund af en konflikt med den anmodede ressources aktuelle tilstand. Denne kode må kun bruges, hvis brugeren anses for at være i stand til at løse konflikten og sende en ny anmodning. Svaret bør indeholde tilstrækkelig information til, at brugeren kan finde kilden til konflikten. Konflikter opstår typisk i behandlingen af PUT-anmodninger. Hvis f.eks. versionsoplysningerne, der er knyttet til en PUT-anmodning om at ændre en bestemt ressource, er i konflikt med en tidligere (tredjeparts) anmodning, bør serveren i et versionskontrolmiljø returnere en 409-fejl, der informerer brugeren om, at anmodningen ikke kunne gennemføres. I dette tilfælde vil svarenheden sandsynligvis indeholde en sammenligning af forskellene mellem de to modstridende versioner, så brugeren kan indsende den nye version igen efter sammenlægningen. |
| 410 | Den ønskede ressource er ikke længere tilgængelig på serveren og har ikke nogen kendt videresendelsesadresse. En sådan tilstand bør betragtes som permanent. Hvis det er muligt, bør klienter med linkredigeringsfunktioner fjerne alle referencer til denne adresse med brugerens tilladelse. Hvis serveren ikke ved eller ikke kan afgøre, om denne tilstand er permanent, skal der bruges en 404-statuskode. Medmindre andet er angivet, kan dette svar caches.410 Formålet med svaret er primært at hjælpe webmasteren med at vedligeholde webstedet ved at informere brugeren om, at ressourcen ikke længere er tilgængelig, og at serverejeren ønsker, at alle fjernforbindelser til denne ressource også skal fjernes. Denne type hændelse er almindelig i tidsbegrænsede tjenester med merværdi. På samme måde bruges 410-svaret til at underrette klienter om, at en ressource, der oprindeligt tilhørte en person på den aktuelle serverside, ikke længere er tilgængelig. Det er selvfølgelig helt op til serverejeren, om alle permanent utilgængelige ressourcer skal markeres som "410 Gone", og hvor længe denne markering skal opretholdes. |
| 411 | Serveren nægter at acceptere anmodninger uden en defineret Content-Length header. Efter at have tilføjet en gyldig Content-Length-header, der angiver længden af anmodningens meddelelsestekst, kan klienten indsende anmodningen igen. |
| 412 | Serveren kunne ikke opfylde en eller flere af forudsætningerne, da den kontrollerede, at de var angivet i anmodningens headerfelt. Denne statuskode gør det muligt for klienten at angive forudsætninger i anmodningens metameddelelse (data i anmodningens headerfelt), når der hentes en ressource, og dermed forhindre, at anmodningsmetoden anvendes på andre ressourcer end det indhold, den ønsker. |
| 413 | Serveren nægter at behandle den aktuelle anmodning, fordi den sender enhedsdata af en størrelse, der er større, end serveren er villig til eller i stand til at håndtere. I dette tilfælde kan serveren lukke forbindelsen for at forhindre klienten i at fortsætte med at sende denne anmodning. Hvis denne tilstand er midlertidig, bør serveren returnere en Retry-After-svarheader for at informere klienten om, hvor lang tid den kan prøve igen. |
| 414 | Længden af anmodningens URI overskrider den længde, som serveren kan fortolke, så serveren nægter at betjene anmodningen. Dette sker sjældent og er ofte tilfældet, når en formular, der skulle have brugt POST-metoden, bliver til en GET-metode, hvilket resulterer i en lang forespørgselsstreng. Redirect URI "sorte huller", som f.eks. at bruge den gamle URI som en del af den nye URI ved hver redirect, hvilket resulterer i en lang URI efter flere redirects. Klienter forsøger at angribe servere ved at udnytte sikkerhedshuller, der findes i nogle servere. Sådanne servere bruger en buffer med fast længde til at læse eller manipulere URI'en i en anmodning, og når parametrene efter en GET overstiger en bestemt værdi, kan der opstå et bufferoverløb, som fører til udførelse af vilkårlig kode [1]. Servere uden sådanne sårbarheder bør returnere en 414-statuskode. |
| 415 | For den aktuelt anmodede metode og den anmodede ressource er den enhed, der er indsendt i anmodningen, ikke i et format, der understøttes af serveren, så anmodningen afvises. |
| 416 | Hvis anmodningen indeholder en Range-anmodningsheader, og eventuelle dataområder, der er angivet i Range, ikke overlapper med de områder, der er tilgængelige for den aktuelle ressource, og If-Range-anmodningsheaderen ikke er defineret i anmodningen, skal serveren returnere en 416-statuskode. Hvis Range bruger byte-intervaller, er dette tilfældet, hvis den første byte-position i alle de data-intervaller, der er angivet i anmodningen, overstiger længden af den aktuelle ressource. Serveren skal også inkludere en Content-Range entity header, der specificerer længden af den aktuelle ressource sammen med 416-statuskoden. Dette svar må heller ikke bruge multipart/byteranges som Content-Type. |
| 417 | Det forventede indhold, der er angivet i request-headeren Expect, kan ikke opfyldes af serveren, eller denne server er en proxyserver, der har klare beviser for, at indholdet af Expect ikke kan opfyldes på den næste node i den aktuelle rute. |
| 421 | Antallet af forbindelser til serveren fra den IP-adresse, hvor den aktuelle klient befinder sig, overskrider det maksimalt tilladte for serveren. IP-adressen refererer her typisk til klientens adresse set fra serveren (f.eks. brugerens gateway- eller proxyserveradresse). I dette tilfælde kan antallet af forbindelser involvere mere end én slutbruger. |
| 422 | Antallet af forbindelser til serveren fra den aktuelle klients IP-adresse overskrider det maksimum, som serveren tillader. IP-adressen refererer her typisk til klientens adresse set fra serveren (f.eks. brugerens gateway- eller proxyserveradresse). I dette tilfælde kan antallet af forbindelser involvere mere end én slutbruger. |
| 422 | Anmodningen var formateret korrekt, men kunne ikke besvares, fordi den indeholdt semantiske fejl. (RFC 4918 WebDAV) 423 Locked Den aktuelle ressource er låst. (RFC 4918 WebDAV) |
| 424 | Den aktuelle anmodning mislykkedes på grund af en fejl, der opstod i en tidligere anmodning, såsom PROPPATCH.(RFC 4918 WebDAV) |
| 425 | Defineret i udkastet til WebDav Advanced Collections, men optræder ikke i WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Klienter bør skifte til TLS/1.0.(RFC 2817) |
| 449 | Udvidet af Microsoft til at repræsentere, at anmodninger skal forsøges igen, når den relevante handling er blevet udført. |
| 500 | Serveren stødte på en uforudset tilstand, der forhindrede den i at færdiggøre behandlingen af anmodningen. Dette problem opstår typisk, når der er en fejl i serverens programkode. |
| 501 | Serveren understøtter ikke en bestemt funktion, som er nødvendig for den aktuelle anmodning. Når serveren ikke kan genkende den ønskede metode og ikke er i stand til at understøtte dens anmodning om en hvilken som helst ressource. |
| 502 | En server, der fungerer som gateway eller proxy, modtager et ugyldigt svar fra en upstream-server, når den forsøger at udføre en anmodning. |
| 503 | Serveren er i øjeblikket ikke i stand til at behandle anmodningen på grund af midlertidig servervedligeholdelse eller overbelastning. Denne tilstand er midlertidig og vil blive genoprettet efter et stykke tid. Hvis der kan forventes en forsinkelse, kan svaret indeholde en Retry-After-header for at angive forsinkelsen. Hvis denne Retry-After-information ikke gives, skal klienten håndtere det på samme måde som et 500-svar. Bemærk: Eksistensen af 503-statuskoden betyder ikke, at serveren skal bruge den, hvis den er overbelastet. Nogle servere ønsker blot at nægte klienten en forbindelse. |
| 504 | En server, der fungerer som gateway eller proxy, og som forsøger at udføre en anmodning, modtager ikke et rettidigt svar fra en upstream-server (en server, der er identificeret af en URI, f.eks. HTTP, FTP, LDAP) eller en sekundær server (f.eks. DNS). Bemærk: Nogle proxyservere returnerer en 400- eller 500-fejl, når DNS-opslaget går i stå. |
| 505 | Serveren understøtter ikke, eller nægter at understøtte, den version af HTTP, der bruges i anmodningen. Det betyder, at serveren ikke kan eller vil bruge den samme version som klienten. Svaret skal indeholde en enhed, der beskriver, hvorfor versionen ikke understøttes, og hvilke protokoller serveren understøtter. |
| 506 | Udvidet af Transparent Content Negotiation Protocol (RFC 2295) til at repræsentere en intern fejlkonfiguration fra serverens side: Den anmodede Negotiation Variant-ressource er konfigureret til at bruge sig selv i gennemsigtig indholdsforhandling og er derfor ikke et passende fokus i en forhandlingsproces. |
| 507 | Serveren kan ikke gemme det indhold, der er nødvendigt for at fuldføre anmodningen. Denne tilstand betragtes som midlertidig.WebDAV (RFC 4918) |
| 509 | Serveren har nået sin båndbreddegrænse. Dette er ikke en officiel statuskode, men bruges stadig i vid udstrækning. |
| 510 | Den politik, der kræves for at opnå ressourcen, var ikke uopfyldt. (RFC 2774) |