| Http-statuscode | Statuscode Betekenis |
|---|
| 100 | De client moet doorgaan met het verzenden van verzoeken. Dit tijdelijke antwoord wordt gebruikt om de client te informeren dat een deel van zijn verzoek door de server is ontvangen en niet is afgewezen. De client moet doorgaan met het verzenden van de rest van de aanvraag, of dit antwoord negeren als de aanvraag compleet is. De server moet een definitief antwoord naar de client sturen als de aanvraag compleet is. |
| 101 | De server heeft de aanvraag van de client begrepen en zal de client via de Upgrade message header informeren om een ander protocol te gebruiken om de aanvraag te voltooien. Na het verzenden van de laatste lege regel van dit antwoord, schakelt de server over naar de protocollen die zijn gedefinieerd in de koptekst van het Upgrade-bericht. Dit dient alleen te gebeuren als het voordeliger is om over te schakelen naar een nieuw protocol. Het is bijvoorbeeld voordeliger om over te schakelen naar een nieuwe versie van HTTP dan naar een oudere versie, of om over te schakelen naar een realtime en synchroon protocol om bronnen te leveren die gebruik maken van dergelijke functies. |
| 102 | Statuscodes, uitgebreid door WebDAV (RFC 2518), geven aan dat de verwerking zal doorgaan. |
| 200 | Het verzoek is geslaagd en de door het verzoek gewenste antwoordkop of gegevensinhoud zal met dit antwoord worden teruggestuurd. |
| 201 | Het verzoek is uitgevoerd en er is een nieuwe bron aangemaakt zoals vereist door het verzoek en de URI ervan is teruggestuurd met de Location-header. Als de vereiste bron niet op tijd kan worden aangemaakt, moet '202 Accepted' worden teruggestuurd. |
| 202 | De server heeft het verzoek geaccepteerd, maar nog niet verwerkt. Net zoals het kan worden afgewezen, kan het verzoek uiteindelijk wel of niet worden uitgevoerd. In de context van asynchrone operaties is er niets handiger dan het terugsturen van deze statuscode. Het doel van het terugsturen van een antwoord met een 202 statuscode is om de server in staat te stellen verzoeken van andere processen te accepteren (zoals een batchgebaseerde bewerking die slechts eenmaal per dag wordt uitgevoerd) zonder dat de client met de server verbonden hoeft te blijven totdat de batchbewerking volledig is voltooid. Een antwoord dat een verzoek voor verwerking accepteert en een 202 statuscode terugstuurt ZOU in de teruggestuurde entiteit enige informatie moeten bevatten die de huidige status van het proces aangeeft, evenals een pointer naar een verwerkingsstatusmonitor of statusvoorspelling zodat de gebruiker kan inschatten of de bewerking is voltooid. |
| 203 | De server heeft de aanvraag succesvol verwerkt, maar de geretourneerde meta-informatie in de entity header is geen definitieve set die geldig is op de originele server, maar een kopie van een lokale of derde partij. De huidige informatie kan een subset of superset zijn van de originele versie. Bijvoorbeeld, metagegevens die bronnen bevatten kunnen ervoor zorgen dat de originele server de meta-informatie super kent. Het gebruik van deze statuscode is niet verplicht en is alleen gepast als het antwoord zonder deze code 200 OK zou hebben geretourneerd. |
| 204 | De server heeft de aanvraag succesvol verwerkt, maar hoeft geen fysieke inhoud terug te sturen en wil bijgewerkte meta-informatie terugsturen. Het antwoord kan nieuwe of bijgewerkte meta-informatie terugsturen in de vorm van entity headers. Als zulke headers bestaan, moeten ze overeenkomen met de gevraagde variabelen. Als de client een browser is, dan DIENT de browser van de gebruiker de pagina te behouden waarop het verzoek is verzonden zonder enige wijzigingen in de documentweergave, hoewel volgens de specificatie de nieuwe of bijgewerkte meta-informatie MOET worden toegepast op het document in de actieve weergave van de browser van de gebruiker. Aangezien het 204 antwoord geen berichttekst mag bevatten, eindigt het altijd met de eerste lege regel na de koptekst van het bericht. |
| 205 | De server heeft de aanvraag succesvol verwerkt en niets teruggestuurd. In tegenstelling tot het 204 antwoord, vraagt het antwoord dat deze statuscode retourneert de aanvrager echter om de documentweergave opnieuw in te stellen. Deze respons wordt voornamelijk gebruikt om het formulier te resetten onmiddellijk na het accepteren van gebruikersinvoer, zodat de gebruiker gemakkelijk een andere invoer kan starten. Net als het 204 antwoord mag dit antwoord geen berichttekst bevatten en eindigt het met de eerste lege regel na de koptekst van het bericht. |
| 206 | De server heeft met succes een deel van de GET-aanvraag verwerkt. HTTP downloadtools zoals FlashGet of Thunderbolt gebruiken dit type antwoord om onderbroken downloads uit te voeren of om een groot document op te splitsen in meerdere downloadsegmenten tegelijk. Het verzoek moet een Range header bevatten om het bereik van de inhoud aan te geven die de client wil ontvangen, en kan een If-Range bevatten als verzoekvoorwaarde. Het antwoord moet de volgende headervelden bevatten: Content-Range om het bereik aan te geven van de inhoud die wordt teruggestuurd in dit antwoord; in het geval van een download in meerdere segmenten met een Content-Type van multipart/byteranges, moet elk meerdelig segment een veld Content-Range bevatten dat het bereik aangeeft van de inhoud in dat segment. Als het antwoord een Content-Length bevat, moet de waarde daarvan overeenkomen met het werkelijke aantal bytes in het inhoudsbereik dat wordt geretourneerd. date ETag en/of Content-Location, als hetzelfde verzoek een antwoord 200 had moeten teruggeven. Expires, Cache-Control en/of Vary, als hun waarden kunnen verschillen van andere antwoorden met dezelfde variabelen. Expires, Cache-Control en/of Vary, als de waarden ervan kunnen verschillen van de waarden van andere eerdere antwoorden voor dezelfde variabelen. Dit antwoord ZOU GEEN andere entiteitkoppen MOETEN bevatten als het verzoek gebruik maakt van If-Range sterke cachevalidatie, en ZOU GEEN andere entiteitkoppen MOETEN bevatten als het verzoek gebruik maakt van If-Range zwakke cachevalidatie; dit voorkomt inconsistenties tussen gecachete entiteitinhoud en bijgewerkte entiteitkopinformatie. Anders DIENT dit antwoord alle entity header velden te bevatten die geretourneerd hadden moeten worden in alle 200 antwoorden die geretourneerd hadden moeten worden. Als de ETag of Last-Modified headers niet exact overeenkomen, ZOU de client-side cache moeten verbieden om de inhoud die in antwoord 206 wordt geretourneerd te combineren met enige eerder in de cache opgeslagen inhoud. Elke cache die de Range en Content-Range headers niet ondersteunt, mag de inhoud die is teruggestuurd door het 206 antwoord niet cachen. |
| 207 | De statuscode, zoals uitgebreid door WebDAV (RFC 2518), betekent dat de volgende berichttekst een XML-bericht zal zijn en een reeks afzonderlijke responscodes kan bevatten, afhankelijk van het aantal eerdere subverzoeken. |
| 300 | De aangevraagde bron heeft een reeks alternatieve retourberichten, elk met zijn eigen specifieke adres en browsergestuurde onderhandelingsinformatie. De gebruiker of browser kan zelf een voorkeursadres voor omleiding selecteren. Tenzij dit een HEAD-verzoek is, moet het antwoord een entiteit bevatten die een lijst is van bronkenmerken en adressen waaruit de gebruiker of browser het meest geschikte omleidingsadres kan selecteren. Het formaat van deze entiteit wordt bepaald door het formaat van de Content-Type definitie. De browser kan automatisch de meest geschikte selectie maken op basis van het formaat van het antwoord en de eigen mogelijkheden van de browser. Natuurlijk specificeert de RFC 2616 specificatie niet hoe zo'n automatische keuze moet worden gemaakt. Als de server zelf al een voorkeurskeuze heeft voor het retoursignaal, dan moet de URI van dit retoursignaal worden gespecificeerd in Location; de browser kan deze Location-waarde gebruiken als het adres voor automatische doorverwijzing. Daarnaast kan dit antwoord ook in de cache worden opgeslagen, tenzij anders aangegeven. |
| 301 | De aangevraagde bron is permanent verplaatst naar de nieuwe locatie en alle toekomstige verwijzingen ernaar moeten een van de verschillende URI's gebruiken die in dit antwoord zijn teruggestuurd. Indien mogelijk moeten clients met mogelijkheden voor het bewerken van links automatisch het gevraagde adres wijzigen in het adres dat door de server wordt geretourneerd. Dit antwoord kan ook in de cache worden opgeslagen, tenzij anders aangegeven. De nieuwe permanente URI moet worden teruggestuurd in het veld Location van het antwoord. Tenzij dit een HEAD verzoek is, moet de antwoordentiteit een hyperlink naar de nieuwe URI en een korte beschrijving bevatten. Als dit geen GET- of HEAD-verzoek is, mag de browser niet automatisch doorverwijzen tenzij dit door de gebruiker wordt bevestigd, omdat de voorwaarden van het verzoek hierdoor kunnen veranderen. Opmerking: Voor sommige browsers die het HTTP/1.0-protocol gebruiken, geldt dat wanneer ze een POST-verzoek verzenden en een 301-antwoord krijgen, het volgende omleidingsverzoek een GET zal zijn. |
| 302 | De aangevraagde bron antwoordt nu tijdelijk op het verzoek vanaf een andere URI. Aangezien deze omleiding tijdelijk is, moet de client toekomstige verzoeken naar het oorspronkelijke adres blijven sturen. Dit antwoord kan alleen in de cache worden opgeslagen als het is gespecificeerd in Cache-Control of Expires. De nieuwe tijdelijke URI moet worden teruggestuurd in het veld Location van het antwoord. Tenzij dit een HEAD verzoek is, moet de antwoordentiteit een hyperlink naar de nieuwe URI en een korte beschrijving bevatten. Als dit geen GET- of HEAD-verzoek is, is het de browser verboden automatisch door te sturen tenzij dit door de gebruiker wordt bevestigd, omdat de voorwaarden van het verzoek hierdoor kunnen veranderen. Opmerking: Hoewel de RFC 1945- en RFC 2068-specificaties de client niet toestaan om de methode van het verzoek te wijzigen bij het omleiden, behandelen veel bestaande browsers het 302-antwoord als een 303-antwoord en gebruiken ze GET om toegang te krijgen tot de URI die is opgegeven in de Locatie, waarbij de methode van het oorspronkelijke verzoek wordt genegeerd. De statuscodes 303 en 307 zijn toegevoegd om duidelijk te maken welk antwoord de server van de client verwacht. |
| 303 | Het antwoord op het huidige verzoek kan worden gevonden op een andere URI en de client moet die bron benaderen met GET. Deze methode bestaat voornamelijk om de uitvoer van scriptgeactiveerde POST-verzoeken om te leiden naar een nieuwe bron. Deze nieuwe URI is geen alternatieve verwijzing naar de oorspronkelijke bron. Het is ook verboden om het 303 antwoord in de cache te plaatsen. Het tweede verzoek (omleiding) mag natuurlijk wel in de cache worden opgeslagen. De nieuwe URI moet worden teruggestuurd in het veld Location van het antwoord. Tenzij dit een HEAD verzoek is, moet de antwoordentiteit een hyperlink naar de nieuwe URI en een korte beschrijving bevatten. Opmerking: Veel browsers voorafgaand aan HTTP/1.1 versies begrijpen de 303 status niet goed. Als interactie met deze browsers moet worden overwogen, zou de 302 statuscode voldoende moeten zijn, aangezien de meeste browsers het 302 antwoord op precies dezelfde manier afhandelen als de bovenstaande specificatie vereist dat de client het 303 antwoord afhandelt. |
| 304 | De server ZOU deze statuscode moeten retourneren als de client een voorwaardelijke GET-aanvraag verstuurt die is toegestaan en de inhoud van het document (sinds het laatste bezoek of volgens de voorwaarden van de aanvraag) niet is gewijzigd.304 Antwoorden mogen geen berichttekst bevatten en eindigen daarom altijd met de eerste lege regel na de berichtkop. Het antwoord MOET de volgende headers bevatten: Datum, tenzij de server geen klok heeft. Als een server zonder klok deze regels volgt, dan kunnen de proxyserver en de client het veld Datum zelf toevoegen aan de inkomende antwoordkop (zoals gespecificeerd in RFC 2068) en zal het cachingmechanisme correct werken.ETag en/of Content-Location, als hetzelfde verzoek een antwoord 200 zou hebben geretourneerd.Expires Expires, Cache-Control en/of Vary, als de waarde kan verschillen van de waarde die overeenkomt met andere eerdere antwoorden voor dezelfde variabele. Als voor dit antwoordverzoek een sterke cachevalidatie wordt gebruikt, mag dit antwoord geen andere entiteitheaders bevatten; anders (bijvoorbeeld als voor een voorwaardelijk GET-verzoek een zwakke cachevalidatie wordt gebruikt) mag dit antwoord geen andere entiteitheaders bevatten; dit voorkomt inconsistenties tussen de inhoud van entiteiten in de cache en bijgewerkte informatie in de entiteitheaders. Als een 304-antwoord aangeeft dat een entiteit momenteel niet in de cache is opgenomen, moet het caching-systeem het antwoord negeren en het verzoek herhalen zonder de beperking. Als een 304-antwoord wordt ontvangen met het verzoek om een cachegegeven bij te werken, MOET het caching-systeem het volledige gegeven bijwerken om de waarden van alle velden weer te geven die in het antwoord zijn bijgewerkt. |
| 305 | De aangevraagde bron moet worden benaderd via de opgegeven proxy. het veld Locatie geeft informatie over de URI waar de opgegeven proxy zich bevindt. de ontvanger zou herhaaldelijk een afzonderlijk verzoek moeten verzenden om via deze proxy toegang te krijgen tot de bron. Alleen de oorspronkelijke server kan een 305 antwoord maken. Opmerking: Het is niet duidelijk uit RFC 2068 dat een 305-antwoord bedoeld is om een enkel verzoek om te leiden en alleen kan worden gemaakt door de oorspronkelijke server. Het negeren van deze beperkingen kan leiden tot ernstige gevolgen voor de beveiliging. |
| 306 | In de laatste versie van de specificatie wordt de 306 statuscode niet meer gebruikt. |
| 307 | De aangevraagde bron antwoordt nu tijdelijk op het verzoek vanaf een andere URI. Omdat zulke redirects tijdelijk zijn, moeten clients toekomstige verzoeken naar het oorspronkelijke adres blijven sturen. Dit antwoord kan alleen in de cache worden opgeslagen als het is opgegeven in Cache-Control of Expires. De nieuwe tijdelijke URI moet worden teruggestuurd in het veld Location van het antwoord. Tenzij dit een HEAD-verzoek is, moet de antwoordentiteit een hyperlink naar de nieuwe URI en een korte beschrijving bevatten. Omdat sommige browsers het 307 antwoord niet herkennen, moet de bovenstaande informatie worden toegevoegd zodat de gebruiker het kan begrijpen en toegang kan vragen tot de nieuwe URI. Als dit geen GET- of HEAD-verzoek is, verbiedt de browser automatische doorverwijzing, tenzij dit door de gebruiker wordt bevestigd, omdat de voorwaarden van het verzoek kunnen veranderen. |
| 400 | 1. Er is een semantische fout en het huidige verzoek kan niet worden begrepen door de server. Tenzij gewijzigd, mag de client dit verzoek niet herhaaldelijk indienen. 2. De verzoekparameters zijn verkeerd. |
| 401 | Het huidige verzoek vereist gebruikersauthenticatie. Het antwoord moet een WWW-Authenticate-header bevatten voor de aangevraagde bron om gebruikersinformatie te vragen. De client kan herhaaldelijk een verzoek indienen dat de juiste autorisatieheaderinformatie bevat. Als het huidige verzoek al autorisatiegegevens bevat, betekent het 401-antwoord dat de server verifieert dat die gegevens zijn geweigerd. Als het 401 antwoord dezelfde authenticatievraag bevat als het vorige antwoord, en de browser heeft al minstens één authenticatiepoging gedaan, dan ZOU de browser de gebruiker de entiteitsinformatie in het antwoord moeten presenteren, aangezien deze entiteitsinformatie relevante diagnostische informatie kan bevatten. Zie RFC 2617. |
| 402 | Deze statuscode is gereserveerd voor mogelijke toekomstige vereisten. |
| 403 | De server heeft het verzoek begrepen maar weigert het uit te voeren. In tegenstelling tot een 401 antwoord, biedt authenticatie geen hulp en dit verzoek moet niet opnieuw worden ingediend. Als dit geen HEAD verzoek is en de server wil duidelijk kunnen zeggen waarom het verzoek niet kan worden uitgevoerd, dan moet de reden voor de weigering worden beschreven in de entiteit. Natuurlijk kan de server ook een 404 antwoord terugsturen als hij de client geen informatie wil geven. |
| 404 | Het verzoek is mislukt, de gevraagde bron is niet gevonden op de server. Er is geen informatie om de gebruiker te vertellen of de situatie tijdelijk of permanent is. Als de server op de hoogte is van de situatie, moet hij de 410-statuscode gebruiken om de gebruiker te informeren dat de oude bron permanent niet beschikbaar is vanwege een of ander intern configuratiemechanisme en dat er geen omleiding beschikbaar is. 404 wordt veel gebruikt als de server niet wil onthullen waarom de aanvraag is afgewezen of als er geen ander geschikt antwoord beschikbaar is. |
| 405 | De aanvraagmethode die is opgegeven in de aanvraagregel kan niet worden gebruikt om de bijbehorende bron aan te vragen. Het antwoord moet een Allow header terugsturen die de lijst van verzoekmethoden aangeeft die aanvaardbaar zijn voor de huidige bron. Aangezien de PUT- en DELETE-methoden naar de bron op de server schrijven, ondersteunen de meeste webservers deze verzoekmethoden niet of staan ze deze standaard niet toe en retourneren ze een 405-fout voor dergelijke verzoeken. |
| 406 | De inhoudskenmerken van de aangevraagde bron voldoen niet aan de voorwaarden in de verzoekheader en er kan geen antwoordentiteit worden gegenereerd. Tenzij dit een HEAD-verzoek is, moet het antwoord een entiteit retourneren met een lijst van entiteiteigenschappen en -adressen waaruit de gebruiker of browser de meest geschikte kan selecteren. Het formaat van de entiteit wordt bepaald door het mediatype dat is gedefinieerd in de Content-Type header. Browsers kunnen hun eigen beste keuzes maken op basis van het formaat en hun eigen mogelijkheden. De specificatie definieert echter geen criteria voor het maken van dergelijke automatische keuzes. |
| 407 | Vergelijkbaar met het 401 antwoord, behalve dat de client zich MOET authenticeren bij de proxyserver. De proxyserver MOET een Proxy-Authenticate terugsturen voor identiteitsverzoek. De client MOET een Proxy-Authorization header terugsturen voor authenticatie. Zie RFC 2617. |
| 408 | Time-out verzoek. De client heeft het verzenden van een verzoek niet voltooid binnen de tijd die de server bereid was te wachten. De client kan de aanvraag op elk moment opnieuw verzenden zonder wijzigingen aan te brengen. |
| 409 | Het verzoek kon niet worden voltooid vanwege een conflict met de huidige status van de aangevraagde bron. Deze code mag alleen worden gebruikt als de gebruiker in staat wordt geacht het conflict op te lossen en een nieuw verzoek in te dienen. Het antwoord moet voldoende informatie bevatten voor de gebruiker om de bron van het conflict te achterhalen. Conflicten komen meestal voor bij het verwerken van PUT verzoeken. Als bijvoorbeeld in een versiecontroleomgeving de versie-informatie die is gekoppeld aan een PUT die is ingediend om een bepaalde bron te wijzigen, conflicteert met een eerder verzoek (van een derde partij), moet de server een 409-fout terugsturen om de gebruiker te informeren dat het verzoek niet kon worden voltooid. In dit geval bevat de antwoordentiteit waarschijnlijk een vergelijking van de verschillen tussen de twee conflicterende versies, zodat de gebruiker de nieuwe versie opnieuw kan indienen na de samenvoeging. |
| 410 | De aangevraagde bron is niet langer beschikbaar op de server en heeft geen bekend doorstuuradres. Een dergelijke toestand moet als permanent worden beschouwd. Indien mogelijk moeten clients met de mogelijkheid om links te bewerken alle verwijzingen naar dit adres verwijderen met toestemming van de gebruiker. Als de server niet weet of niet kan bepalen of deze toestand permanent is, moet een 404-statuscode worden gebruikt. Tenzij anders aangegeven, kan dit antwoord in de cache worden opgeslagen.410 Het doel van dit antwoord is in de eerste plaats om de webmaster te helpen bij het onderhouden van de site door de gebruiker te informeren dat de bron niet langer beschikbaar is en dat de eigenaar van de server wil dat alle verbindingen op afstand naar deze bron ook worden verwijderd. Dit type gebeurtenis komt vaak voor bij diensten met een beperkte tijd en toegevoegde waarde. Op dezelfde manier wordt het 410-antwoord gebruikt om clients te laten weten dat een bron die oorspronkelijk toebehoorde aan een individu op de huidige serversite niet langer beschikbaar is. Het is natuurlijk volledig aan de eigenaar van de server om te bepalen of alle permanent onbeschikbare bronnen moeten worden gemarkeerd als '410 verdwenen' en hoe lang deze markering moet worden gehandhaafd. |
| 411 | De server weigert verzoeken te accepteren zonder de Content-Length header gedefinieerd. Na het toevoegen van een geldige Content-Length header die de lengte van de berichttekst van het verzoek aangeeft, kan de client het verzoek opnieuw indienen. |
| 412 | De server heeft niet voldaan aan een of meer van de vereisten toen werd geverifieerd of deze waren opgegeven in het headerveld van het verzoek. Met deze statuscode kan de client randvoorwaarden instellen in de metaboodschap van het verzoek (gegevens in het headerveld van het verzoek) bij het verkrijgen van een bron, waardoor wordt voorkomen dat de verzoekmethode wordt toegepast op andere bronnen dan de gewenste inhoud. |
| 413 | De server weigert het huidige verzoek te verwerken omdat het entiteitsgegevens bevat die groter zijn dan de server wil of kan verwerken. In dit geval kan de server de verbinding sluiten om te voorkomen dat de client doorgaat met het verzenden van deze aanvraag. Als deze toestand tijdelijk is, moet de server een Retry-After antwoordkop retourneren om de client te informeren na hoeveel tijd hij opnieuw kan proberen. |
| 414 | De lengte van de URI van het verzoek overschrijdt de lengte die de server kan interpreteren, dus de server weigert het verzoek te verwerken. Dit komt zelden voor en is vaak het geval wanneer een formulier dat de POST-methode had moeten gebruiken, een GET-methode wordt, wat resulteert in een lange querystring. URI-"zwarte gaten", zoals het gebruik van de oude URI als onderdeel van de nieuwe URI bij elke redirect, wat resulteert in een lange URI na meerdere redirects. Klanten proberen servers aan te vallen door kwetsbaarheden in de beveiliging van sommige servers te misbruiken. Dergelijke servers gebruiken een buffer met een vaste lengte om de URI van een verzoek te lezen of te manipuleren, en wanneer de parameters na een GET een bepaalde waarde overschrijden, kan een bufferoverloop optreden, wat leidt tot willekeurige code-uitvoering [1]. Servers zonder dergelijke kwetsbaarheden zouden een 414 statuscode moeten retourneren. |
| 415 | Voor de huidige aangevraagde methode en aangevraagde bron is de entiteit die in het verzoek wordt ingediend niet in een formaat dat door de server wordt ondersteund, dus wordt het verzoek afgewezen. |
| 416 | Als het verzoek een Range-verzoekkop bevat en gegevensbereiken die in de Range zijn gespecificeerd niet overlappen met de bereiken die beschikbaar zijn voor de huidige bron, en de If-Range-verzoekkop niet is gedefinieerd in het verzoek, moet de server een 416-statuscode retourneren. Als Range bytebereiken gebruikt, dan is dit het geval als de eerste bytepositie van alle gegevensbereiken gespecificeerd in het verzoek de lengte van de huidige bron overschrijdt. De server moet ook een Content-Range-entiteitskoptekst opnemen die de lengte van de huidige bron specificeert, samen met de 416-statuscode. Dit antwoord mag ook geen multipart/byteranges gebruiken als Content-Type. |
| 417 | De verwachte inhoud gespecificeerd in de request header Expect kan niet worden vervuld door de server, of deze server is een proxyserver die duidelijk bewijs heeft dat de inhoud van Expect niet kan worden vervuld op het volgende knooppunt in de huidige route. |
| 421 | Het aantal verbindingen met de server vanaf het IP-adres waar de huidige client zich bevindt, overschrijdt het maximum dat door de server wordt toegestaan. Meestal verwijst het IP-adres hier naar het adres van de client zoals gezien vanaf de server (bijvoorbeeld het gateway- of proxyserveradres van de gebruiker). In dit geval kan het aantal verbindingen meer dan één eindgebruiker betreffen. |
| 422 | Het aantal verbindingen met de server vanaf het IP-adres van de huidige client overschrijdt het maximum dat door de server is toegestaan. Het IP-adres verwijst hier meestal naar het adres van de client zoals gezien vanaf de server (bijvoorbeeld het gateway- of proxyserveradres van de gebruiker). In dit geval kan het aantal verbindingen meer dan één eindgebruiker betreffen. |
| 422 | Het verzoek was correct geformatteerd, maar kon niet worden beantwoord omdat het semantische fouten bevatte. (RFC 4918 WebDAV) 423 Vergrendeld De huidige bron is vergrendeld. (RFC 4918 WebDAV) |
| 424 | Het huidige verzoek is mislukt door een fout die zich voordeed in een vorig verzoek, zoals PROPPATCH.(RFC 4918 WebDAV) |
| 425 | Gedefinieerd in de WebDav Advanced Collections draft, maar komt niet voor in het WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Klanten moeten overschakelen naar TLS/1.0.(RFC 2817) |
| 449 | Uitgebreid door Microsoft om aan te geven dat verzoeken opnieuw moeten worden geprobeerd nadat de juiste actie is uitgevoerd. |
| 500 | De server is op een onverwachte omstandigheid gestuit waardoor de verwerking van het verzoek niet kon worden voltooid. Dit probleem doet zich meestal voor bij een fout in de programmacode van de server. |
| 501 | De server ondersteunt een bepaalde functie die vereist is voor de huidige aanvraag niet. Wanneer de server de aangevraagde methode niet herkent en de aanvraag voor een bron niet kan ondersteunen. |
| 502 | Een server die werkt als een gateway of proxy ontvangt een ongeldig antwoord van een upstream server wanneer deze een verzoek probeert uit te voeren. |
| 503 | De server kan het verzoek momenteel niet verwerken vanwege tijdelijk serveronderhoud of overbelasting. Deze toestand is tijdelijk en zal na enige tijd worden hersteld. Als een vertraging kan worden verwacht, kan het antwoord een Retry-After header bevatten om de vertraging aan te geven. Als deze Retry-After informatie niet wordt gegeven, dan moet de client het op dezelfde manier afhandelen als een 500 antwoord. Opmerking: Het bestaan van de 503 statuscode betekent niet dat de server deze moet gebruiken als hij overbelast is. Sommige servers willen de client simpelweg een verbinding weigeren. |
| 504 | Een server die als gateway of proxy werkt en een verzoek probeert uit te voeren, krijgt niet tijdig een antwoord van een upstream server (een server die wordt geïdentificeerd door een URI, zoals HTTP, FTP, LDAP) of een secundaire server (zoals DNS). Opmerking: Sommige proxyservers geven een 400- of 500-fout terug wanneer de DNS-opzoeking wordt onderbroken. |
| 505 | De server ondersteunt de versie van HTTP die in de aanvraag wordt gebruikt niet of weigert deze te ondersteunen. Dit houdt in dat de server niet dezelfde versie kan of wil gebruiken als de cliënt. Het antwoord moet een entiteit bevatten die beschrijft waarom de versie niet wordt ondersteund en welke protocollen de server ondersteunt. |
| 506 | Uitgebreid door het Transparent Content Negotiation Protocol (RFC 2295) om een interne misconfiguratie van de server weer te geven: de gevraagde Negotiation Variant bron is geconfigureerd om zichzelf te gebruiken in transparante inhoudsonderhandeling en is daarom geen geschikte focus in een onderhandelingsproces. |
| 507 | De server is niet in staat de inhoud op te slaan die nodig is om het verzoek te voltooien. Deze voorwaarde wordt als tijdelijk beschouwd.WebDAV (RFC 4918) |
| 509 | De server heeft zijn bandbreedtelimiet bereikt. Dit is geen officiële statuscode, maar wordt nog steeds veel gebruikt. |
| 510 | Er werd niet voldaan aan het beleid dat nodig is om de bron te verkrijgen. (RFC 2774) |