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) |