| HTTP statuskode | Statuskodebetydning |
|---|
| 100 | Klienten skal fortsette å sende forespørsler. Denne midlertidige svaret brukes til å informere klienten om at noen av hans forespørsler har blitt mottatt av serveren og ikke avvist. Klienten skal fortsette å sende resten av forespørselen, eller ignorere svaret hvis forespørselen er fullført. Serveren må sende et endelig svar til klienten etter at forespørselen er fullført. |
| 101 | Serveren har forstått klientens forespørsel og vil informere klienten gjennom Upgrade-hode om å bruke en annen protokoll for å fullføre forespørselen. Etter å ha sendt den siste tomme linjen i svaret, vil serveren bytte til de protokollene som er definert i Upgrade-hode. Slike tiltak bør bare tas når overgangen til en ny protokoll er mer gunstig. For eksempel har overgangen til en ny HTTP-versjon fordeler over en gammel versjon, eller overgangen til en virkelig-tid og synkron protokoll for å levere ressurser som utnytter slike funksjoner. |
| 102 | Statuskoden utvidet av WebDAV (RFC 2518) indikerer at behandlingen vil fortsette. |
| 200. | Forespørselen var vellykket, og de ønskede responshode eller datakroppene returneres med svaret. |
| 201 | Forespørselen er fullført, og en ny ressurs er opprettet basert på kravene i forespørselen, og dens URI er returnert med Location-hode. Hvis den nødvendige ressursen ikke kan opprettes i tide,'202 Accepted' bør returneres. |
| 202 | Serveren har akseptert forespørselen, men den har ennå ikke behandlet den. Akkurat som den kan bli avvist, kan forespørselen enten eller ikke utføres til slutt. I tilfelle asynkrone operasjoner, er det ingen mer praktisk måte å gjøre dette på enn å sende denne statuskoden. Formålet med å returnere en 202 statuskode-svar for å tillate serveren å akseptere forespørsler fra andre prosesser (som en batch-enhetlig operasjon som utføres bare én gang om dagen) uten å måtte holde klienten tilkoblet til serveren inntil batch-operasjonen er fullført. Som svar på å akseptere en forespørsel om behandling og returnere en 202 statuskode, bør den returnerte entiteten inkludere noen informasjon som indikerer den nåværende tilstanden til prosessen, samt en peker til prosessstatusovervåkeren eller statusprognosen, slik at brukeren kan estimere om operasjonen er fullført. |
| 203 | Serveren har behandlet forespørselen med suksess, men den returnerte entitetshode meta-informasjonen er ikke en gyldig bestemt setning på kilde-serveren, men en lokal eller tredjeparts-partskopi. Den nåværende informasjonen kan være en delmengde eller en overdelmengde av den opprinnelige versjonen. For eksempel kan metadata som inneholder ressurser forårsake at kilde-serveren vet om meta super. Bruk av denne statuskoden er ikke påkrevd og er bare passende hvis svaret returnerer 200 OK uten denne statuskoden. |
| 204 | Serveren behandlet forespørselen med suksess, men trenger ikke returnere noen fysisk innhold, og ønsker å returnere oppdatert metadata. Svaret kan være i form av en entitetshode, returnere nye eller oppdaterte metadata. Hvis denne headerinformasjonen eksisterer, bør den korrespondere med den forespurte variabelen. Hvis klienten er en nettleser, bør brukerens nettleser beholde siden som sendte forespørselen uten noen endringer i dokumentvisningen, selv om nye eller oppdaterte metadata skal anvendes på dokumentet i brukerens nettlesers aktive visning i henhold til spesifikasjonen. Siden den 204 svar er forbudt fra å inkludere noen meldingskropp, det slutter alltid med den første blanke linjen etter header. |
| 205 | Serveren behandlet forespørselen med suksess og returnerte ingenting. Men i motsetning til den 204 Respons, svaret som returnerer denne statuskoden krever at forespørselen returnerer dokumentvisningen. Dette svar brukes hovedsakelig til å nullstille skjemaet umiddelbart etter at brukerinput er akseptert slik at brukeren enkelt kan starte en annen input. Som den 204 svar, dette svaret er også forbudt fra å inkludere noen meldingskropp og slutter med den første blanke linjen etter hodet. |
| 206 | Serveren har vellykket behandlet en del av GET-forespørselen. HTTP nedlastingsverktøy som FlashGet eller Xunlei bruker denne typen svar for å implementere en brodd fortsettelse eller for å bryte et stort dokument opp i flere nedlastingssegmenter for samtidig nedlasting. Forespørselen må inneholde et Range-hode for å indikere innholdsspekteret som klientsiden ønsker, og kan inkludere If-Range som en forespørselsbetingelse. Svaret må inneholde følgende hodefelt: Content-Range for å indikere innholdsspekteret som returneres i dette svaret; hvis det er et multi-segment nedlasting med Content-Type multipart/byteranges, bør hver delmengde inneholde en Content-Range-feltet for å indikere innholdsspekteret for denne segmentet. Hvis svaret inneholder Content-Length, så må verdien matche det faktiske antallet byte i innholdsspekteret den returnerer. Dato ETag og/eller Content-Location, hvis samme forespørsel skulle ha returnert en 200-svar. Expires, Cache-Kontroll, og/eller Vary, hvis verdien kan være annerledes enn verdien som samsvarer med andre svar til samme variabel før. Hvis dette svar forespørselen bruker If-Range sterk cache validering, så bør dette svaret ikke inkludere andre enhetshoder; hvis dette svar forespørselen bruker If-Range svak cache validering, så bør dette svaret ikke inkludere andre enhetshoder; dette unngår inkonsekvenser mellom cached enhetsinnhold og oppdaterte enhetshodeinformasjon. ellers, bør dette svaret inneholde alle enhetshodefelt som bør returneres i en 200-svar. Hvis ETag eller Last-Modified-hoder som ikke matcher nøyaktig, klientsiden cache bør forby kombinasjon av innholdet som returneres i 206 svar med noe som tidligere er cached. Enhver cache som ikke støtter Range og-Range-hodelet er forbudt fra å cache innholdet som returneres av 206 svar. |
| 207 | En statuskode utvidet av WebDAV (RFC 2518) representerer at kroppen til det følgende meldingen vil være en XML-melding, og kan inneholde en rekke uavhengige responskoder avhengig av antallet tidligere under-forespørsler. |
| 300 | Den forespurte ressursen har et utvalg av tilbakemeldingsalternativer, hver med sin egen spesifikke adresse og nettleser-drevet forhandling informasjon. Brukeren eller nettleseren kan velge en foretrukket adresse for omdirigering. Hvis dette ikke er en GET- eller HEAD-forespørsel, er nettleseren forbudt fra å automatisk omdirigere med mindre det bekreftes av brukeren, da betingelsene for forespørselen kan endre seg som et resultat. Merk: For noen nettlesere som bruker HTTP-Type. Nettleseren kan automatisk gjøre det mest passende valget basert på formatet til responsen og nettleserens egne evner. Selvfølgelig, RFC 2616 spesifikasjonen ikke spesifiserer hvordan denne automatiske valgprosessen skal utføres. Hvis serveren selv allerede har en foretrukket tilbakemeldingsvalg, bør URI-en for tilbakemeldingen spesifiseres i Location; nettlesere kan bruke denne Location-verdien som adressen for automatisk omdirigering. I tillegg, hvis ikke annet er spesifisert, er responsen også cachebar. |
| 301 | Den forespurte ressursen er permanent flyttet til en ny plass, og alle fremtidige referanser til denne ressursen bør bruke en av flere URI-er som returneres av denne responsen. Hvis mulig, bør klienten med lenkeediteringsfunksjoner automatisk endre den forespurte adressen til adressen returnert fra serveren. Hvis ikke annet er spesifisert, er denne responsen også cachebar. Den nye permanente URI-en bør returneres i Location-feltet i responsen. Hvis dette ikke er en HEAD-forespørsel, bør responsen inneholde en enhet med en liste over ressursattributter og adresser fra hvor brukeren eller nettleseren kan velge den mest passende omdirigeringsadressen. Formatet for denne enheten bestemmes av formatet definert av Content/1.0-protokollen, når de sender en POST-forespørsel og får en 301 svar, vil den påfølgende omdirigeringsforespørselen bli GET. |
| 302 | Den forespurte ressursen svarer nå midlertidig på forespørselen fra en annen URI. Siden slike omdirigeringer er midlertidige, bør klienten fortsette å sende fremtidige forespørsler til den opprinnelige adressen. Dette svaret kan lagres i cache bare hvis spesifisert i Cache-Kontroll eller Utløpsdato. Den nye midlertidige URI-en skal returneres i Lokasjon-feltet i svaret. Hvis dette ikke er en HEAD-forespørsel, skal svarentiteten inneholde en hyperlenke til den nye URI-en og en kort beskrivelse. Hvis dette ikke er en GET- eller HEAD-forespørsel, forbyr nettleseren automatisk omdirigering med mindre bekreftet av brukeren, da betingelsene for forespørselen kan endre seg som et resultat. Merk: Selv om RFC 1945 og RFC 2068 spesifikasjoner tillater ikke klienten å endre forespørselsmetoden når det omdirigeres, mange eksisterende nettlesere behandler 302 svar som en 303 svar og bruk GET for å få tilgang til URI som spesifisert i Lokasjon, og ignorere den opprinnelige forespørselsmetoden. Statuskoder 303 og 307 ble lagt til for å klargjøre hva serveren forventer fra klienten. |
| 303 | svar på den gjeldende forespørselen kan finnes på en annen URI, og klienten bør GET tilgang til denne ressursen. Denne metoden finnes hovedsakelig for å tillate skript-aktivert POST-forespørsel utdata skal omdirigere til en ny ressurs. Denne nye URI er ikke en erstatningsreferanse til den opprinnelige ressursen. Også, 303 svar er forbudt å lagre. Selvfølgelig, en annen forespørsel (omdirigering) kan lagres. Nytt URI skal returneres i feltet Location i svaret. Unntatt dette er en HEAD-forespørsel, bør responsen inneholde en hyperlinke til det nye URI og en kort beskrivelse. Merk: Mange nettlesere før HTTP/1.1 ikke forstår 303 status korrekt. Hvis du trenger å vurdere interaksjon med disse nettleserne, er 302 statuskode bør være tilstrekkelig, fordi de fleste nettlesere håndterer 302 svar på nøyaktig samme måte som ovenstående spesifikasjon krever at klienten håndterer 303 svar. |
| 304 | Hvis klienten sender en betinget GET-forespørsel og forespørselen har blitt tillatt, og innholdet i dokumentet ikke har endret seg (siden forrige besøk eller i henhold til betingelsene for forespørselen), bør serveren returnere denne statuskoden. 304 svar er forbudt å inkludere meldingskropp, så alltid slutt med den første blanke linjen etter header. Svaret må inneholde følgende headerinformasjon: Date, med mindre denne serveren har ingen klokke.
Hvis serveren uten klokke også følger disse reglene, kan proxyserveren og klienten selv legge til feltet Date i mottatt svarheader (som spesifisert i RFC 2068), og caching-mekanismen vil fungere bra. ETag og/eller Content-Location, hvis samme forespørsel skulle ha returnert en 200-svar. Expires, Cache-Kontroll, og/eller Vary, hvis verdien kan være annerledes enn verdien som samsvarer med andre svar til samme variabel tidligere.
Hvis dette svarforespørsel bruker sterk cachevalidering, bør dette svaret ikke inneholde andre enhetsheader; ellers (for eksempel, en betinget GET-forespørsel bruker svak cachevalidering), er det forbudt å inkludere andre enhetsheader; dette unngår inkonsekvenser mellom lagret enhetsinnhold og oppdatert enhetsheaderinformasjon. Hvis en 304 respons indikerer at en enhet ikke er tilgjengelig i cache, må caching-systemet ignorere responsen og sende gjentatte forespørsler uten restriksjoner.
Hvis en 304 respons mottas for å oppdatere en lagret post, må caching-systemet oppdatere hele posten for å reflektere verdiene for alle felt som ble oppdatert i responsen. |
| 305 | Den forespurte ressursen må nå tilgjengelig gjennom den spesifiserte proxyen. URI-informasjonen for den spesifiserte proxyen gis i Location-feltet. Mottakeren må sende en separat forespørsel flere ganger for å få tilgang til den tilsvarende ressursen gjennom denne proxyen. Kun killetjeneren kan opprette en 305 respons. Merk: Det er ingen uttrykkelig 305 respons i RFC 2068 til å omdirigere en enkelt forespørsel, og det kan bare opprettes av killetjeneren. Ignorering av disse restriksjonene kan føre til alvorlige sikkerhetskonsekvenser. |
| 306 | I den nyeste versjonen av spesifikasjonen, 306 statuskode lenger brukes. |
| 307 | Den forespurte ressursen svarer nå midlertidig på forespørselen fra en annen URI. Siden slike omdirigeringer er midlertidige, skal klienten fortsette å sende fremtidige forespørsler til den opprinnelige adressen. Denne responsen kan bare lagres i cache hvis spesifisert i Cache-Kontroll eller Expires. Den nye midlertidige URI-en skal returneres i Location-feltet i responsen. Med mindre dette er en HEAD-forespørsel, skal den responsende entiteten inneholde en hyperlenke som peker til den nye URI-en og en kort beskrivelse. Siden noen nettlesere ikke gjenkjenner 307 respons, må ovennevnte informasjon legges til slik at brukeren kan forstå og be om tilgang til den nye URI.
Hvis dette ikke er en GET- eller HEAD-forespørsel, forbyr nettleseren automatisk omdirigering med mindre brukeren bekrefter det, siden forespørselens betingelser kan endre seg som et resultat. |
| 400 | 1. Semantikkene er feil, og den nåværende forespørselen kan ikke forstås av serveren. Med mindre den endres, bør klienten ikke sende inn forespørselen igjen. 2. Forespørselsparametrene er feil. |
| 401 | den nåværende forespørselen krever brukerautentisering. Svaret må inneholde en WWW-Authenticate-hode for den forespurte ressursen for å be brukeren om informasjon. Klienten kan sende inn en ny forespørsel med riktig Authorization-hodeinformasjon. Hvis den nåværende forespørselen allerede inneholder Authorization-sertifikater, så 401 svar representerer at serveren har avvist disse sertifikatene. Hvis den 401 svar inneholder samme autentiseringsforespørsel som det tidligere svaret, og nettleseren har forsøkt autentisering minst én gang, så nettleseren bør vise brukeren enhetsinformasjonen som er inneholdt i svaret, siden denne enhetsinformasjonen kan inneholde relevant diagnostisk informasjon. Se RFC 2617. |
| 402 | Denne statuskoden er reservert for mulige fremtidige krav. |
| 403 | serveren har forstått forespørselen, men nektet å utføre den. I motsetning til en 401 svar, autentisering hjelper ikke, og forespørselen bør ikke gjentas. Hvis dette ikke er en HEAD-forespørsel, og serveren vil kunne forklare hvorfor forespørselen ikke kan utføres, så bør grunnen til avvisningen beskrives innenfor enheten. Selvfølgelig kan serveren også returnere en 404 svar hvis den ikke vil at klienten skal få noen informasjon. |
| 404 | forespørselen mislyktes, og den ønskede ressursen ble ikke funnet på serveren. Det er ingen informasjon som kan fortelle brukeren om tilstanden er midlertidig eller permanent. Hvis serveren er klar over situasjonen, the 410 status code bør brukes til å informere den gamle ressursen om at den er permanent utilgjengelig på grunn av en intern konfigurasjonsmekanisme og har ingen adresse å hoppe til. The 404 status code brukes vanligvis når serveren ikke vil avsløre hvorfor forespørselen ble avvist eller ingen annen passende respons er tilgjengelig. |
| 405 | Den forespurte metoden i forespørselslinjen kan ikke brukes til å forespørre den tilsvarende ressursen. Svar må returnere et Allow-hode som indikerer en liste over forespørselsmetoder som kan aksepteres av den nåværende ressursen. Siden PUT og DELETE-metoder skriver til ressurser på serveren, støtter de fleste webservere ikke eller ikke tillater standarden for ovennevnte forespørselsmetode og vil returnere en 405 feil for slike forespørsler. |
| 406 | Innholdets egenskaper for den forespurte ressursen oppfyller ikke betingelsene i forespørselshodet, så en svarentitet kan ikke genereres. Hvis dette ikke er en HEAD-forespørsel, bør svaret returnere en entitet som gir brukeren eller nettleseren mulighet til å velge de mest passende egenskapene og adresselista. Formatet til entiteten bestemmes av medietypen definert i Content-Type-hode. Browseren kan gjøre det beste valget basert på formatet og sine egne evner. Imidlertid definerer spesifikasjonen ingen kriterier for å gjøre slike automatiske valg. |
| 407 | Lignende til 401 svar, med unntak av at klienten må autentisere på proxy-serveren. Proxy-serveren må returnere en Proxy-Autentiser for autentisering. Klienten kan returnere en Proxy-Autorisasjonshode for autentisering. Se RFC 2617. |
| 408 | Forespørselen timed out. Klienten fullførte ikke sendingen av forespørselen innen den tiden serveren var klar til å vente. Klienten kan sende inn forespørselen igjen når som helst uten noen endringer. |
| 409 | Forespørselen kan ikke fullføres på grunn av konflikt med den forespurte ressursens nåværende tilstand. Denne koden kan bare brukes hvis det antas at brukeren kan løse konflikten og vil sende inn en ny forespørsel. Svar bør inneholde nok informasjon til at brukeren kan finne årsaken til konflikten. Konflikter oppstår vanligvis i behandlingen av PUT-forespørsler. For eksempel, i en versjon-kontrollert miljø, hvis versjonsinformasjonen knyttet til en PUT-innleverte endringsforespørselen for en bestemt ressurs konflikterer med en tidligere (tredje-part) forespørsel, serveren bør returnere en 409 feilmelding til brukeren om at forespørselen ikke kunne fullføres.
På dette punktet, er det sannsynlig at responsen inneholder en sammenligning av forskjeller mellom de to konflikterende versjonene, slik at brukeren kan resubmittere den sammenslåtte versjonen. |
| 410 | Den forespurte ressursen er ikke lenger tilgjengelig på serveren og har ingen kjent viderekoblingsadresse. Denne tilstanden bør anses som permanent. Hvis mulig, bør klienten med lenkeредigeringsfunksjoner fjerne alle referanser til denne adressen med brukerens tillatelse. Hvis serveren ikke vet eller ikke kan bestemme om denne tilstanden er permanent, så en 404 statuskode bør brukes. Hvis ikke annet er spesifisert, er dette svaret cachebart. Formålet med 410 svar brukes hovedsakelig til å hjelpe webmasteren med å vedlikeholde nettstedet, informere brukeren om at ressursen ikke lenger er tilgjengelig, og at servereieren ønsker at alle eksterne tilkoblinger til denne ressursen skal slettes.
Denne typen hendelse er vanlig i tid-begrenset, verdi-tilleggstjenester. På samme måte som 410 svar brukes til å informere klienten om at ressurser som opprinnelig tilhørte en enkeltperson ikke lenger er tilgjengelige på den nåværende serverplasseringen. Selvfølgelig er det helt opp til servereieren å bestemme om å merke alle permanent utilgjengelige ressurser som' 410 Gone ', og hvor lenge denne merkingen skal beholdes. |
| 411 | Serveren nekter å akseptere forespørselen uten å definere et innhold-Lengdeheader. Etter å ha lagt til gyldig innhold-Lengdeheader som indikerer lengden på forespørselskroppen, klienten kan sende forespørselen igjen. |
| 412 | Serveren klarte ikke å oppfylle en eller flere forutsetninger når de ble verifisert i hodet feltet av forespørselen. Denne statuskoden tillater klienten å sette forutsetninger i forespurte metadata (forespørselshode felt data) når ressurser hentes, og forhindrer dermed at forespørselsmetoden brukes til ressurser som ikke er ønsket. |
| 413 | Serveren nekter å behandle den nåværende forespørselen fordi forespørselen sender mer enhetsdata enn serveren er villig eller i stand til å håndtere. I dette tilfellet kan serveren lukke tilkoblingen for å forhindre at klienten fortsetter å sende forespørselen. Hvis denne situasjonen er midlertidig, bør serveren returnere en Retry-Etter responshode for å informere klienten om hvor mye tid den kan prøve igjen. |
| 414 | Den forespurte URI-en er lengre enn serveren kan tolke, så serveren nekter å behandle forespørselen. Dette er sjeldent, og vanlige tilfeller inkluderer: En skjemaoversendelse som skulle ha brukt POST-metoden blir en GET-metode, noe som gjør at forespørselsstrengen (Query String) blir for lang. OmdirigeringsURI "mørke hull", som hver omdirigering som bruker den gamle URI-en som en del av den nye URI-en, noe som fører til at URI-en blir for lang etter flere omdirigeringer. Kunden forsøker å angripe serveren med sikkerhetsfeil som finnes i noen servere.
Denne typen server bruker en fast-lengdebuffer for å lese eller manipulere den forespurte URI-en. Når parameterne etter GET overstiger et visst verd, kan det oppstå en bufferoverflødig, noe som kan føre til uventet kodeutførelse [1]. Servere uten slike sårbarheter bør returnere en 414 statuskode. |
| 415 | For metoden til den nåværende forespørselen og den forespurte ressursen, er enheten som er sendt i forespørselen ikke i et format som serveren støtter, så forespørselen blir avvist. |
| 416 | Hvis forespørselen inneholder et Rangehode, og ingen dataområder spesifisert i Rangemeldingen samsvarer med tilgjengelig område for den nåværende ressursen, og hvis-Rangehode er ikke definert i forespørselen, serveren bør returnere en 416 statuskode. Hvis Range bruker en bytestrekning, betyr dette at den første bytteposisjonen for alle dataområder spesifisert i forespørselen overskrider lengden på den gjeldende ressursen. Serveren bør også inkludere en Content-Range entity header sammen med 416 statuskode for å indikere lengden på den gjeldende ressursen. Denne responsen er også forbudt fra å bruke multipart/byteranges som innhold-Type. |
| 417 | Ingenting i forespørselsheaderen 'Expect' kan oppfylles av serveren, eller serveren er en proxyserver som har tydelig bevis for at det forventede innholdet ikke kan oppfylles på neste node i den gjeldende ruten. |
| 421 | Antallet tilkoblinger til serveren fra Internettprotokolladressen der den gjeldende klientsiden befinner seg, overskrider det maksimale som serveren tillater. Typisk refererer Internettprotokolladressen her til klientsiden som serveren ser (som brukerens gateway eller proxyserveradresse). I dette tilfellet kan tilkoblingsantallet involvere mer enn én sluttnyttig. |
| 422 | Antallet tilkoblinger til serveren fra Internettprotokolladressen der den gjeldende klientsiden befinner seg, overskrider det maksimale som serveren tillater. Typisk refererer Internettprotokolladressen her til klientsiden som serveren ser (som brukerens gateway eller proxyserveradresse). I dette tilfellet kan tilkoblingsantallet involvere mer enn én sluttnyttig. |
| 422 | Forespørselen var korrekt formateret, men kunne ikke svares på grunn av en semantisk feil. (RFC 4918 WebDAV) 423 Låst Den gjeldende ressursen er låst. (RFC 4918 WebDAV) |
| 424 | Den gjeldende forespørselen mislyktes på grunn av en feil i en tidligere forespørsel, som PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definert i WebDav Avanserte Samlinger-draften, men ikke i WebDAV Sekvensielle Set Protokoll (RFC 3658). |
| 426 | Klientsiden bør bytte til TLS/1.0. (RFC 2817) |
| 449 | Utvidet av Microsoft, forespørsler skal prøves igjen etter å ha utført den nødvendige handlingen. |
| 500 | Serveren møtte en uventet situasjon som forhindret den fra å fullføre forespørselen. Vanligvis oppstår dette problemet når serverens kode feiler. |
| 501 | Serveren støtter ikke en funksjon som kreves av den gjeldende forespørselen. Når serveren ikke kan gjenkjenne den forespurte metoden og ikke kan støtte sin forespørsel om noen ressurs. |
| 502 | Når en server som fungerer som en gateway eller proxy forsøker å utføre en forespørsel, mottar den en ugyldig respons fra en oppstrøms server. |
| 503 | Serveren kan for tiden ikke behandle forespørsler på grunn av midlertidig servervedlikehold eller overbelastning. Denne tilstanden er midlertidig og vil bli gjenopprettet etter en stund. Hvis forsinkelsestiden kan forutsies, kan svaret inkludere en Retry-Etter header for å indikere forsinkelsestiden. Hvis denne Retry-Etter informasjon ikke er gitt, skal klienten håndtere det som om det var en 500-svar. Merk: Tilstedeværelsen av en 503 statuskode betyr ikke at serveren må bruke den i tilfelle overbelastning. Noen servere ønsker bare å nekte klientens tilkobling. |
| 504 | Når en server som fungerer som en gateway eller proxy forsøker å utføre en forespørsel, mislykkes den med å motta et svar fra en oppstrøms server (identifisert av URI, som HTTP, FTP, LDAP) eller en sekundær server (som DNS) i en tilstrekkelig tidsramme. Merk: Noen proxy-servere returnerer en 400 eller 500-feil når DNS-forespørselen utløper |
| 505 | Serveren støtter ikke, eller nekter å støtte, versjonen av HTTP som brukes i forespørselen. Dette innebærer at serveren ikke kan eller vil bruke samme versjon som klienten. Svar bør inkludere en enhet som beskriver hvorfor versjonen ikke støttes og hvilke protokoller serveren støtter. |
| 506 | Utvidet av gjennomsiktig innholdsforklaring protokollen (RFC 2295), dette representerer en intern konfigurasjonsfeil på serveren: den forespurte forhandlingss variable ressurs er konfigurert til å bruke seg selv i en gjennomsiktig innholdsforklaring, og dermed er ikke en passende fokus i en forhandlingsprosess. |
| 507 | Serveren kan ikke lagre innholdet som er nødvendig for å fullføre forespørselen. Denne tilstanden anses som midlertidig. WebDAV (RFC 4918) |
| 509 | Serveren har nådd båndbreddebegrensningen. Dette er ikke en offisiell statuskode, men den brukes fortsatt bredt. |
| 510 | De politikker som kreves for å oppnå ressurser er ikke oppfylt. (RFC 2774) |
