Online værktøjer
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)
Adgang til optegnelser: