| Http-statuskode | 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 meldingshodet Upgrade om å bruke en annen protokoll for å fullføre forespørselen. Etter at den siste tomme linjen i dette svaret er sendt, vil serveren bytte til de protokollene som er definert i Upgrade-meldingshodet. Dette bør bare gjøres hvis det er mer fordelaktig å bytte til en ny protokoll. Det kan for eksempel være mer fordelaktig å bytte til en ny versjon av HTTP enn en eldre versjon, eller å bytte til en sanntids- og synkronprotokoll for å levere ressurser som drar nytte av slike funksjoner. |
| 102 | Statuskoder, utvidet av WebDAV (RFC 2518), representerer at behandlingen vil fortsette. |
| 200 | Forespørselen har blitt godkjent, og svarhodet eller datahelheten som forespørselen ønsket, vil bli returnert med dette svaret. |
| 201 | Forespørselen er oppfylt, og en ny ressurs er opprettet i henhold til forespørselen, og dens URI er returnert med Location-headeren. Hvis den nødvendige ressursen ikke kan opprettes i tide, returneres "202 Accepted". |
| 202 | Serveren har akseptert forespørselen, men har ennå ikke behandlet den. På samme måte som den kan bli avvist, kan det hende at forespørselen til slutt blir utført eller ikke. I forbindelse med asynkrone operasjoner er det ikke noe mer praktisk enn å sende denne statuskoden. Hensikten med å returnere et svar med statuskoden 202 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 å måtte holde klienten tilkoblet serveren helt til batchoperasjonen er fullført. Et svar som aksepterer en forespørsel om behandling og returnerer en 202-statuskode, BØR inneholde informasjon som angir prosessens nåværende tilstand, samt en peker til en statusmonitor eller statusprediksjon, slik at brukeren kan anslå om operasjonen er fullført. |
| 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 den opprinnelige versjonen. For eksempel kan metadata som inneholder ressurser, føre til at den opprinnelige serveren 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 slike overskrifter 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 at dokumentvisningen endres, 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 har behandlet forespørselen og ikke returnert noe. 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 et stort dokument i flere nedlastingssegmenter 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 header-felt: Content-Range for å indikere omfanget av innholdet som returneres i dette svaret; i tilfelle av en nedlasting av flere segmenter med en Content-Type av multipart/byteranges, bør hvert multipart-segment inneholde et Content-Range-felt som indikerer omfanget av innholdet i det segmentet. Hvis svaret inneholder en Content-Length, må verdien stemme overens med det sanne antallet byte i innholdsområdet som returneres. date 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 andre svar med de samme variablene. Expires, Cache-Control og/eller Vary, hvis verdiene kan være forskjellige fra verdiene i andre tidligere svar for de samme variablene. Dette svaret BØR IKKE inneholde andre entitetshoder hvis forespørselen bruker If-Range sterk hurtigbuffervalidering, og BØR IKKE inneholde andre entitetshoder hvis forespørselen bruker If-Range svak hurtigbuffervalidering; på denne måten unngår man uoverensstemmelser mellom bufret entitetsinnhold og oppdatert informasjon i entitetshodene. Ellers BØR dette svaret inneholde alle entitetshodefeltene som skulle ha vært returnert i alle 200-svarene som skulle ha vært returnert. Hvis ETag- eller Last-Modified-overskriftene ikke stemmer nøyaktig overens, BØR hurtigbufferen på klientsiden forby å kombinere innholdet som returneres i svar 206 med tidligere bufret innhold. Enhver hurtigbuffer som ikke støtter Range- og Content-Range-overskriftene, har forbud mot å bufre innholdet som returneres av 206-svaret. |
| 207 | Statuskoden, som utvidet av WebDAV (RFC 2518), 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 returmeldinger, hver med sin egen spesifikke adresse og nettleserstyrt forhandlingsinformasjon. Brukeren eller nettleseren kan selv 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 et slikt automatisk valg skal gjøres. Hvis serveren selv allerede har et foretrukket valg av retur, bør URI-en for denne returen angis i Location; nettleseren kan bruke denne Location-verdien som adresse for automatisk omdirigering. I tillegg kan dette svaret også 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 derfor forbudt for nettleseren å omdirigere automatisk med mindre brukeren bekrefter det, ettersom vilkårene for forespørselen kan endres som et resultat av dette. Merk: For noen nettlesere som bruker HTTP/1.0-protokollen, vil den neste omdirigeringsforespørselen være en 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. 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, 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 ved 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 alternativ referanse til den opprinnelige ressursen. Det er også forbudt å 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 svarenheten inneholde en hyperkobling til den nye URI-en og en kort beskrivelse. Merk: Mange nettlesere før HTTP/1.1-versjoner forstår ikke 303-status på riktig måte. Hvis interaksjon med disse nettleserne må vurderes, bør 302-statuskoden gjøre susen, 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 | Serveren BØR returnere denne statuskoden hvis klienten sender en betinget GET-forespørsel som er tillatt, og innholdet i dokumentet (siden forrige besøk eller i henhold til vilkårene for forespørselen) ikke er endret.304 Svar er forbudt å inneholde en meldingstekst, og avsluttes derfor alltid med den første tomme linjen etter meldingsoverskriften. Svaret MÅ inneholde følgende overskrifter: Dato, med mindre serveren ikke har en klokke. Hvis en server uten klokke følger disse reglene, kan proxy-serveren og klienten 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 ville ha returnert et 200-svar.Expires Expires, Cache-Control og/eller Vary, hvis verdien kan være forskjellig fra verdien som tilsvarer andre tidligere svar for den samme variabelen. Hvis denne svarforespørselen bruker sterk cache-validering, skal dette svaret ikke inneholde andre entitetsoverskrifter; i motsatt fall (f.eks. hvis en betinget GET-forespørsel bruker svak cache-validering), er det forbudt for dette svaret å inneholde andre entitetsoverskrifter; på denne måten unngår man uoverensstemmelser mellom bufret entitetsinnhold og oppdatert informasjon i entitetsoverskriftene. 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 den angitte proxyen. feltet Location gir informasjon om URI-en der den angitte proxyen befinner seg. 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 konsekvenser for sikkerheten. |
| 306 | I den nyeste versjonen av spesifikasjonen brukes ikke statuskoden 306 lenger. |
| 307 | Den forespurte ressursen svarer nå midlertidig på forespørselen fra en annen URI. Siden slike omdirigeringer er midlertidige, 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, må informasjonen ovenfor legges til 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 bekrefter det, fordi vilkårene for forespørselen kan endre seg. |
| 400 | 1. Det foreligger en semantisk feil, og den aktuelle forespørselen kan ikke forstås av serveren. Med mindre den er endret, bør klienten ikke sende denne forespørselen gjentatte ganger. 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 forespørsel gjentatte ganger som inneholder riktig Authorisation header-informasjon. Hvis den aktuelle forespørselen allerede inneholder autorisasjonsopplysninger, betyr 401-svaret at serveren bekrefter at disse opplysningene er avvist. Hvis 401-svaret inneholder samme autentiseringsforespørsel som det forrige svaret, og nettleseren allerede har forsøkt autentisering minst én gang, BØR nettleseren presentere brukeren for entitetsinformasjonen i svaret, ettersom 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 denne forespørselen bør ikke sendes på nytt. Hvis dette ikke er en HEAD-forespørsel, og serveren ønsker å kunne si klart ifra om 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 å gi klienten noen informasjon. |
| 404 | Forespørselen mislyktes, den forespurte ressursen ble ikke funnet på serveren. Det er ingen informasjon som forteller brukeren om situasjonen er midlertidig eller permanent. Hvis serveren er klar over situasjonen, bør den bruke statuskoden 410 for å informere brukeren om at den gamle ressursen er permanent utilgjengelig på grunn av en intern konfigurasjonsmekanisme, og at det ikke finnes noen omadressering. 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 tilgjengelig. |
| 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. Ettersom PUT- og DELETE-metodene skriver til ressursen på serveren, støtter de fleste webservere ikke disse forespørselsmetodene eller tillater 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 en liste over entitetsegenskaper og adresser som brukeren eller nettleseren kan velge den mest hensiktsmessige fra. Formatet på entiteten bestemmes av medietypen som er definert i Content-Type-overskriften. Nettlesere kan gjøre sine egne valg basert på formatet og sine egne evner. Spesifikasjonen definerer imidlertid ingen kriterier for å gjøre slike automatiske valg. |
| 407 | Likner 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-Authorization-hode for autentisering. Se RFC 2617. |
| 408 | Tidsavbrudd for forespørsel. Klienten fullførte ikke sendingen av 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 den forespurte ressursens nåværende tilstand. Denne koden kan bare brukes hvis brukeren anses å være i stand til å løse konflikten og sende inn en ny forespørsel. Svaret bør inneholde nok informasjon til at brukeren kan finne kilden til konflikten. Konflikter oppstår vanligvis i behandlingen av PUT-forespørsler. Hvis for eksempel versjonsinformasjonen som er knyttet til en PUT-forespørsel som sendes inn for å endre en bestemt ressurs, er i konflikt med en tidligere (tredjeparts) forespørsel, bør serveren returnere en 409-feilmelding 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 versjonen på nytt etter sammenslåingen. |
| 410 | Den forespurte ressursen er ikke lenger tilgjengelig på serveren og har ingen kjent videresendingsadresse. En slik tilstand 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 denne tilstanden er permanent, bør en 404-statuskode brukes. Med mindre annet er angitt, kan dette svaret lagres i hurtigbufferen.410 Formålet med dette svaret er først og fremst å 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 denne ressursen også skal fjernes. Denne typen hendelser er vanlige i tidsbegrensede, verdiøkende tjenester. På samme måte brukes 410-svaret til å varsle klienter om at en ressurs som opprinnelig tilhørte en person på det aktuelle serverområdet, ikke lenger er tilgjengelig. Det er selvsagt helt opp til servereieren om alle permanent utilgjengelige ressurser skal merkes som "410 Gone", og hvor lenge denne merkingen skal opprettholdes. |
| 411 | Serveren nekter å godta forespørsler uten at Content-Length-overskriften er definert. Etter å ha lagt til et gyldig Content-Length-hode som angir lengden på meldingsteksten, kan klienten sende inn forespørselen på nytt. |
| 412 | Serveren klarte ikke å oppfylle en eller flere av forutsetningene da den verifiserte at de var oppgitt i topptekstfeltet i forespørselen. Denne statuskoden gjør det mulig for klienten å angi forhåndsbetingelser i metameddelelsen (data i topptekstfeltet i forespørselen) når en ressurs skal 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 entitetsdata som er større enn serveren er villig eller i stand til å håndtere. I dette tilfellet kan serveren stenge forbindelsen for å hindre at klienten fortsetter å sende denne forespørselen. Hvis denne tilstanden er midlertidig, bør serveren returnere et Retry-After-svarhode for å informere klienten om hvor lang tid det tar før den kan prøve på nytt. |
| 414 | Lengden på forespørselens URI overskrider lengden som serveren kan tolke, slik at serveren nekter å betjene forespørselen. Dette skjer sjelden, men ofte når et skjema som skulle ha vært sendt inn med POST-metoden, blir sendt inn med GET-metoden, 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 ved 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 URI-en til en forespørsel, og når parameterne etter en GET overskrider en viss verdi, kan det oppstå et bufferoverløp, 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 ikke entiteten som sendes inn i forespørselen, i et format som støttes av serveren, og forespørselen blir derfor avvist. |
| 416 | Hvis forespørselen inneholder et Range-forespørselshode, og eventuelle dataområder som er angitt i Range, ikke overlapper 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, er dette tilfelle hvis den første byteposisjonen 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 spesifiserer 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 denne 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 der den aktuelle klienten befinner seg, 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 antall tilkoblinger omfatte mer enn én sluttbruker. |
| 422 | 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 antall tilkoblinger omfatte mer enn én sluttbruker. |
| 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) |
| 424 | Den gjeldende forespørselen mislyktes på grunn av en feil som oppstod 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 tilstand 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 bestemt funksjon som er nødvendig for den aktuelle forespørselen. Når serveren ikke kan gjenkjenne 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 stund. 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, og som forsøker å utføre en forespørsel, får ikke 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 er tidsavbrutt. |
| 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 en transparent innholdsforhandling, og er derfor ikke et egnet fokus i en forhandlingsprosess. |
| 507 | Serveren kan ikke lagre innholdet som er nødvendig for å fullføre 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, ble ikke ikke oppfylt. (RFC 2774) |