HTTP-statuskoden er en tresifret kode som returneres av serveren som svar på en forespørsel, og som brukes til å identifisere resultatet av forespørselen. Dette verktøyet gir en standardisert klassifisering og scenarietolkning som passer for utviklere, drifts- og vedlikeholdspersonell og personer som lærer om nettverksteknologi.
Alle forklaringer er basert på RFC-standarddokumentet, slik at man unngår regionale forskjeller i uttrykk og sikrer at brukere over hele verden forstår det samme.
| Http-statuskoder | Statuskode Betydning |
|---|---|
| 100 | Klienten skal fortsette å sende forespørsler. Dette midlertidige svaret brukes til å informere klienten om at en del av forespørselen er mottatt av serveren og ikke har blitt avvist. Klienten bør fortsette å sende resten av forespørselen, eller ignorere dette svaret hvis forespørselen er fullført. Serveren må sende et siste svar til klienten når forespørselen er fullført. |
| 101 | Serveren har forstått klientens forespørsel og vil varsle klienten via Upgrade-overskriften om at en annen protokoll ble brukt for å fullføre forespørselen. Etter at den siste tomme linjen i svaret er sendt, bytter serveren til protokollen som er definert i Upgrade-headeren. Dette bør bare gjøres hvis det er mer fordelaktig å bytte til den nye protokollen. Det kan for eksempel være mer fordelaktig å bytte til en ny versjon av HTTP enn en eldre versjon, eller å bytte til en synkron sanntidsprotokoll for å levere ressurser som utnytter slike funksjoner. |
| 102 | Statuskoder, utvidet av WebDAV (RFC 2518), indikerer at behandlingen vil fortsette. |
| 200 | Forespørselen var vellykket, og svaroverskriftene eller datahelheten som forespørselen ønsket, vil bli returnert sammen med svaret. |
| 201 | Forespørselen er oppfylt, og en ny ressurs er opprettet som svar på forespørselen, og dens URI er returnert med Location-headeren. Hvis den forespurte ressursen ikke kan opprettes i tide, returneres følgende'202 Accepted'。 |
| 202 | Serveren har akseptert forespørselen, men har ennå ikke behandlet den. På samme måte som den kan bli avvist, er det ikke sikkert at forespørselen blir utført til slutt. Når det gjelder asynkrone operasjoner, finnes det ikke noe mer praktisk enn å sende denne statuskoden. Hensikten med å returnere et 202-svar er at serveren skal kunne godta forespørsler fra andre prosesser (for eksempel en batchbasert operasjon som bare utføres én gang om dagen) uten at klienten trenger å opprettholde en forbindelse til serveren før batchoperasjonen er fullført. Et svar som aksepterer en forespørsel om behandling og returnerer en 202-statuskode, bør inneholde informasjon om prosessens nåværende status, samt en peker til en statusmonitor eller statusprediksjon, slik at brukeren kan anslå om operasjonen er fullført eller ikke. |
| 203 | Serveren har behandlet forespørselen, men den returnerte metainformasjonen i entitetshodet er ikke et endelig sett som er gyldig på den opprinnelige serveren, men en kopi fra en lokal eller tredje part. Den aktuelle informasjonen kan være en delmengde eller et supersett av originalen. For eksempel kan metadata som inneholder ressurser, føre til at opprinnelsesserveren kjenner meta-informasjonen super. Bruk av denne statuskoden er ikke påkrevd og er bare hensiktsmessig hvis svaret ville ha returnert 200 OK uten den. |
| 204 | Serveren behandlet forespørselen, men trenger ikke å returnere noe fysisk innhold og ønsker å returnere oppdatert metainformasjon. Svaret kan returnere ny eller oppdatert metainformasjon i form av entitetshoder. Hvis disse overskriftene finnes, skal de tilsvare de forespurte variablene. Hvis klienten er en nettleser, BØR brukerens nettleser beholde siden som forespørselen ble sendt fra, uten noen endringer i dokumentvisningen, selv om den nye eller oppdaterte metainformasjonen i henhold til spesifikasjonen BØR brukes på dokumentet i den aktive visningen i brukerens nettleser. Siden 204-svaret ikke kan inneholde noen meldingstekst, slutter det alltid med den første tomme linjen etter meldingshodet. |
| 205 | Serveren håndterer forespørselen og returnerer ingenting. I motsetning til 204-svaret ber imidlertid svaret som returnerer denne statuskoden, spørreren om å tilbakestille dokumentvisningen. Dette svaret brukes først og fremst til å tilbakestille skjemaet umiddelbart etter at brukeren har lagt inn noe, slik at brukeren enkelt kan starte en ny innlegging. I likhet med 204-svaret inneholder dette svaret ingen meldingstekst, og det avsluttes med den første tomme linjen etter meldingshodet. |
| 206 | Serveren har behandlet en del av GET-forespørselen. HTTP-nedlastingsverktøy som FlashGet eller Thunderbolt bruker denne typen svar for å utføre periodiske nedlastinger eller for å dele opp en stor fil i flere nedlastinger samtidig. Forespørselen må inneholde et Range-overskriftsord for å angi hvilket område av innhold klienten ønsker å motta, og kan inneholde en If-Range som en forespørselsbetingelse. Svaret må inneholde følgende overskriftsfelt: Content-Range for å angi omfanget av innholdet som returneres i dette svaret, eller, i tilfelle nedlastinger i flere deler med en Content-Type av multipart/byteranges, et Content-Range-felt i hvert multipart-segment for å angi omfanget av innholdet i det segmentet. Hvis svaret inneholder en Content-Length, må verdien stemme overens med det sanne antallet byte i det returnerte innholdsområdet. Expires, Cache-Control og/eller Vary, hvis verdiene kan være forskjellige fra verdiene i andre tidligere svar med de samme variablene. Dette svaret bør ikke inneholde andre entitetshoder hvis forespørselen bruker sterk If-Range-buffervalidering, og bør ikke inneholde andre entitetshoder hvis forespørselen bruker svak If-Range-buffervalidering; på denne måten unngår man uoverensstemmelser mellom innholdet i bufret entitet og den oppdaterte informasjonen i entitetshodene. Ellers BØR dette svaret inneholde alle entitetshodefeltene som skulle ha vært returnert i 200-svaret. Hvis ETag- eller Last-Modified-overskriftene ikke stemmer nøyaktig overens, bør hurtigbufferen på klientsiden ikke tillate at innholdet som returneres i svar 206, kombineres med tidligere hurtigbufret innhold. Enhver hurtigbuffer som ikke støtter Range- og Content-Range-overskriftene, kan ikke bufre innholdet som returneres i 206-svaret. |
| 207 | Statuskoder utvidet av WebDAV(RFC 2518) Statuskoden, som utvidet av WebDAV, betyr at den påfølgende meldingsteksten vil være en XML-melding og kan inneholde en rekke separate svarkoder, avhengig av antall tidligere underforespørsler. |
| 300 | Den forespurte ressursen har en rekke alternative svar, hvert med sin egen spesifikke adresse og nettleserstyrt forhandlingsinformasjon. Det er opp til brukeren eller nettleseren å velge en foretrukket adresse for omdirigering. Med mindre dette er en HEAD-forespørsel, bør svaret inneholde en entitet som er en liste over ressurskarakteristikker og adresser som brukeren eller nettleseren kan velge den mest hensiktsmessige omdirigeringsadressen fra. Formatet på denne entiteten bestemmes av formatet på Content-Type-definisjonen. Nettleseren kan automatisk velge den mest hensiktsmessige adressen basert på formatet på svaret og nettleserens egne evner. RFC 2616-spesifikasjonen spesifiserer selvfølgelig ikke hvordan dette automatiske valget skal gjøres. Hvis serveren selv allerede har et foretrukket returalternativ, bør URI-en for returen angis i Location; nettlesere kan bruke denne Location-verdien som adresse for automatisk omdirigering. I tillegg kan svaret bufres med mindre annet er spesifisert. |
| 301 | Den forespurte ressursen er permanent flyttet til den nye plasseringen, og alle fremtidige referanser til den bør bruke en av de ulike URI-ene som returneres i dette svaret. Hvis det er mulig, bør klienter med lenkeredigeringsfunksjoner automatisk endre den forespurte adressen til den som returneres fra serveren. Dette svaret kan også lagres i hurtigbufferen med mindre annet er spesifisert. Den nye permanente URI-en skal returneres i Location-feltet i svaret. Med mindre dette er en HEAD-forespørsel, skal svarenheten inneholde en hyperkobling til den nye URI-en og en kort beskrivelse. Hvis dette ikke er en GET- eller HEAD-forespørsel, er det forbudt for nettleseren å omdirigere automatisk med mindre brukeren har bekreftet det, ettersom vilkårene for forespørselen kan endres som følge av dette. Merk: For noen nettlesere som bruker HTTP/1.0-protokollen, vil den neste omdirigeringsforespørselen være GET når de sender en POST-forespørsel og får et 301-svar. |
| 302 | Den forespurte ressursen svarer nå midlertidig på forespørselen fra en annen URI. Siden denne omdirigeringen er midlertidig, bør klienten fortsette å sende fremtidige forespørsler til den opprinnelige adressen. Svaret kan bare lagres i hurtigbuffer hvis det er angitt i Cache-Control eller Expires. Den nye midlertidige URI-en skal returneres i Location-feltet i svaret. Med mindre dette er en HEAD-forespørsel, skal svarenheten inneholde en hyperkobling til den nye URI-en og en kort beskrivelse. Hvis dette ikke er en GET- eller HEAD-forespørsel, er det forbudt for nettleseren å omdirigere automatisk med mindre brukeren bekrefter det, ettersom vilkårene for forespørselen kan endres som et resultat av dette. Merk: Selv om RFC 1945- og RFC 2068-spesifikasjonene ikke tillater klienten å endre metoden for forespørselen under omdirigering, behandler mange eksisterende nettlesere 302-svaret som et 303-svar og bruker GET for å få tilgang til URI-en som er angitt i Location, uten å ta hensyn til metoden i den opprinnelige forespørselen. Statuskodene 303 og 307 er lagt til for å tydeliggjøre hvilket svar serveren forventer fra klienten. |
| 303 | Svaret på den aktuelle forespørselen finnes på en annen URI, og klienten bør få tilgang til den ressursen ved hjelp av GET. Denne metoden finnes først og fremst for å gjøre det mulig å omdirigere skriptaktiverte POST-forespørsler til en ny ressurs. Denne nye URI-en er ikke en erstatningsreferanse til den opprinnelige ressursen. Det er heller ikke tillatt å bufre 303-svaret. Den andre forespørselen (omdirigering) kan selvfølgelig bufres. Den nye URI-en skal returneres i Location-feltet i svaret. Med mindre dette er en HEAD-forespørsel, bør responsentiteten inneholde en hyperkobling til den nye URI-en og en kort beskrivelse. Merk: Mange nettlesere før HTTP/1.1 forstår ikke 303-status på riktig måte. Hvis interaksjon med disse nettleserne må vurderes, bør 302-statuskoden fungere, siden de fleste nettlesere håndterer 302-svaret på nøyaktig samme måte som spesifikasjonen ovenfor krever at klienten skal håndtere 303-svaret. |
| 304 | Denne statuskoden skal returneres av serveren hvis klienten sender en betinget GET-forespørsel og forespørselen er tillatt, og innholdet i dokumentet ikke er endret (enten siden forrige besøk eller i henhold til vilkårene for forespørselen). 304-svar er forbudt å inneholde en meldingstekst, og avsluttes derfor alltid med den første tomme linjen etter meldingens overskrift. Svaret må inneholde følgende header-informasjon: Dato, med mindre serveren ikke har en klokke. Hvis serveren ikke har en klokke, følger proxy-serveren og klienten disse reglene og kan selv legge til Date-feltet i det innkommende svarhodet (som spesifisert i RFC 2068), og caching-mekanismen vil fungere som den skal.ETag og/eller Content-Location, hvis den samme forespørselen skulle ha returnert et 200-svar. Expires, Cache-Control og/eller Vary, hvis verdiene kan være forskjellige fra verdiene i andre tidligere svar med de samme variablene. Hvis svarforespørselen bruker sterk cache-validering, skal svaret ikke inneholde flere entitetsoverskrifter; i motsatt fall (f.eks. hvis en betinget GET-forespørsel bruker svak cache-validering), er det forbudt for svaret å inneholde flere entitetsoverskrifter; på denne måten unngår man uoverensstemmelser mellom bufret entitetsinnhold og oppdatert informasjon om entitetsoverskrifter. Hvis et 304-svar indikerer at en entitet ikke er bufret for øyeblikket, må bufringssystemet ignorere svaret og gjenta forespørselen uten begrensningen. Hvis det mottas et 304-svar som ber om at en cache-oppføring oppdateres, MÅ bufringssystemet oppdatere hele oppføringen slik at den gjenspeiler verdiene i alle feltene som oppdateres i svaret. |
| 305 | Den forespurte ressursen må nås via en spesifisert proxy. Feltet Location vil gi informasjon om URI-en til den spesifiserte proxyen, og mottakeren må sende en separat forespørsel gjentatte ganger for å få tilgang til ressursen via denne proxyen. Bare den opprinnelige serveren kan opprette et 305-svar. Merk: Det fremgår ikke klart av RFC 2068 at et 305-svar er ment å omdirigere en enkelt forespørsel, og at det bare kan opprettes av den opprinnelige serveren. Hvis disse begrensningene ignoreres, kan det få alvorlige sikkerhetsmessige konsekvenser. |
| 306 | I den nyeste versjonen av spesifikasjonen brukes ikke statuskoden 306 lenger. |
| 307 | Forespurte ressurser svarer nå midlertidig på forespørsler fra forskjellige URI-er. Siden denne omdirigeringen er midlertidig, bør klienter fortsette å sende fremtidige forespørsler til den opprinnelige adressen. Dette svaret kan bare lagres i hurtigbuffer hvis det er spesifisert i Cache-Control eller Expires. Den nye midlertidige URI-en skal returneres i Location-feltet i svaret. Med mindre dette er en HEAD-forespørsel, bør svaret inneholde en hyperkobling til den nye URI-en og en kort beskrivelse. Fordi noen nettlesere ikke gjenkjenner 307-svaret, er det nødvendig å legge til informasjonen ovenfor slik at brukeren kan forstå og be om tilgang til den nye URI-en. Hvis dette ikke er en GET- eller HEAD-forespørsel, forbyr nettleseren automatisk omdirigering, med mindre brukeren har bekreftet det, fordi vilkårene for forespørselen kan endres. |
| 400 | 1, semantisk feil, den aktuelle forespørselen kan ikke forstås av serveren. Med mindre den er endret, skal klienten ikke gjenta forespørselen. 2, forespørselsparametrene er feil. |
| 401 | Den aktuelle forespørselen krever brukerautentisering. Svaret må inneholde et WWW-Authenticate-hode for den forespurte ressursen for å be om brukerinformasjon. Klienten kan sende en ny forespørsel med riktig informasjon i Authorisation-headeren. Hvis den aktuelle forespørselen allerede inneholder autorisasjonsopplysninger, betyr et 401-svar at serveren bekrefter at disse opplysningene er avvist. Hvis 401-svaret inneholder samme autentiseringsforespørsel som det forrige svaret, og nettleseren allerede har gjort minst ett forsøk på autentisering, bør nettleseren vise brukeren entitetsinformasjonen i svaret, siden denne entitetsinformasjonen kan inneholde relevant diagnostisk informasjon. Se RFC 2617. |
| 402 | Denne statuskoden er reservert for mulige fremtidige krav. |
| 403 | Serveren har forstått forespørselen, men nekter å utføre den. I motsetning til et 401-svar gir ikke autentisering noen hjelp, og forespørselen bør ikke sendes på nytt. Hvis dette ikke er en HEAD-forespørsel, og serveren ønsker å kunne si hvorfor forespørselen ikke kan utføres, bør årsaken til avslaget beskrives i entiteten. Serveren kan selvfølgelig også returnere et 404-svar hvis den ikke ønsker at klienten skal få noen informasjon. |
| 404 | Forespørselen mislyktes, den forespurte ressursen ble ikke funnet på serveren. Det finnes ingen informasjon som kan fortelle brukeren om situasjonen er midlertidig eller permanent. Hvis serveren er klar over situasjonen, bør den bruke statuskoden 410 for å informere serveren om at den gamle ressursen er permanent utilgjengelig på grunn av en intern konfigurasjonsmekanisme, og at det ikke er mulig å omdirigere den. 404 brukes ofte når serveren ikke ønsker å opplyse om hvorfor forespørselen ble avvist, eller når det ikke finnes noe annet passende svar. |
| 405 | Forespørselsmetoden som er angitt i forespørselslinjen, kan ikke brukes til å be om den tilsvarende ressursen. Svaret må returnere et Allow-hode som angir listen over forespørselsmetoder som er akseptable for den aktuelle ressursen. Siden PUT- og DELETE-metodene skriver til ressursen på serveren, støtter eller tillater de fleste webservere dem ikke som standard og vil returnere en 405-feil for slike forespørsler. |
| 406 | Innholdsegenskapene til den forespurte ressursen oppfyller ikke betingelsene i forespørselshodet, og det kan ikke genereres en responsenhet. Med mindre dette er en HEAD-forespørsel, skal svaret returnere en entitet som inneholder de mest passende entitetsegenskapene og en liste over adresser som brukeren eller nettleseren kan velge mellom. Formatet på entiteten bestemmes av medietypen som er definert i Content-Type-overskriften. Nettleseren kan gjøre det beste valget basert på formatet og sine egne evner. Spesifikasjonen definerer imidlertid ingen kriterier for å gjøre slike automatiske valg. |
| 407 | Ligner på 401-svaret, bortsett fra at klienten må autentisere seg hos proxy-serveren. Proxy-serveren MÅ returnere en Proxy-Authenticate for identitetsavhør. Klienten kan returnere et Proxy-Authorisation-hode for autentisering. Se RFC 2617. |
| 408 | Tidsavbrudd for forespørsel. Klienten fullførte ikke en forespørsel innen den tiden serveren var forberedt på å vente. Klienten kan sende forespørselen på nytt når som helst uten å gjøre noen endringer. |
| 409 | Forespørselen kunne ikke fullføres på grunn av en konflikt med gjeldende status for den forespurte ressursen. Denne koden kan bare brukes hvis brukeren anses å være i stand til å løse konflikten og sende inn en ny forespørsel. Svaret skal inneholde nok informasjon til at brukeren kan finne kilden til konflikten. Konflikter oppstår ofte i behandlingen av PUT-forespørsler. I et versjonskontrollmiljø kan for eksempel en PUT-forespørsel som sendes inn for å endre en bestemt ressurs med versjonsinformasjon som er i konflikt med en tidligere (tredjeparts) forespørsel, returnere en 409-feil som informerer brukeren om at forespørselen ikke kunne fullføres. I dette tilfellet vil responsentiteten sannsynligvis inneholde en sammenligning av forskjellene mellom de to motstridende versjonene, slik at brukeren kan sende inn den nye, sammenslåtte versjonen på nytt. |
| 410 | Den forespurte ressursen er ikke lenger tilgjengelig på serveren, og det finnes ingen kjent videresendingsadresse. En slik situasjon bør betraktes som permanent. Hvis det er mulig, bør klienter med lenkeredigeringsfunksjoner fjerne alle referanser til denne adressen med brukerens tillatelse. Hvis serveren ikke vet eller ikke kan avgjøre om tilstanden er permanent, bør en 404-statuskode brukes. Med mindre annet er spesifisert, kan dette svaret lagres i hurtigbufferen. 410-svaret har først og fremst til hensikt å hjelpe nettredaktøren med å vedlikeholde nettstedet ved å informere brukeren om at ressursen ikke lenger er tilgjengelig, og at serverens eier ønsker at alle eksterne tilkoblinger til ressursen også skal slettes. Denne typen hendelser er vanlige i tidsbegrensede, verdiøkende tjenester. På samme måte brukes 410-svaret til å varsle klienten om at en ressurs som tilhører en person, ikke lenger er tilgjengelig på det aktuelle serverområdet. Spørsmålet om hvorvidt alle ressurser som er permanent utilgjengelige, må merkes som det, og hvor lenge de skal være det, er selvsagt også viktig.'410 Gone'， Det er helt opp til serverens eier å bestemme hvor lenge den skal opprettholdes. |
| 411 | Serveren nekter å godta forespørsler uten at Content-Length-overskriften er definert. Klienten kan sende forespørselen på nytt etter å ha lagt til et gyldig Content-Length-overskriftsnavn som angir lengden på meldingsteksten. |
| 412 | Serveren klarte ikke å oppfylle en eller flere av forutsetningene som er angitt i topptekstfeltet i forespørselen, da forespørselen ble validert. Denne statuskoden gjør det mulig for klienten å angi forhåndsbetingelser i metainformasjonen i forespørselen (data i header-feltet i forespørselen) når en ressurs hentes, slik at forespørselsmetoden ikke kan brukes på andre ressurser enn det innholdet den ønsker. |
| 413 | Serveren nekter å behandle den aktuelle forespørselen fordi den inneholder mer fysiske data enn serveren er villig eller i stand til å håndtere. I dette tilfellet kan serveren stenge forbindelsen for å hindre klienten i å fortsette å sende forespørselen. Hvis situasjonen er midlertidig, bør serveren returnere en Retry-After header for å informere klienten om hvor lang tid den har på seg til å prøve på nytt. |
| 414 | Forespørselen URI er lengre enn serveren kan tolke, så serveren nekter å betjene forespørselen. Dette skjer sjelden, og oppstår vanligvis når en skjemainnlevering som skulle ha brukt POST-metoden, blir en GET-metode, noe som resulterer i en lang spørringsstreng. "Svarte hull" i viderekoblings-URI-en, for eksempel ved at den gamle URI-en brukes som en del av den nye URI-en for hver viderekobling, noe som resulterer i en lang URI etter flere viderekoblinger. Klienter forsøker å angripe servere ved å utnytte sikkerhetshull som finnes i enkelte servere. Slike servere bruker en buffer med fast lengde til å lese eller manipulere den forespurte URI-en, noe som kan føre til et bufferoverløp når GET-parameteren overskrider en viss verdi, noe som kan føre til kjøring av vilkårlig kode.[1]。 Servere uten slike sårbarheter bør returnere en 414-statuskode. |
| 415 | For den aktuelle forespurte metoden og den forespurte ressursen er enheten som sendes inn i forespørselen, ikke i et format som støttes av serveren, og forespørselen blir avvist. |
| 416 | Hvis forespørselen inneholder et Range-forespørselshode, og eventuelle dataområder som er angitt i Range, ikke sammenfaller med de tilgjengelige områdene for den aktuelle ressursen, og If-Range-forespørselshodet ikke er definert i forespørselen, skal serveren returnere en 416-statuskode. Hvis Range bruker byteområder, betyr dette at den første byten i alle dataområdene som er angitt i forespørselen, overskrider lengden på den aktuelle ressursen. Serveren bør også inkludere en Content-Range-enhetsoverskrift som angir lengden på den aktuelle ressursen sammen med statuskoden 416. Dette svaret kan heller ikke bruke multipart/byteranges som Content-Type. |
| 417 | Det forventede innholdet som er spesifisert i forespørselshodet Expect, kan ikke oppfylles av serveren, eller serveren er en proxy-server som har klare bevis på at innholdet i Expect ikke kan oppfylles ved neste node i den aktuelle ruten. |
| 421 | Antall tilkoblinger til serveren fra IP-adressen til den aktuelle klienten overskrider det maksimale antallet som er tillatt av serveren. IP-adressen refererer her vanligvis til klientens adresse sett fra serveren (f.eks. brukerens gateway- eller proxy-serveradresse). I dette tilfellet kan mer enn én sluttbruker være involvert i antall tilkoblinger. |
| 422 | Antall tilkoblinger fra den aktuelle klientens IP-adresse til serveren overskrider det maksimale antallet som er tillatt av serveren. IP-adressen refererer her vanligvis til klientens adresse sett fra serveren (f.eks. brukerens gateway- eller proxy-serveradresse). I dette tilfellet kan mer enn én sluttbruker være involvert i antall tilkoblinger. |
| 422 | Forespørselen var riktig formatert, men kunne ikke besvares fordi den inneholdt semantiske feil. (RFC 4918 WebDAV) 423 Locked Den aktuelle ressursen er låst. (RFC 4918 WebDAV) 423 Låst |
| 424 | Den gjeldende forespørselen mislyktes på grunn av en feil i en tidligere forespørsel, for eksempel PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definert i utkastet til WebDav Advanced Collections, men forekommer ikke i WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Klienter bør bytte til TLS/1.0. (RFC 2817) |
| 449 | Utvidet av Microsoft for å representere at forespørsler bør forsøkes på nytt etter at den aktuelle handlingen er utført. |
| 500 | Serveren opplevde en uforutsett situasjon som hindret den i å fullføre behandlingen av forespørselen. Dette problemet oppstår vanligvis når det er en feil i serverens programkode. |
| 501 | Serveren støtter ikke en funksjon som kreves av den aktuelle forespørselen. Når serveren ikke gjenkjenner den forespurte metoden og ikke kan støtte forespørselen om en ressurs. |
| 502 | En server som fungerer som gateway eller proxy, mottar et ugyldig svar fra en oppstrømsserver når den prøver å utføre en forespørsel. |
| 503 | Serveren kan for øyeblikket ikke behandle forespørselen på grunn av midlertidig servervedlikehold eller overbelastning. Denne tilstanden er midlertidig og vil bli gjenopprettet etter en viss tid. Hvis det kan forventes en forsinkelse, kan svaret inneholde et Retry-After-hode for å angi forsinkelsen. Hvis denne Retry-After-informasjonen ikke oppgis, skal klienten håndtere den på samme måte som et 500-svar. Merk: At statuskoden 503 finnes, betyr ikke at serveren må bruke den hvis den er overbelastet. Noen servere ønsker ganske enkelt å nekte klienten å koble seg til. |
| 504 | En server som fungerer som en gateway eller proxy som forsøker å utføre en forespørsel, mottar ikke et svar i tide fra en oppstrømsserver (en server som er identifisert av en URI, for eksempel HTTP, FTP, LDAP) eller en sekundær server (for eksempel DNS). Merk: Noen proxy-servere returnerer en 400- eller 500-feil når DNS-oppslaget tar tid. |
| 505 | Serveren støtter ikke, eller nekter å støtte, den versjonen av HTTP som brukes i forespørselen. Dette innebærer at serveren ikke kan eller vil bruke samme versjon som klienten. Svaret skal inneholde en entitet som beskriver hvorfor versjonen ikke støttes, og hvilke protokoller serveren støtter. |
| 506 | Utvidet av Transparent Content Negotiation Protocol (RFC 2295) for å representere en intern feilkonfigurasjon fra serverens side: Den forespurte forhandlingsvariantressursen er konfigurert til å bruke seg selv i Transparent Content Negotiation, og er derfor ikke et passende fokus i en forhandlingsprosess. |
| 507 | Serveren kan ikke lagre innholdet som er nødvendig for å oppfylle forespørselen. Denne tilstanden anses som midlertidig.WebDAV(RFC 4918) |
| 509 | Serveren har nådd sin båndbreddegrense. Dette er ikke en offisiell statuskode, men er likevel mye brukt. |
| 510 | Policyen som kreves for å få tak i ressursen, er ikke oppfylt. (RFC 2774) |