| HTTP Statuskode |
Statuskode Beskrivelse |
| 100 |
Klienten skal fortsætte med at sende anmodningen. Dette midlertidige svar er til for at informere klienten om, at dens delvise anmodning allerede er blevet modtaget af serveren og endnu ikke er blevet afvist. Klienten skal fortsætte med at sende den resterende del af anmodningen, eller hvis anmodningen er færdig, ignorere dette svar. Serveren skal sende et endeligt svar til klienten, når anmodningen er fuldført. |
| 101 |
Serveren har forstået klientens anmodning og vil informere klienten om at bruge en anden protokol til at fuldføre anmodningen via Upgrade headeren. Efter den sidste tomme linje i dette svar vil serveren skifte til de protokoller, der er defineret i Upgrade headeren. Sådanne foranstaltninger bør kun tages, når det er fordelagtigt at skifte til en ny protokol, som f.eks. at opgradere til en nyere HTTP-version sammenlignet med en ældre version, eller skifte til en realtidsprotocol der ændrer data, der drager fordel af denne type funktioner. |
| 102 |
En statuskode udvidet af WebDAV (RFC 2518), der angiver, at behandlingen fortsat vil blive udført. |
| 200 |
Anmodningen var vellykket, og de ønskede svarhuvuder eller data vil blive sendt til denne anmodning. |
| 201 |
Anmodningen er blevet gennemført, og en ny ressource er blevet oprettet i overensstemmelse med anmodningens krav, og dens URI er blevet sendt tilbage via Location headeren. Hvis den ønskede ressource ikke kan oprettes med det samme, skal der returneres '202 Accepted'. |
| 202 |
Serveren har accepteret anmodningen, men har endnu ikke behandlet den. Men som det kunne blive afvist, kan den pågældende anmodning heller ikke udføres. I tilfælde af asynkrone operationer kan der ikke være nogen løsning, der er mere praktisk end at sende denne statuskode. Formålet med at returnere et svar med statuskode 202 er at tillade serveren at acceptere anmodninger til andre procedurer (f.eks. en batchoperatør, der kun kører én gang dagligt), uden at klienten skal opretholde en forbindelse til serveren, indtil batchoperationen er færdigbehandlet. Et svar, der accepterer anmodningen og returnerer statuskode 202, skal indeholde nogle oplysninger i den returnerede enhed, der angiver den nuværende behandlingsstatus, samt oplysninger om monitorering af status eller statusforudsigelse, så brugerne kan estimere, om operationen er afsluttet. |
| 203 |
Serveren har behandlet anmodningen, men de returnerede metadata er ikke en gyldig bestemt samling på originalserveren, men snarere en kopi fra lokal eller tredjeparter. De nuværende oplysninger kan være et subset eller superset af den originale version. F.eks. kan metadata, der indeholder ressourcen, føre til, at originalserveren er klar over metadataets overordnede. Det er ikke obligatorisk at bruge denne statuskode, og det er kun passende, når et svar ellers ville returnere 200 OK, hvis det ikke blev brugt. |
| 204 |
Serveren har behandlet anmodningen, men behøver ikke at returnere noget enhedsindhold og ønsker at returnere opdaterede metadata. Svaret kan returnere nye eller opdaterede metadata i form af enhedshoved. Hvis disse header-informationer eksisterer, skal de svare til de ønskede variable. Hvis klienten er en browser, bør brugeren af browseren holde den side, der sendte anmodningen, uden at ændre visning af dokumentet, selvom de nye eller opdaterede oplysninger i henhold til standarden bør anvendes på dokumentet i brugerens visning af aktiviteter i deres browser. Da svaret 204 er forbudt fra at inkludere nogen beskedbro, slutter det altid med den første tomme linje efter headerne. |
| 205 |
Serveren har behandlet anmodningen vellykket, men har ikke returneret noget indhold. I modsætning til svaret 204 kræver dette svar, at anmoderen nulstiller visningen af dokumentet. Dette svar bruges primært efter brugerinput for hurtigt at nulstille en formular, så brugeren kan starte en ny adgang. Ligesom svar 204 er dette også forbudt for at inkludere et beskedbro, og det slutter med den første tomme linje efter headerne. |
| 206 |
Serveren har med succes behandlet dele af GET-anmodningen. HTTP-download værktøjer som FlashGet eller Thunder bruger sådanne svar til at opnå breakpoint-genoptagelse eller bryde et stort dokument op i flere downloadssegmenter til samtidig at blive downloaded. Anmodningen skal inkludere Range headeren for at indikere det ønskede indholdsområde til klienten og kan også indeholde If-Range som betingelse. Svaret skal indeholde følgende headerfelter: Content-Range for at angive det returnerede indholdsområde i dette svar; hvis det er multipart/byteranges indholdstypen for flere downloads, skal hver multipart-del også indeholde Content-Range felter til at angive dette segments indholdsområde. Hvis svaret indeholder Content-Length, skal værdien svare til det faktiske antal bytes i det returnerede indholdsområde. Date, ETag og/eller Content-Location, hvis den samme anmodning skulle returnere et 200 svar. Expires, Cache-Control og/eller Vary, hvis værdierne kan være forskellige fra andre svar med de axiomatiske variabler. Hvis dette svar anvendte If-Range stærk cachevalidering, må dette svar ikke indeholde nogen yderligere enhedshoveder; hvis anmodningen for dette svar anvendte If-Range svag cachevalidering, er dette svar forbudt mod at inkludere yderligere enhedshoveder; dette forhindrer uoverensstemmelser mellem cache-t indhold og opdaterede metadata. Ellers skal dette svar inkludere alle enhedshoveder, der skal returneres i et 200 svar. Hvis ETag eller Last-Modified headers ikke matcher nøjagtigt, må klientens cache ikke kombinere indholdet fra svaret i 206 med noget cachede indhold tidligere. Enhver cache, der ikke understøtter Range og Content-Range headers, må ikke cache indholdet fra et svar i 206. |
| 207 |
En statuskode udvidet af WebDAV (RFC 2518), der indikerer den følgende enhed skal være et XML-dokument, og som muligvis indeholder en række uafhængige svarkoder afhængigt af antallet af tidligere underanmodninger. |
| 300 |
Den anmodede ressource har en række alternative svar, hver med sin egen adresse og browserdrevne handelsinformation. Brugere eller browsere kan vælge en foretrukken adresse til omdirigering. Medmindre det er en HEAD-anmodning, skal dette svar også indeholde en ressourceattribut og en liste over adresserede enheden, så brugerne eller browsere kan vælge den mest passende omdirigering. Formatet på denne enhed defineres af det af Content-Type angivne format. Browsere kan automatisk træffe det mest passende valg baseret på svarets format og browserens egne evner. Selvfølgelig specificerer RFC 2616 ikke, hvordan en sådan automatisk valg skal foregå. Hvis serveren allerede har en foretrukken feedbackmulighed, skal dette URI for feedback angives i Location headeren; browsere kan tage denne Location værdi som automatisk omdirigeringsadresse. Desuden, medmindre andet er angivet, er dette svar også cache-bart. |
| 301 |
Den anmodede ressource er permanent flyttet til en ny placering, og i fremtiden bør ethvert henvisende til denne ressource anvende en af de URI'er, der returneres i dette svar. Hvis det er muligt, bør klienter med linkredigeringsmuligheder automatisk ændre den anmodede adresse til den adresse, der returneres fra serveren. Desuden, medmindre andet er angivet, er dette svar også cache-bart. Den nye permanente URI skal returneres i Location feltet af svaret. Medmindre dette er en HEAD-anmodning, skal svaret enhed indeholde et hyperlink til den nye URI og en kort beskrivelse. Hvis det ikke er en GET eller HEAD anmodning, forbyder browseren automatisk omdirigering medmindre der er givet brugerens samtykke, da anmodningsbetingelserne kunne ændre sig. Bemærk: For nogle browsere, der bruger HTTP/1.0-protokoller, når de sender POST-anmodninger, og modtager et 301 svar, bliver det efterfølgende omdirigerede anmodning en GET-anmodning. |
| 302 |
Den anmodede ressource reagerer nu temporært fra en anden URI. Da en sådan omdirigering er midlertidig, bør klienten fortsætte med at sende senere anmodninger til den originale adresse. Dette svar kan kun være cachebart, når det er specifiYret i Cache-Control eller Expires. Den nye midlertidige URI skal returneres i Location feltet af svaret. Medmindre det er en HEAD-anmodning, skal svaret enhed indeholde et hyperlink til den nye URI samt en kort beskrivelse. Hvis det ikke er en GET eller HEAD anmodning, forbyder browseren automatisk omdirigering medmindre der er givet brugerens samtykke, da anmodningsbetingelserne kunne ændre sig. Bemærk: Selvom RFC 1945 og RFC 2068 specifikationen ikke tillader klienten at ændre forespørgselens metode ved omdirigering, ser mange eksisterende browsere på en 302 svar som en 303 svar og tilgår den URI, der er angivet i Location, ved at ignorere den oprindelige metode. Statuskoderne 303 og 307 blev tilføjet for at præcisere, hvilken respons serveren forventer fra klienten. |
| 303 |
Svaret til den aktuelle anmodning kan findes ved den anden URI, og klienten bør tilgå den ressource ved hjælp af metoden GET. Denne metode er primært for at tillade redirektering af outputs fra POST-anmodninger genereret ved scripts til nye ressourcer. Den nye URI repræsenterer ikke erstatningen for den originale ressource. Samtidig er svar koden 303 forbudt fra at blive cachet. Naturligvis kan den anden anmodning (omdirigeringen) blive cachet. Den nye URI skal returneres i Location feltet af svaret. Medmindre dette er en HEAD-anmodning, skal svaret enhed indeholde et hyperlink til den nye URI samt en kort beskrivelse. Bemærk: Mange browsere, der er før version HTTP/1.1, kan ikke korrekt forstå statuskode 303. Hvis det er nødvendigt at tage hensyn til de interaktioner med sådanne browsere, kan statuskode 302 være tilstrækkelig, da de fleste browsere behandler en 302 svar på samme måde som den behavior, der kræves af specifikationen for 303 svar. |
| 304 |
Hvis klienten sender en betinget GET-anmodning, og anmodningen er blevet accepteret, og indholdet af dokumentet (siden sidst besøgte eller efter betingelsen i anmodningen) ikke er ændret, bør serveren returnere denne statuskode. Svar med statuskode 304 er forbudt at inkludere nogen meddelelser; de slutter derfor altid med den første tomme linje efter headerne. Dette svar skal indeholde følgende header oplysninger: Dato, medmindre serveren ikke har et ur. Hvis serveren uden et ur stadig overholder disse regler, kan proxyservere og klienter tilføje Date-feltet til de modtagne svar headere (som angivet i RFC 2068 ), og caching-mekanismen vil fungere korrekt. ETag og/eller Content-Location, hvis den samme forespørgsel bør have returneret et 200 svar. Expires, Cache-Control og/eller Vary, hvis deres værdier kan være forskellige fra de tidligere svar med den samme variabel. Hvis denne anmodning bruger stærk cache validering, bør dette svar ikke indeholde andre enhedshoveder; ellers, hvis anmodningen til dette svar afslører en betinget GET, som bruger svag caching, bør dette svar forbyde at inkludere andre enhedshoveder; dette forhindrer uoverensstemmelser mellem det cachede indhold og de opdaterede enhedshoveder. Hvis en 304 svar indikerer, at der aktuelt er en enhed, der ikke er cachet, skal cache-systemet ignorere dette svar og gentag sende en anmodning uden begrænsning. Hvis der modtages en 304 svar, der kræver opdatering af en cachepost, skal cache-systemet opdatere hele posten for at afspejle alle de felter, der er blevet opdateret i svaret. |
| 305 |
Den anmodede ressource skal tilgås via den angivne proxy. Location feltet giver URI oplysning om den specifikke proxy, og modtageren skal sende endnu en anmodning separat for at tilgå resurcen gennem denne proxy. Kun den originale server kan etablere en 305 svar. Bemærk: RFC 2068 specificerer ikke klart, at et 305 svar er til omdirigering af en separat anmodning og kan kun etableres af den originale server. At ignorere sådanne begrænsninger kan føre til alvorlige sikkerhedsrisici. |
| 306 |
I den nyeste specifikation er statuskode 306 ikke længere i brug. |
| 307 |
Den anmodede ressource reagerer nu temporært fra en anden URI. Da en sådan omdirigering er midlertidig, bør klienten fortsætte med at sende efterfølgende anmodninger til den originale adresse. Kun hvis der er angivet cache-control eller expires, er dette svar cachebart. Den nye midlertidige URI skal returneres i Location feltet af svaret. Medmindre dette er en HEAD-anmodning, skal svaret indeholde enhed der henviser til den nye URI samt en kort forklaring. Da nogle browsere ikke kan registrere 307 svar, er det nødvendigt at inkludere disse oplysninger for at hjælpe brugeren med at forstå og anmode om adgang til den nye URI. Hvis det ikke er en GET eller HEAD anmodning, forbyder browseren automatisk omdirigering, medmindre der gives eget samtykke, da anmodningsbetingelserne kan ændre sig. |
| 400 |
1. Semantikken er ukorrekt, og den nuværende anmodning kan ikke forstås af serveren. Medmindre det rettes, bør klienten ikke gentage anmodningen. 2. Anmodningsparameterne er forkerte. |
| 401 |
Den nuværende anmodning kræver brugerautentifikation. Dette svar bør indeholde en WWW-Authenticate header der er relevant for den ønskede ressource for at spørge brugeren information. Klienten kan gentage anmodningen med en passende Authorization header. Hvis den nuværende anmodning allerede inkluderer en Authorization certifikat, repræsenterer 401 svaret at serverens verifikation har afvist disse certifikater. Hvis 401 svaret indeholder den samme godkendelse forespørgsel som den forrige, og browseren allerede har forsøgt verificeringen mindst én gang, skal browseren vise enheden informationen i svaret, da denne enhed kan indeholde diagnosticeringsoplysninger. Se RFC 2617. |
| 402 |
Denne statuskode er forbeholdt fremtidige krav. |
| 403 |
Serveren har forstået anmodningen men nægter at udføre den. I modsætning til 401 svaret hjælper godkendelsen ikke, og anmodningen bør ikke gentages. Hvis dette ikke er en HEAD anmodning, og serveren ønsker at give en forklaring om, hvorfor anmodningen ikke kan udføres, bør det ske i enheden. Selvfølgelig kan serveren også returnere et 404 svar, hvis den ikke ønsker at give noget information til klienten. |
| 404 |
Anmodningen fejlede, og den ønskede ressource kunne ikke findes på serveren. Ingen oplysninger kan fortælle brugeren, om denne tilstand er midlertidig eller permanent. Hvis serveren kender situationen, skal den bruge statuskode 410 for at informere, at den gamle ressource på grund af en eller anden intern konfigurationsproblematik permanent ikke længere er tilgængelig og der ikke er en alternativ adresse. Statuskode 404 anvendes bredt, når serveren ikke ønsker at afsløre, hvorfor anmodningen blev nægtet,eller der ingen anden passende svar er tilgængelig. |
| 405 |
Anmodningsmetoden specificeret i anmodningslinjen kan ikke anvendes til at anmode om den passende ressource. Dette svar bør returnere en Allow header, der angiver den liste over anmodningsmetoder, som den aktuelle ressource kan modtage. Da PUT og DELETE metoder vil ændre serverressourcer, tillader de fleste web-servere ikke eller begrænser disse anmodninger i deres standard konfiguration, og der returneres derfor en 405 fejl for sådanne anmodninger. |
| 406 |
Indholdsegenskaberne i den anmodede ressource kan ikke opfylde betingelserne i anmodningshovedene og kan derfor ikke generere en svar enhed. Medmindre det er en HEAD anmodning, skal svaret returnere en enhed, der indeholder egenskaber og adresser, som giver brugeren eller browseren mulighed for at vælge den mest passende enhed. Formatet af enheden bestemmes af den medie-type, der defineres i Content-Type headeren. Browsere kan automatisk vælge det bedste valg baseret på formatet og deres egne funktioner. Men specifikationen definerer ikke nogen standarder for at lave sådanne automatiske valg. |
| 407 |
Som 401 svaret, men klienten skal godkendes via en proxy. Proxyserveren skal returnere en Proxy-Authenticate for at stille spørgsmål. Klienten kan sende en Proxy-Authorization header til validering. Se RFC 2617. |
| 408 |
Anmodningen er udløbet. Klienten har ikke sendt en anmodning inden serverens forberedelse havde ventet. Klienten kan når som helst genindsende denne anmodning uden ændringer. |
| 409 |
Anmodningen kan ikke fuldføres på grund af en konflikt med den nuværende tilstand af den anmodede ressource. Denne kode må kun bruges i de tilfælde, hvor brugeren forventes at kunne løse konflikten og derefter genindsende en ny anmodning. Svaret skal give tilstrækkelige oplysninger til at hjælpe brugeren med at spore kilden til konflikten. Konflikter opstår normalt ved behandling af PUT anmodninger. Hvis der er en konflikt mellem versionsinformation, der vedrører eventuelle modificeringer foretaget til en bestemt ressource og en tidligere (tredje part) anmodning, bør serveren returnere en 409 fejl for at advare brugeren om, at anmodningen ikke kan gennemføres. I sådanne tilfælde vil svaret muligvis indeholde en forskel mellem de to konfliktende versioner for at hjælpe brugeren med at genindsende en kombination af den nye version. |
| 410 |
Den anmodede ressource er ikke længere tilgængelig på serveren og der er ingen kendte videresendelser. Denne situation skal betragtes som permanent. Hvis det er muligt, skal klienten, der har redigeringsmuligheder for links, efter at have fået brugerens samtykke, fjerne alle referencer til denne adresse. Hvis serveren ikke ved eller ikke kan bekræfte, om denne situation er permanent, bør den anvende statuskode 404. Medmindre andet specificeres, er dette svar cachebart. Formålet med 410 svar er primært at hjælpe webstedsejere med at administrere webstedet og underrette brugerne, at ressourcen ikke længere er tilgængelig og at server ligeledes ejer at ønske, at alle henvisninger til denne ressource fjernes. Denne hændelse er meget almindelig i tidsbegrænsede, værditilføjede tjenester. Ligeledes bruges statuskode 410 også til at informere klienter om, at en personlig ressource ikke længere er tilgængelig på den aktuelle server. Selvfølgelig afhænger det af webstedsejerens discretion, hvorvidt alle permanente ubrugelige ressourcer skal mærkes som '410 Gone' og hvor længe denne markering bør opretholdes. |
| 411 |
Serveren nægter at acceptere anmodningen uden at have defineret en Content-Length header. Klienten kan gentage anmodningen, efter at den effektive Content-Length header er tilføjet for at angive længden af anmodningens beskedindhold. |
| 412 |
Serveren kunne ikke opfylde en eller flere af de forudsætninger, der er angivet i anmodningshovedene. Denne statuskode giver klienten mulighed for at specificere forudsætninger i anmodningsmetadata (anmodningshoveddata) ved at hente ressourcen for at undgå anvendelse af den ønskede metode på det uønskede indhold. |
| 413 |
Serveren nægter at behandle den aktuelle anmodning, da den indsendte enhedsdataoversigt overskrider, hvad serveren er villig eller i stand til at håndtere. I denne situation kan serveren lukke forbindelsen for at forhindre klienten i at fortsætte med at sende denne anmodning. Hvis denne situation er midlertidig, skal serveren returnere et Retry-After header for at informere klienten om, hvornår de kan forsøge igen. |
| 414 |
Den anmodede URI-længde overstiger den længde, som serveren er i stand til at fortolke, så serveren nægter at levere den pågældende anmodning. Dette er sjældent, og de typiske situationer inkluderer: formularindsendelse, der skulle have brugt POST metode, der er blevet til GET, hvilket resulterer i en for lang forespørgsel (Query String); en redirect URI "blackhole," hvor den gamle URI anvendes som en del af den nye URI ved hver omdirigering, hvilket resulterer i en overdrevent lang URI efter flere omdirigeringer; klient, der forsøger at udnytte sikkerhedsfejl i specifikke servere med faste længde buffer til læsning eller håndtering af anmodninger, når GET-parameterne overstiger en bestemt værdi kan det føre til buffer overflow, hvilket kan tillade uønsket kode at blive udført[1]. Servere uden sådanne sårbarheder bør tilbageholde statuskode 414. |
| 415 |
For den aktuelle anmodningsmetode og den anmodede ressource, er den enhed, der er blevet sendt i anmodningen, ikke et format, der understøttes på serveren, hvilket gør anmodningen ugyldig. |
| 416 |
Hvis anmodningen indeholder en Range header, og nogen dataområder specificerede i Range overlap ikke med det nuværende Ressource tilgængelige område, og der ikke er angivet nogen If-Range header i anmodningen, bør serveren returnere statuskode 416. Hvis Range bruger byteområde, refererer denne situation til, at den specifikke startbyteposition for alle dataområder, der er specificerede, overstiger den nuværende ressource-længde. Serveren bør også inkludere en Content-Range header i svaret for at angive ressourcens længde. Dette svar må heller ikke anvende multipart/byteranges som sin Content-Type. |
| 417 |
Indholdet, der er angivet i anmodningshovedet Expect, kan ikke opfyldes af serveren, eller hvis denne server er en proxy, har det tydelig evidens for, at det, der er anmodet i det næste kæde af ruter, ikke kan opfyldes. |
| 421 |
Antallet af forbindelser fra den nuværende IP-adresse til serveren overstiger den maksimale anbefaling fra serveren. Typisk refererer denne IP-adresse til den client adresse, der ses fra serverens synspunkt (som brugerens gateway eller proxyserver adresse). I denne situation kan tællingen af forbindelser involvere mere end én bruger. |
| 422 |
Anmodningen er korrekt formateret, men indeholder semantiske fejl, og kan derfor ikke besvares (RFC 4918 WebDAV). 423 Låst, den aktuelle ressource er låst (RFC 4918 WebDAV). |
| 424 |
Den nuværende anmodning mislykkedes på grund af en fejl i en tidligere anmodning, for eksempel PROPPATCH (RFC 4918 WebDAV). |
| 425 |
Defineret i WebDav Advanced Collections-dokumentet, men ikke optræder i “WebDAV-sequence protocol” (RFC 3658). |
| 426 |
Klienten bør skifte til TLS/1.0 (RFC 2817). |
| 449 |
Udvidelse af Microsoft, og indikerer, at anmodningen bør gentages efter den passende operation er blevet udført. |
| 500 |
Serveren har mødt en uventet tilstand, der forhinder, at anmodningen bliver behandlet. Generelt ville dette problem opstå når der er fejl i serverens kode. |
| 501 |
Serveren understøtter ikke en funktion krævet af den nuværende anmodning. Når serveren ikke kan genkende den anmodede metode, og ikke kan støtte en ønsket anmodning til nogen ressourcer. |
| 502 |
Som serveren fungerer som gateway eller proxy, mislykkedes det at modtage en uvalid besvarelse fra en upstream server, der forsøgte at behandle anmodningen. |
| 503 |
Serveren kan ikke i øjeblikket behandle anmodningen på grund af midlertidig vedligeholdelse af serveren eller overbelastning. Denne situation er midlertidig og må forventes at blive genoprettet efter en tid. Hvis forsinkelsen kan forventes, bør svaret inkludere en Retry-After header for at angive tidspunktet for forsinkelsen. Uden denne Retry-After information, skal klienten behandle svaret 500 som et resultat. Bemærk: Tilstedeværelsen af statuskode 503 betyder ikke, at serveren skal bruge dette svar ved overbelastning. Nogle servere vil bare nægte klientens forbindelse. |
| 504 |
Som server, der fungerer som gateway eller proxy, når tjenerne forsøgte at udføre en anmodning, modtages senest en uvalid respons fra en upstream server (den server, hvis URI er identificeret, f.eks. HTTP, FTP, LDAP) eller fra en assistent-server (f.eks. DNS). Bemærk: Nogle proxyservere vil returnere 400 eller 500 fejl, når DNS-forespørgslen overskrider timeout. |
| 505 |
Serveren understøtter ikke eller nægter at understøtte den HTTP-version, der anvendes i anmodningen. Dette indikerer, at serveren ikke kan eller ikke er villig til at bruge den samme version som klienten. Svaret bør indeholde en beskrivelse af, hvorfor versionen ikke understøttes, samt hvilke protokoller serveren understøtter. |
| 506 |
Udvidet af “Transparent Content Negotiation Protocol” (RFC 2295), der indikerer en intern konfigurationsfejl på serveren: den anmodede forhandlingsopgave ressource er konfigureret til at bruges selv i den transparente indhold forhandling, hvorfor det ikke kan optræde som et relevant fokus i en forhandling. |
| 507 |
Serveren kan ikke gemme indhold, der skal bruges til at afslutte anmodningen. Denne situation betragtes som midlertidig. WebDAV (RFC 4918) |
| 509 |
Serveren har nået båndbreddelimit. Dette er ikke en officiel statuskode, men bruges stadig bredt. |
| 510 |
Politikkerne, der kræves for at få adgang til ressourcen, er ikke opfyldt (RFC 2774). |