HTTP-statuskode er en 3-cifret kode, der returneres af serveren som svar p? en anmodning, og som bruges til at identificere resultatet af anmodningen. Dette v?rkt?j giver en standardiseret klassificering og scenariefortolkning, der er velegnet til udviklere, drifts- og vedligeholdelsespersonale og elever i netv?rksteknologi.
Alle forklaringer er baseret p? RFC-standarddokumentet, s? man undg?r regionale forskelle i udtrykket og sikrer, at brugere over hele verden forst?r det samme.
| Http-statuskoder | Statuskode Betydning |
|---|---|
| 100 | Klienten b?r forts?tte med at sende anmodninger. Dette midlertidige svar bruges til at informere klienten om, at en del af anmodningen 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 afsluttet. 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-headeren om, at der blev brugt en anden protokol til at gennemf?re anmodningen. Efter at have sendt den sidste tomme linje i svaret, skifter serveren til de protokoller, der er defineret i Upgrade-headeren. Dette b?r kun g?res, hvis det er mere fordelagtigt at skifte til den nye protokol. For eksempel kan det v?re en fordel at skifte til en ny version af HTTP frem for en ?ldre version, eller at skifte til en synkron protokol i realtid for at levere ressourcer, der udnytter s?danne funktioner. |
| 102 | Statuskoder, udvidet med WebDAV (RFC 2518), angiver, at behandlingen vil forts?tte. |
| 200 | Anmodningen var vellykket, og de ?nskede svarhoveder eller data vil blive returneret sammen med svaret. |
| 201 | Anmodningen er blevet opfyldt, og en ny ressource er blevet oprettet som svar p? anmodningen, og dens URI er blevet returneret med Location-headeren. Hvis den ?nskede ressource ikke kan oprettes i tide, skal f?lgende returneres'202 Accepted'。 |
| 202 | Serveren har accepteret anmodningen, men har endnu ikke behandlet den. Ligesom den kan blive afvist, er det ikke sikkert, at anmodningen bliver udf?rt i sidste ende. I tilf?lde af asynkrone operationer er der ikke noget mere praktisk end at sende denne statuskode. Form?let med at returnere et 202-svar 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 klienten beh?ver at opretholde en forbindelse til serveren, indtil batchoperationen er 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 status, samt en pointer til en behandlingsstatusmonitor eller statusforudsigelse, s? brugeren kan vurdere, om operationen er afsluttet eller ej. |
| 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. Den aktuelle information kan v?re en delm?ngde eller en overm?ngde af den oprindelige. For eksempel kan metadata, der indeholder ressourcer, f? originalserveren 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 opdaterede metaoplysninger. Svaret kan returnere nye eller opdaterede metainformationer i form af entity headers. Hvis disse headere findes, b?r de svare til de ?nskede variabler. Hvis klienten er en browser, B?R brugerens browser beholde den side, hvor anmodningen blev sendt, 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 h?ndterer anmodningen med succes og returnerer intet. Men i mods?tning til 204-svaret beder det svar, der returnerer denne statuskode, rekvirenten 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 en stor fil i flere downloads 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, eller, i tilf?lde af multipart-downloads med en Content-Type p? multipart/byteranges, et Content-Range-felt i hvert multipart-segment for at angive omfanget af indholdet i det segment. Hvis svaret indeholder en Content-Length, skal dens v?rdi matche det sande antal bytes i det indholdsomr?de, det returnerer. Expires, Cache-Control og/eller Vary, hvis deres v?rdier kan v?re forskellige fra v?rdierne i andre tidligere svar med de samme variabler. Dette svar b?r ikke indeholde andre entitetsoverskrifter, hvis anmodningen bruger st?rk If-Range-cachevalidering, og b?r ikke indeholde andre entitetsoverskrifter, hvis anmodningen bruger svag If-Range-cachevalidering; dette undg?r uoverensstemmelser mellem det cachelagrede entitetsindhold og de opdaterede entitetsoverskriftsoplysninger. Ellers B?R dette svar indeholde alle de entitetsoverskriftsfelter, der skulle have v?ret returneret i 200-svaret. Hvis ETag- eller Last-Modified-overskrifterne ikke matcher n?jagtigt, b?r cachen p? klientsiden afvise at kombinere det indhold, der returneres i svar 206, med tidligere cachelagret indhold. Enhver cache, der ikke underst?tter Range- og Content-Range-overskrifterne, m? ikke cachelagre det indhold, der returneres i 206-svaret. |
| 207 | Statuskoder udvidet af WebDAV(RFC 2518) Statuskoden, som udvidet af WebDAV, 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 anmodede ressource har en r?kke alternative svar, hver med sin egen specifikke adresse og browserdrevne forhandlingsoplysninger. Det er op til brugeren eller browseren at v?lge en foretrukken adresse til omdirigering. Medmindre der er tale om en HEAD-anmodning, skal svaret indeholde en entitet, 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 naturligvis ikke, hvordan dette automatiske valg skal foretages. Hvis serveren selv allerede har en foretrukken returmulighed, skal URI'en for returen angives i Location; browsere kan bruge denne Location-v?rdi som adresse for automatisk omdirigering. Desuden kan svaret 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, skal svarentiteten indeholde et hyperlink til den nye URI og en kort beskrivelse. Hvis dette ikke er en GET- eller HEAD-anmodning, er det 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 GET. |
| 302 | Den anmodede ressource svarer nu midlertidigt p? anmodningen fra en anden URI. Da denne omdirigering er midlertidig, skal klienten forts?tte med at sende fremtidige anmodninger til den oprindelige adresse. Svaret 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-foresp?rgsel, 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 under 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 erstatningsreference til den oprindelige ressource. Det er heller ikke tilladt at cachelagre 303-svaret. Den anden anmodning (omdirigering) m? selvf?lgelig godt 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 forst?r ikke 303-tilstanden korrekt. Hvis interaktion med disse browsere skal overvejes, b?r 302-statuskoden fungere, da de fleste browsere h?ndterer 302-svaret p? n?jagtig samme m?de, som specifikationen ovenfor kr?ver, at klienten h?ndterer 303-svaret. |
| 304 | Denne statuskode skal returneres af serveren, hvis klienten sender en betinget GET-anmodning, og anmodningen er tilladt, og indholdet af dokumentet ikke er ?ndret (enten siden sidste bes?g eller i henhold til betingelserne for anmodningen). 304-svar er forbudt at indeholde en meddelelsestekst og slutter derfor altid med den f?rste tomme linje efter meddelelsens overskrift. Svaret skal indeholde f?lgende headeroplysninger: Dato, medmindre serveren ikke har et ur. Hvis serveren ikke har et ur, f?lger disse regler, s? 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 skulle have returneret et 200-svar. Expires, Cache-Control og/eller Vary, hvis deres v?rdier kan v?re forskellige fra v?rdierne i andre tidligere svar med de samme variabler. Hvis svaranmodningen bruger st?rk cache-validering, b?r svaret ikke indeholde yderligere entitetsoverskrifter; ellers (f.eks. hvis en betinget GET-anmodning bruger svag cache-validering) er det forbudt for svaret at indeholde yderligere entitetsoverskrifter; dette undg?r uoverensstemmelser mellem cachelagret entitetsindhold og opdateret entitetsoverskriftsinformation. 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 en specificeret proxy. Feltet Location giver oplysninger om URI'en for den specificerede proxy, og 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 | Anmodede ressourcer svarer nu midlertidigt p? anmodninger fra forskellige URI'er. Da denne omdirigering er midlertidig, 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, er det n?dvendigt at tilf?je ovenst?ende oplysninger, 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, semantisk fejl, den aktuelle anmodning kan ikke forst?s af serveren. Medmindre den er ?ndret, b?r klienten ikke gentage anmodningen. 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 sende en anmodning igen med de relevante oplysninger i Authorisation-headeren. Hvis den aktuelle anmodning allerede indeholder autorisationsoplysninger, betyder et 401-svar, 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 gjort mindst ét fors?g p? godkendelse, b?r browseren vise brugeren 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 anmodningen b?r ikke indsendes igen. Hvis dette ikke er en HEAD-anmodning, og serveren ?nsker at kunne sige, hvorfor anmodningen ikke kan udf?res, skal ?rsagen til afvisningen beskrives i entiteten. Serveren kan selvf?lgelig ogs? returnere et 404-svar, hvis den ikke ?nsker, at klienten skal f? 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 serveren 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 eller tillader de fleste webservere 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 de mest passende entitetskarakteristika og en liste over adresser, som brugeren eller browseren kan v?lge imellem. Entitetens format bestemmes af den medietype, der er defineret i Content-Type-headeren. Browseren kan tr?ffe det bedste valg baseret p? formatet og sine 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 hos proxyserveren. Proxyserveren SKAL returnere en Proxy-Authenticate til identitetsafh?ring. Klienten kan returnere en Proxy-Authorisation header til autentificering. Se RFC 2617. |
| 408 | Timeout for anmodning. Klienten gennemf?rte ikke 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 indsende en ny anmodning. Svaret b?r indeholde tilstr?kkelig information til, at brugeren kan finde kilden til konflikten. Konflikter opst?r ofte i behandlingen af PUT-anmodninger. I et versionskontrolmilj? b?r en PUT, der sendes for at ?ndre en bestemt ressource med versionsoplysninger, der er i konflikt med en tidligere (tredjeparts) anmodning, f.eks. 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, sammenlagte version igen. |
| 410 | Den ?nskede ressource er ikke l?ngere tilg?ngelig p? serveren, og der er ingen kendt videresendelsesadresse. En s?dan situation 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 tilstanden er permanent, skal der bruges en 404-statuskode. Medmindre andet er angivet, kan dette svar caches. Form?let med 410-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 ressourcen ogs? skal slettes. Denne type h?ndelse er almindelig i tidsbegr?nsede tjenester med merv?rdi. P? samme m?de bruges 410-svaret til at underrette klienten om, at en ressource, der tilh?rer en person, ikke l?ngere er tilg?ngelig p? det aktuelle serversted. Sp?rgsm?let om, hvorvidt alle permanent utilg?ngelige ressourcer skal markeres som s?dan, og hvor l?nge de skal forblive det, er naturligvis ogs? vigtigt.'410 Gone'， Det er helt op til serverejeren at bestemme, hvad der skal v?re permanent utilg?ngeligt, og hvor l?nge det skal opretholdes. |
| 411 | Serveren n?gter at acceptere anmodninger uden en defineret Content-Length header. Klienten kan sende anmodningen igen efter at have tilf?jet en gyldig Content-Length-header, der angiver l?ngden af anmodningens meddelelsestekst. |
| 412 | Serveren kunne ikke opfylde en eller flere af de foruds?tninger, der er angivet i anmodningens headerfelt, da den validerede anmodningen. Denne statuskode g?r det muligt for klienten at angive foruds?tninger i anmodningens metainformation (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 indeholder flere fysiske data, 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 anmodningen. Hvis situationen er midlertidig, b?r serveren returnere en Retry-After-header for at informere klienten om, hvor lang tid den har til at pr?ve igen. |
| 414 | Anmodningens URI er l?ngere, end serveren kan fortolke, s? serveren n?gter at betjene anmodningen. Dette er sj?ldent og sker normalt, 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", s?som at bruge den gamle URI som en del af den nye URI for 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 den anmodede URI, hvilket kan resultere i et bufferoverl?b, n?r GET-parameteren overstiger en bestemt v?rdi, hvilket 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, og anmodningen afvises. |
| 416 | Hvis anmodningen indeholder en Range-anmodningsheader, og eventuelle dataomr?der, der er angivet i Range, ikke falder sammen 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, betyder det, at den f?rste byte i alle de data-intervaller, der er angivet i anmodningen, overstiger l?ngden af den aktuelle ressource. Serveren b?r 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 serveren 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 aktuelle klients IP-adresse 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 mere end én slutbruger v?re involveret i forbindelsest?llingen. |
| 422 | Antallet af forbindelser fra den aktuelle klients IP-adresse til serveren overskrider det maksimalt tilladte af serveren. IP-adressen refererer her typisk til klientens adresse set fra serveren (f.eks. brugerens gateway- eller proxyserveradresse). I dette tilf?lde kan mere end én slutbruger v?re involveret i antallet af forbindelser. |
| 422 | Foresp?rgslen 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) 423 L?st |
| 424 | Den aktuelle anmodning mislykkedes p? grund af en fejl i en tidligere anmodning, f.eks. 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 funktion, der kr?ves af den aktuelle anmodning. N?r serveren ikke genkender den ?nskede metode og ikke kan underst?tte dens anmodning om nogen 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 Transparent Content Negotiation og er derfor ikke et passende fokus i en forhandlingsproces. |
| 507 | Serveren kan ikke gemme det indhold, der er n?dvendigt for at opfylde 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 f? fat i ressourcen, er ikke blevet opfyldt. (RFC 2774) |