| HTTP status kode | Statuskodes betydning |
|---|
| 100 | Klienten skal fortsætte med at sende anmodninger. Denne midlertidige respons bruges til at informere klienten om, at nogle af dens anmodninger er modtaget af serveren og ikke er afvist. Klienten skal fortsætte med at sende resten af anmodningen, eller ignorere responsen, hvis anmodningen er afsluttet. Serveren skal sende en endelig respons til klienten efter at anmodningen er afsluttet. |
| 101 | Serveren har forstået klientens anmodning og vil informere klientens side gennem Upgrade-headeren om at bruge et andet protokol til at fuldføre anmodningen. Efter at have sendt den sidste blanke linje i svaret, vil serveren skifte til de protokoller defineret i Upgrade-headeren. Lignende foranstaltninger bør kun træffes, når skiftet til en ny protokol er mere gunstigt. For eksempel har skiftet til en ny HTTP-version fordele over en gammel version, eller skiftet til en virkelig-tid og synkron protokol til at levere ressourcer, der udnytter sådanne funktioner. |
| 102 | Statuskoden udvidet af WebDAV (RFC 2518) indikerer, at behandlingen vil fortsætte. |
| 200. | Anmodningen var succesfuld, og de ønskede responsheader eller datakroppe returneres med svaret. |
| 201 | Anmodningen er blevet opfyldt, og en ny ressource er blevet oprettet baseret på kravene i anmodningen, og dens URI er blevet returneret med Location-headeren. Hvis den krævede ressource ikke kan oprettes i tide,'202 Accepteret' bør returneres. |
| 202 | Serveren har accepteret anmodningen, men den har endnu ikke behandlet den. ligesom den måske kan afvises, kan anmodningen måske eller måske ikke udføres til sidst. I tilfælde af asynkrone operationer er der ingen mere bekvem måde at gøre dette på end at sende denne statuskode. Formålet med at returnere en 202 statuskode-svar er for at lade serveren acceptere anmodninger fra andre processer (som en batch-en baseret operation, der udføres kun én gang om dagen) uden at behøve at holde klientens forbindelse til serveren, indtil batchoperationen er fuldført. Som svar på at acceptere en anmodning om behandling og returnere en 202 statuskode, bør den returnerede entity inkludere nogen information, der indikerer den nuværende tilstand af processen, samt et pejl til processtatusovervågningen eller statusprognosen, så brugeren kan vurdere, om operationen er afsluttet. |
| 203 | Serveren har behandlede forespørgslen succesfuldt, men den returnerede entity header metainformation er ikke en gyldig deterministisk sæt på oprindelsesserveren, men er en lokal eller tredjeparts-part kopi. Den nuværende information kan være en delmængde eller en overmængde af den oprindelige version. For eksempel kan metadata, der indeholder ressourcer, få oprindelsesserveren til at vide om meta super. Brug af denne statuskode er ikke påkrævet og er kun passende, hvis svaret returnerer 200 OK uden denne statuskode. |
| 204 | Serveren behandlede forespørgslen succesfuldt, men behøver ikke returnere nogen fysisk indhold, og ønsker at returnere opdateret metainformation. Svaret kan være i form af en entity header, der returnerer nye eller opdaterede metainformationer. Hvis denne headerinformation eksisterer, skal den korrespondere til den anmodede variabel. Hvis klienten er en browser, skal brugerens browser holde den side, der sendte forespørgslen, uden nogen ændringer i dokumentvisningen, selvom nye eller opdaterede metainformationer skal anvendes på dokumentet i brugerens browserens aktive visning ifølge specifikationen. Siden den 204 respons er forbudt fra at inkludere nogen meddelelseskrop, den slutter altid med den første blanke linje efter headeren. |
| 205 | Serveren behandlede forespørgslen succesfuldt og returnerede intet. Men i modsætning til den 204 Respons, den respons, der returnerer denne statuskode, kræver, at forespørgsleren nulstiller dokumentvisningen. Denne respons bruges primært til at nulstille formularen øjeblikkeligt efter at have accepteret brugerinput, så brugeren nemt kan starte en anden input. Som den 204 svar, dette svar er også forbudt fra at inkludere nogen meddelelseskrop og slutter med den første blanke linje efter headeren. |
| 206 | Serveren har succesfuldt behandlet en del af GET forespørgslen. HTTP download værktøjer som FlashGet eller Xunlei bruger denne type svar til at implementere en brudstykke fortsættelse eller til at bryde et stort dokument op i flere downloadsegmenter til samtidig download. Forespørgslen skal indeholde en Række header for at indikere rækken af indhold, klienten ønsker, og kan inkludere Hvis-Række som en forespørgsel betingelse. Svaret skal indeholde følgende hovedfelter: Content-Række for at indikere rækken af indhold, der returneres i dette svar; hvis det er et multi-segment download med Content-Type del/byteranges, skal hver delsegment indeholde en Content-Række feltet for at indikere indholdet række af dette segment. Hvis svaret indeholder Content-Længde, så dens værdi skal matche det faktiske antal bytes i indholdet række det returnerer. Dato ETag og/eller Indhold-Lokation, hvis den samme anmodning skulle have returneret en 200 svar. Udløber, Cache-Kontrol, og/eller Vary, hvis dens værdi kan være forskellig fra værdien, der svarer til andre svar til samme variabel før. Hvis dette svar forespørgsel bruger Hvis-Række stærk cache validering, så dette svar bør ikke indeholde andre enhedshoveder; hvis dette svar forespørgsel bruger Hvis-Række svag cache validering, så dette svar bør ikke indeholde andre enhedshoveder; dette undgår inkonsistens mellem cached enhed indhold og opdateret enhedshoved information. ellers, dette svar bør indeholde alle enhedshoved felt, der skal returneres i en 200 svar. Hvis ETag eller Sidst-Modificeret headers matcher ikke præcist, klientens cache skal forbyde kombinationen af indholdet, der returneres i 206 svar med nogen tidligere cachet indhold. Enhver cache, der ikke understøtter Række og Indhold-Rækkeheader er forbudt fra at cachere indholdet, der returneres af 206 svar. |
| 207 | En statuskode udvidet af WebDAV (RFC 2518) repræsenterer, at kroppen af det efterfølgende meddelelse vil være en XML-meddelelse, og kan indeholde en række uafhængige svarkoder afhængigt af antallet af tidligere under-anmodninger. |
| 300 | Den anmodede ressurs har en række feedbackmuligheder, hver med sin egen specifikke adresse og browser-driven negotiation information. Brugeren eller browseren kan vælge en foretrukken adresse for omdirigering. Hvis dette ikke er en HEAD-anmodning, skal svaret indeholde en entitet med en liste over ressourcelistegenskaber og adresser, fra hvilke brugeren eller browseren kan vælge den mest passende omdirigeringsadresse. Formatet for denne entitet bestemmes af formatet defineret af Content-Type. Browseren kan automatisk vælge det mest passende valg baseret på formatet af svaret og browserens egne funktioner. Selvfølgelig, RFC 2616 angiver ikke, hvordan denne automatiske valg skal udføres. Hvis serveren selv allerede har en foretrukken feedback-valg, skal URI'en for feedback specificeres i Location; browsere kan bruge denne Location-værdi som adressen for automatisk omdirigering. Derudover er svaret også cachebar, hvis ikke andet er angivet. |
| 301 | Den anmodede ressurs er permanent flyttet til en ny placering, og enhver fremtidig reference til denne ressurs skal bruge en af flere URI'er, der returneres af dette svar. Hvis det er muligt, skal klienten med linkredigeringsfunktioner automatisk ændre den anmodede adresse til den adresse, der returneres fra serveren. Hvis ikke andet er angivet, er dette svar også cachebar. Den nye permanente URI skal returneres i Location-feltet af svaret. Hvis dette ikke er en HEAD-anmodning, skal svarets entitet indeholde en hyperlinke til den nye URI og en kort beskrivelse. Hvis dette ikke er en GET eller HEAD-anmodning, er browseren forbudt fra at automatisk omdirigere medmindre brugeren bekræfter det, da betingelserne for anmodningen kan ændre sig som følge heraf. Bemærk: For nogle browsere, der bruger HTTP-specifikationen,/1.0-protokollen, når de sender en POST-anmodning og får en 301 svar, vil den efterfølgende omdirigeringsanmodning blive GET. |
| 302 | Den anmodede ressurs svarer nu midlertidigt på anmodningen fra en anden URI. Da sådanne omdirigeringer er midlertidige, skal klientens side fortsætte med at sende fremtidige anmodninger til den oprindelige adresse. Dette svar er cachenaturligt kun, hvis specificeret i Cache-Kontrol eller Udløbsdato. Den nye midlertidige URI skal returneres i Lokationfeltet af svaret. Hvis dette ikke er en HEAD-anmodning, skal svarentitlen indeholde en hyperlink til den nye URI og en kort beskrivelse. Hvis dette ikke er en GET eller HEAD-anmodning, forbyder browseren automatisk omdirigering medmindre bekræftet af brugeren, da betingelserne for anmodningen kan ændre sig som et resultat. Bemærk: Selvom RFC 1945 og RFC 2068 specifikationer tillader ikke klienten at ændre anmodningsmetoden, når der omdirigeres, mange eksisterende browsere behandler de 302 svar som en 303 svar og brug GET til at få adgang til URI'et specificeret i Location, ved at ignorere den oprindelige anmodningsmetode. Statuskoder 303 og 307 ble tilføjet for at klargøre, hvad serveren forventer fra klientens side. |
| 303 | svar til den aktuelle anmodning kan findes på en anden URI, og klienten skal GET-adgang til denne ressurs. Denne metode findes primært for at tillade script-aktiveret POST-anmodning output skal omdirigeres til en ny ressurs. Denne nye URI er ikke en erstatning reference til den oprindelige ressurs. Også, 303 svar er forbudt at blive cached. Selvfølgelig kan en anden anmodning (omdirigering) blive cached. Den nye URI skal returneres i Lokation-feltet af svaret. Hvis dette ikke er en HEAD-anmodning, skal svar-entiteten indeholde en hyperlink til den nye URI og en kort beskrivelse. Bemærk: Mange browsere før HTTP/1.1 ikke forstår 303 status korrekt. Hvis du skal overveje interaktion med disse browsere, er 302 statuskode skal være tilstrækkelig, fordi de fleste browsere håndterer 302 svar præcis på samme måde, som ovenstående specifikation kræver, at klienten håndterer 303 svar. |
| 304 | Hvis klienten sender en betinget GET-anmodning og anmodningen er blevet tilladt, og dokumentets indhold ikke er ændret (siden sidste besøg eller i henhold til betingelserne for anmodningen), skal serveren returnere denne statuskode. 304 svar er forbudt at inkludere meddelelseskroppe, så de skal altid afsluttes med den første blanke linje efter hovedet. Svar skal indeholde følgende hovedinformation: Date, medmindre denne server har ingen klokke.
Hvis serveren uden en klokke også følger disse regler, kan proxy-serveren og klienten selv tilføje Datofeltet til modtagne respons-hoveder (som specificeret i RFC 2068), og caching-mekanismen vil fungere fint. ETag og/eller Indhold-Lokation, hvis den samme anmodning skulle have returneret en 200 svar. Udløber, Cache-Kontrol, og/eller Vary, hvis værdien kan være forskellig fra værdien, der svarer til andre svar på samme variabel før.
Hvis denne responsforespørgsel bruger stærk cachevalidering, skal denne respons ikke inkludere andre entity-hoveder; ellers (f.eks. en betinget GET-anmodning bruger svag cachevalidering), er det forbudt at inkludere andre entity-hoveder; dette undgår inkonsistens mellem cachede entity-indhold og opdaterede entity-hovedinformation. Hvis en 304 svar indikerer, at en enhed ikke aktuelt er cached, skal caching-systemet ignorere svaret og sende gentagne anmodninger uden restriktioner.
Hvis en 304 svar modtageres for at opdatere en cached indgang, skal caching-systemet opdatere hele indgangen for at afspejle værdierne for alle felter, der blev opdateret i svaret. |
| 305 | Den anmodede ressurs skal tilgås gennem den specificerede proxy. URI-informationen for den specificerede proxy gives i Location-feltet. Modtageren skal gentagne gange sende en separat anmodning for at tilgå den tilsvarende ressurs gennem denne proxy. Kun den oprindelige server kan etablere en 305 svar. Bemærk: Der er ingen eksplicit 305 svar i RFC 2068 til at omdirigere en enkelt anmodning, og det kan kun etableres af den oprindelige server. Ignorerer disse restriktioner kan føre til alvorlige sikkerhedskonsekvenser. |
| 306 | I den nyeste version af specifikationen, 306 statuskode bruges længere. |
| 307 | Den anmodede ressurs svarer nu midlertidigt på anmodningen fra en anden URI. Da sådanne omdirigeringer er midlertidige, skal klienten fortsætte med at sende fremtidige anmodninger til den oprindelige adresse. Denne respons kan kun caches, hvis det specificeres i Cache-Kontrol eller Udløb. Den nye midlertidige URI skal returneres i responsens Location-felt. Medmindre det er en HEAD-anmodning, skal den respondinge enhed indeholde en hyperlink, der peger på den nye URI, og en kort beskrivelse. Da nogle browsere ikke genkender 307 svar, skal ovenstående information tilføjes, 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 brugeren bekræfter det, da anmodningens betingelser kan ændre sig som følge heraf. |
| 400 | 1. Semantikken er forkert, og den aktuelle forespørgsel kan ikke forstås af serveren. Medmindre ændret, bør klienten ikke indsende forespørgslen gentagne gange. 2. Forespørgselsparametrene er forkerte. |
| 401 | Aktuelle forespørgsel kræver brugerautentificering. Svaret skal indeholde en WWW-Autentificeringshovedet for den anmodede ressource for at bede brugeren om information. Klienten kan indsende en forespørgsel igen med den passende Authorization-hovedinformation. Hvis den aktuelle forespørgsel allerede indeholder Authorization-certifikater, så bør den 401 svar repræsenterer, at serveren har afvist disse certifikater. Hvis den 401 svar indeholder den samme autentificeringsforespørgsel som det tidligere svar, og browseren har forsøgt autentificering mindst én gang, så browseren bør vise brugeren den entitetinformation, der indeholder svaret, da denne entitetinformation kan indeholde relevant diagnostisk information. Se RFC 2617. |
| 402 | Denne statuskode er reserveret til mulige fremtidige krav. |
| 403 | Serveren har forstået forespørgslen, men afvist at udføre den. I modsætning til en 401 svar, autentificering hjælper ikke, og forespørgslen bør ikke gentages. Hvis dette ikke er en HEAD-forespørgsel, og serveren ønsker at kunne forklare, hvorfor forespørgslen ikke kan udføres, så bør grunden til afvisningen beskrives inden for entiteten. Selvfølgelig kan serveren også returnere en 404 svar, hvis den ikke ønsker, at klienten skal få nogen information. |
| 404 | Forespørgslen mislykkedes, og den ønskede ressource blev ikke fundet på serveren. Der er ingen information til at fortælle brugeren, om tilstanden er midlertidig eller permanent. Hvis serveren er opmærksom på situationen, den 410 Statuskoden skal bruges til at informere den gamle ressource om, at den er permanent utilgængelig på grund af nogen intern konfigurationsmekanisme og har ingen adresse at hoppe til. Den 404 Statuskoden bruges ofte, når serveren ikke ønsker at afsløre, hvorfor forespørgslen blev afvist eller der ikke er anden passende respons tilgængelig. |
| 405 | Den kravmetode, der specificeres i kravlinjen, kan ikke bruges til at anmode om den tilsvarende ressource. Svar skal returnere et Allow-hoved, der indikerer en liste over kravmetoder, der kan accepteres af den aktuelle ressource. Da PUT og DELETE-metoder skriver til ressourcer på serveren, understøtter de fleste webservere ikke eller giver ikke som standard de ovennævnte kravmetoder, og vil returnere en 405 fejl for sådanne krav. |
| 406 | Indholdets egenskaber for den anmodede ressource opfylder ikke betingelserne i kravhovedet, så en svarentitet kan ikke genereres. Hvis dette ikke er et HEAD-krav, bør svaret returnere en entitet, der giver brugeren eller browseren mulighed for at vælge de mest passende egenskaber for entiteten og adresselisten. Formaten for entiteten bestemmes af medietypen defineret i Content-Typehoved. Browseren kan træffe den bedste beslutning baseret på formatet og sine egne evner. Dog definerer specifikationen ikke nogen kriterier for at foretage sådanne automatiske valg. |
| 407 | Lignende til 401 svar, dog skal klientsiden autentificere på proxyserveren. Proxyserveren skal returnere en Proxy-Autentificer for autentificering. Klientsiden kan returnere en Proxy-Autoriseringshoved for autentificering. Se RFC 2617. |
| 408 | Anmodningen timed out. Klientsiden fuldførte ikke at sende kravet inden serveren var klar til at vente. Klientsiden kan resubmitte kravet på ethvert tidspunkt uden ændringer. |
| 409 | Kravet kan ikke gennemføres på grund af en konflikt med den nuværende tilstand af det anmodede ressource. Denne kode må kun bruges, hvis brugeren antages at kunne løse konflikten og vil resubmitte et nyt krav. Svar bør indeholde nok information, så brugeren kan opdage kilden til konflikten. Konflikter opstår normalt i behandlingen af PUT-krav. For eksempel i en version-kontrolleret miljø, hvis versioninformationen vedhæftet en PUT-indsendte ændringsanmodning for en bestemt ressurs er i konflikt med en tidligere (tredje-parti) anmodning, skal serveren returnere en 409 fejlmeddelelse til brugeren om, at anmodningen ikke kunne gennemføres.
På dette tidspunkt er det sandsynligt, at responsentiteten indeholder en sammenligning af forskelle mellem de to konflikterende versioner, så brugeren kan indsende den samlede version igen. |
| 410 | Den anmodede ressurs er ikke længere tilgængelig på serveren og har ingen kendt viderekoblingsadresse. Denne tilstand bør betragtes som permanent. Hvis muligt, skal klienten med linkredigeringsfunktioner fjerne alle referencer til denne adresse med brugerens tilladelse. Hvis serveren ikke kender eller ikke kan bestemme, om denne tilstand er permanent, så en 404 statuskode skal bruges. Hvis ikke andet er angivet, er dette svar cachebart. Formålet med 410 svar bruges primært til at hjælpe webmasteren med at vedligeholde hjemmesiden, informere brugeren om, at ressourcen ikke længere er tilgængelig, og at serverejeren ønsker, at alle eksterne forbindelser til denne ressurs skal slettes.
Denne type begivenhed er almindelig i tid-begrænsede, værdi-tilføjede tjenester. Lignende, den 410 svar bruges til at informere klienten om, at ressourcer, der oprindeligt tilhørte en enkelt, ikke længere er tilgængelige på den aktuelle serverside. Selvfølgelig er det helt op til serverejeren, om at markere alle permanent utilgængelige ressourcer som' 410 Gone ', og hvor lang tid skal denne markering beholdes. |
| 411 | Serveren afviser at acceptere anmodningen uden at definere en Indhold-Længdeheader. Efter at have tilføjet gyldig Indhold-Længdeheader, der indikerer længden af anmodningskroppen, klienten kan indsende anmodningen igen. |
| 412 | Serveren mislykkedes med at opfylde en eller flere af forudsætningerne, når de verificerede, at de blev givet i headerfeltet af anmodningen. Denne status kode giver klienten mulighed for at sætte forudsætninger i den anmodede metadata (anmodnings header felt data) når ressourcer hentes, hvilket forhindrer, at anmodningsmetoden anvendes på ressourcer, der ikke er det ønskede. |
| 413 | Serveren afviser at behandle den aktuelle anmodning, fordi anmodningen indsender mere entitetsdata, end serveren er villig 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 denne situation er midlertidig, bør serveren returnere en Retry-Efter respons header til at informere klienten om, hvor meget tid den kan prøve igen. |
| 414 | Den anmodede URI er længere end serveren kan fortolke, så serveren afviser at betjene anmodningen. Dette er sjældent, og almindelige tilfælde inkluderer: En form indsendelse, der skulle have brugt POST-metoden, bliver en GET-metode, hvilket får forespørgselsstrengen (Query String) til at blive for lang. Omdirigerings URI "mørke huller", såsom hver omdirigering bruger den gamle URI som en del af den nye URI, hvilket får URI'en til at blive for lang efter flere omdirigeringer. Klienten forsøger at angribe serveren med sikkerhedshuller, der findes i nogle servere.
Denne type server bruger en fast-længde buffer til at læse eller manipulere den anmodede URI. Når parametrene efter GET overstiger et bestemt værdi, kan der opstå en buffer overflow, hvilket kan føre til uønsket kodeudførelse [1]. Servere uden sådanne sårbarheder skal returnere en 414 status kode. |
| 415 | For metoden på den aktuelle anmodning og den anmodede ressource, er den entitet, der er indsendt i anmodningen, ikke i et format, der støttes af serveren, så anmodningen afvises. |
| 416 | Hvis anmodningen indeholder en Række header, og ingen dataområder specificeret i Række coincidence med den tilgængelige rækkevidde af den aktuelle ressource, og den Hvis-Række header er ikke defineret i anmodningen, serveren skal returnere en 416 status kode. Hvis Range bruger en byte-række, betyder dette situationen, at den første byte-position for alle dataområder specificeret i anmodningen overstiger længden af den aktuelle ressurs. Serveren skal også inkludere en Content-Range entity header sammen med 416 status kode for at indikere længden af den aktuelle ressurs. Denne respons er også forbudt fra at bruge multipart/byteranges som indhold-Type. |
| 417 | Det forventede indhold specificeret i anmodningsheaderen Expect kan ikke opfyldes af serveren, eller serveren er en proxy-server, der har klart bevis for, at det forventede indhold ikke kan opfyldes på næste node i den aktuelle rute. |
| 421 | Antallet af forbindelser til serveren fra Internetsprogadresse, hvor den aktuelle klientside er placeret, overstiger det maksimalt tilladte af serveren. Typisk refererer Internetsprogadresse her til klientside-adressen set fra serveren (som brugerens gateway eller proxy-serveradresse). I dette tilfælde kan forbindelseskontant omfatte mere end én slutbruger. |
| 422 | Antallet af forbindelser til serveren fra Internetsprogadresse, hvor den aktuelle klientside er placeret, overstiger det maksimalt tilladte af serveren. Typisk refererer Internetsprogadresse her til klientside-adressen set fra serveren (som brugerens gateway eller proxy-serveradresse). I dette tilfælde kan forbindelseskontant omfatte mere end én slutbruger. |
| 422 | Anmodningen var korrekt formateret, men kunne ikke besvares på grund af en semantisk fejl. (RFC 4918 WebDAV) 423 Låst Den aktuelle ressurs er låst. (RFC 4918 WebDAV) |
| 424 | Den aktuelle anmodning mislykkedes på grund af en fejl i en tidligere anmodning, såsom PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Defineret i WebDav Avancerede Samlinger-draften, men ikke i WebDAV Sekventiel Samling Protokoll (RFC 3658). |
| 426 | Klientsiden skal skifte til TLS/1.0. (RFC 2817) |
| 449 | Udvidet af Microsoft, skal anmodninger genoptages efter at have udført den nødvendige handling. |
| 500 | Serveren stødte på en uventet situation, der forhindrede den i at fuldføre anmodningen. Generelt opstår dette problem, når serverens kode fejler. |
| 501 | Serveren understøtter ikke en funktion, der kræves af den aktuelle anmodning. Når serveren ikke kan genkende den anmodede metode og ikke kan støtte sin anmodning om nogen ressurs. |
| 502 | Når en server, der fungerer som en gateway eller proxy, forsøger at udføre en anmodning, modtager den en ugyldig respons fra en upstream-server. |
| 503 | Serveren er i øjeblikket ikke i stand til at behandle anmodninger på grund af midlertidig server vedligeholdelse eller overbelastning. Denne tilstand er midlertidig og vil blive genoprettet efter en vis tid. Hvis forsinkelsestiden kan forudsiges, kan svar inkludere en Retry-Efter header til at indikere forsinkelsestiden. Hvis denne Retry-Efter information ikke er givet, skal klienten håndtere det som om det var en 500 svar. Bemærk: Tilstedeværelsen af en 503 status kode betyder ikke, at serveren skal bruge den i tilfælde af overbelastning. Nogle servere ønsker simpelthen at nægte klientens forbindelse. |
| 504 | Når en server, der fungerer som en gateway eller proxy, forsøger at udføre en anmodning, fejler den at modtage et svar fra en upstream server (identificeret ved URI, såsom HTTP, FTP, LDAP) eller en sekundær server (som DNS) i en rettidig måde. Bemærk: Nogle proxy servere returnerer en 400 eller 500 fejl, når DNS forespørgslen udløber |
| 505 | Serveren understøtter ikke, eller afviser at understøtte, versionen af HTTP, der bruges i anmodningen. Dette implikerer, at serveren ikke kan eller vil bruge samme version som klientens side. Svar skal inkludere en enhed, der beskriver, hvorfor versionen ikke understøttes, og hvilke protokoller serveren understøtter. |
| 506 | Udvidet af Gennemsigtig Indholdsnegotiation Protokollen (RFC 2295), dette repræsenterer en intern konfigurationsfejl på serveren: den anmodede forhandling variabel ressource er konfigureret til at bruge sig selv i en gennemsigtig indholdsnegotiation, og derfor er det ikke en passende fokus i en forhandlingsproces. |
| 507 | Serveren kan ikke gemme indholdet, der er nødvendigt for at fuldføre anmodningen. Denne tilstand betragtes som midlertidig. WebDAV (RFC 4918) |
| 509 | Serveren har nået båndbreddsgrænsen. Dette er ikke en officiel status kode, men det bruges stadig bredt. |
| 510 | De politikker, der kræves for at opnå ressourcer, er ikke opfyldt. (RFC 2774) |
