Online Gereedschap
Http-statuscodes 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 is voltooid. 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 laat de client via de Upgrade header weten dat er een ander protocol is gebruikt om de aanvraag te voltooien. Na het verzenden van de laatste lege regel van het antwoord schakelt de server over naar de protocollen die zijn gedefinieerd in de Upgrade-header. Dit dient alleen te gebeuren als het voordeliger is om over te schakelen naar het nieuwe protocol. Bijvoorbeeld, overschakelen naar een nieuwe versie van HTTP kan voordeliger zijn dan een oudere versie, of overschakelen naar een realtime, 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 antwoordkoppen of gegevens worden samen met het antwoord teruggestuurd.
201 Het verzoek is uitgevoerd en een nieuwe bron is aangemaakt als antwoord op het verzoek en de URI ervan is teruggestuurd met de Location-header. Als de aangevraagde bron niet op tijd kan worden aangemaakt, moet het volgende worden teruggestuurd'202 Accepted'。
202 De server heeft het verzoek aanvaard, maar nog niet verwerkt. Net zoals het kan worden afgewezen, kan het verzoek uiteindelijk wel of niet worden uitgevoerd. In het geval van asynchrone operaties is er niets handiger dan het sturen van deze statuscode. Het doel van het retourneren van een 202 antwoord 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 een verbinding met de server hoeft te onderhouden totdat de batchbewerking is voltooid. Een antwoord dat een aanvraag voor verwerking accepteert en een 202 statuscode retourneert, moet in de geretourneerde entiteit enige informatie 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 al dan niet is voltooid.
203 De server heeft de aanvraag succesvol verwerkt, maar de geretourneerde meta-informatie in de hoofding van de entiteit is geen definitieve set die geldig is op de oorspronkelijke server, maar een kopie van een lokale of derde partij. De huidige informatie kan een subset of superset van het origineel zijn. Bijvoorbeeld, metagegevens die bronnen bevatten kunnen ervoor zorgen dat de origin server de super meta-informatie 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 het verzoek met succes verwerkt, maar hoeft geen fysieke inhoud terug te sturen en wil bijgewerkte meta-informatie terugsturen. Het antwoord kan nieuwe of bijgewerkte meta-informatie retourneren in de vorm van entity headers. Als deze headers bestaan, moeten ze overeenkomen met de gevraagde variabelen. Als de client een browser is, DIENT de browser van de gebruiker de pagina te behouden waarop het verzoek is verzonden zonder wijzigingen aan de documentweergave, ook al DIENT de nieuwe of bijgewerkte meta-informatie, volgens de specificatie, te 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 behandelt de aanvraag met succes en stuurt niets terug. 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 bestand op te splitsen in meerdere downloads 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 in dit antwoord wordt geretourneerd, of, in het geval van downloads in meerdere delen met een Content-Type van multipart/byteranges, een Content-Range veld in elk meerdelig segment om het bereik aan te geven 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. Expires, Cache-Control, en/of Vary, als hun waarden kunnen verschillen van de waarden van andere eerdere antwoorden met dezelfde variabelen. Dit antwoord zou geen andere entiteitheaders moeten bevatten als het verzoek een sterke If-Range cache validatie gebruikt, en zou geen andere entiteitheaders moeten bevatten als het verzoek een zwakke If-Range cache validatie gebruikt; dit voorkomt inconsistenties tussen de inhoud van de cache entiteit en de bijgewerkte entiteitheader informatie. Anders DIENT dit antwoord alle entity header velden te bevatten die teruggestuurd hadden moeten worden in het 200 antwoord. Als de ETag of Last-Modified headers niet exact overeenkomen, moet de client-side cache het combineren van de in antwoord 206 geretourneerde inhoud met eerder in de cache opgeslagen inhoud weigeren. Elke cache die de Range en Content-Range headers niet ondersteunt, mag de inhoud die wordt teruggestuurd door het 206 antwoord niet cachen.
207 Statuscodes uitgebreid door WebDAV(RFC 2518) De statuscode, zoals uitgebreid door WebDAV, 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 antwoorden, elk met zijn eigen specifieke adres en browsergestuurde onderhandelingsinformatie. Het is aan de gebruiker of browser om een voorkeursadres voor omleiding te kiezen. 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 kiezen. 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 deze automatische selectie moet worden gedaan. Als de server zelf al een voorkeursoptie voor retourneren heeft, moet de URI van het retourneren worden opgegeven in de Location; browsers kunnen deze Location-waarde gebruiken als het adres voor automatisch doorsturen. Bovendien kan het antwoord 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 teruggestuurd. 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 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. Het antwoord is alleen cachable 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 om automatisch door te sturen tenzij dit door de gebruiker wordt bevestigd, aangezien 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 tijdens 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 uitvoer van scriptgeactiveerde POST-verzoeken om te leiden naar een nieuwe bron. Deze nieuwe URI is geen vervangende verwijzing naar de oorspronkelijke bron. Ook mag het 303 antwoord niet in de cache worden opgeslagen. 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 begrijpen de 303 status niet goed. Als interactie met deze browsers moet worden overwogen, zou de 302 statuscode moeten werken, omdat de meeste browsers het 302 antwoord op precies dezelfde manier afhandelen als de bovenstaande specificatie vereist dat de cliënt het 303 antwoord afhandelt.
304 Deze statuscode moet door de server worden teruggestuurd als de client een voorwaardelijk GET-verzoek stuurt en het verzoek is toegestaan, en de inhoud van het document niet is gewijzigd (sinds het laatste bezoek of volgens de voorwaarden van het verzoek). 304 antwoorden mogen geen berichttekst bevatten en eindigen daarom altijd met de eerste lege regel na de header van het bericht. Het antwoord moet de volgende headerinformatie 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 header van het antwoord (zoals gespecificeerd in RFC 2068) en zal het cachingmechanisme goed werken.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 de waarden van andere eerdere antwoorden met dezelfde variabelen. Als het antwoordverzoek een sterke cachevalidatie gebruikt, mag het antwoord geen aanvullende entiteitheaders bevatten; anders (bijvoorbeeld een voorwaardelijk GET-verzoek gebruikt een zwakke cachevalidatie) mag het antwoord geen aanvullende entiteitheaders bevatten; dit voorkomt inconsistenties tussen inhoud van entiteiten in de cache en bijgewerkte informatie van 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 een opgegeven proxy. Het veld Locatie geeft informatie over de URI van de opgegeven proxy en de ontvanger moet herhaaldelijk een afzonderlijk verzoek 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 aangemaakt door de origin server. Het negeren van deze beperkingen kan ernstige gevolgen hebben voor de beveiliging.
306 In de nieuwste versie van de specificatie wordt de 306 statuscode niet langer gebruikt.
307 Aangevraagde bronnen reageren nu tijdelijk op verzoeken van verschillende URI's. Omdat deze omleiding tijdelijk is, 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, is het nodig om de bovenstaande informatie toe te voegen 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, semantische fout, het huidige verzoek kan niet worden begrepen door de server. Tenzij gewijzigd, mag de client het verzoek niet herhalen. 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 opnieuw een verzoek indienen met de juiste autorisatieheaderinformatie. Als het huidige verzoek al autorisatiegegevens bevat, betekent een 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 moet de browser de gebruiker de entiteitsinformatie in het antwoord tonen, 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 moet het verzoek niet opnieuw worden ingediend. Als dit geen HEAD verzoek is en de server wil kunnen zeggen waarom het verzoek niet kan worden uitgevoerd, dan moet de reden van weigering worden beschreven in de entiteit. Natuurlijk kan de server ook een 404 antwoord terugsturen als hij niet wil dat de client informatie krijgt.
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 server 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 het verzoek 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 of staan de meeste webservers deze standaard niet toe en geven ze een 405-fout terug 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 die de meest geschikte entiteitkenmerken bevat en een lijst met adressen waaruit de gebruiker of browser kan kiezen. Het formaat van de entiteit wordt bepaald door het mediatype dat is gedefinieerd in de Content-Type header. De browser kan de beste keuze maken op basis van het formaat en zijn 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 kan een Proxy-Authorisation-header voor authenticatie terugsturen. Zie RFC 2617.
408 Time-out verzoek. De client heeft een verzoek niet voltooid binnen de tijd die de server bereid was te wachten. De client kan de aanvraag op elk moment opnieuw indienen zonder wijzigingen aan te brengen.
409 De aanvraag 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 vaak voor bij het verwerken van PUT verzoeken. In een versiecontroleomgeving bijvoorbeeld, zou een PUT die wordt ingediend om een bepaalde bron met versie-informatie te wijzigen die conflicteert met een eerder verzoek (van een derde partij) een 409-fout moeten 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, samengevoegde versie opnieuw kan indienen.
410 De aangevraagde bron is niet langer beschikbaar op de server en er is geen doorstuuradres bekend. Een dergelijke situatie moet als permanent worden beschouwd. Indien mogelijk moeten clients met bewerkingsmogelijkheden voor links alle verwijzingen naar dit adres verwijderen met toestemming van de gebruiker. Als de server niet weet of niet kan bepalen of de toestand permanent is, moet een 404-statuscode worden gebruikt. Tenzij anders aangegeven, kan dit antwoord in de cache worden opgeslagen. Het doel van het 410-antwoord is in de eerste plaats om de webmaster te helpen de site te onderhouden door de gebruiker te informeren dat de bron niet langer beschikbaar is en dat de eigenaar van de server wil dat alle externe verbindingen met de 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 de client te laten weten dat een bron van een individu niet langer beschikbaar is op de huidige serverlocatie. Natuurlijk is de vraag of alle permanent onbeschikbare bronnen als zodanig gemarkeerd moeten worden, en hoe lang ze zo moeten worden bewaard, ook belangrijk.'410 Gone'， en hoe lang dit zo moet blijven is geheel aan de server eigenaar.
411 De server weigert verzoeken te accepteren zonder de Content-Length header gedefinieerd. De client kan het verzoek opnieuw indienen na het toevoegen van een geldige Content-Length header die de lengte van de berichttekst van het verzoek aangeeft.
412 De server heeft bij het valideren van de aanvraag niet voldaan aan een of meer van de vereisten in het headerveld van de aanvraag. Met deze statuscode kan de client randvoorwaarden instellen in de meta-informatie 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 meer fysieke gegevens bevat 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 de aanvraag. Als de situatie tijdelijk is, moet de server een Retry-After header terugsturen om de client te informeren hoeveel tijd hij heeft om het opnieuw te proberen.
414 De URI van het verzoek is langer dan de server kan interpreteren, dus de server weigert het verzoek te verwerken. Dit komt zelden voor en gebeurt meestal 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 voor 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 aangevraagde URI te lezen of te manipuleren, wat kan resulteren in een bufferoverloop wanneer de GET-parameter een bepaalde waarde overschrijdt, wat kan leiden 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 en wordt het verzoek afgewezen.
416 Als het verzoek een Range-verzoekheader bevat en gegevensbereiken die in de Range zijn gespecificeerd niet samenvallen met de bereiken die beschikbaar zijn voor de huidige bron, en het verzoek geen If-Range-verzoekheader bevat, moet de server een 416-statuscode retourneren. Als Range bytebereiken gebruikt, betekent dit dat de eerste byte 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 de 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 naar de server vanaf het IP-adres van de huidige client 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 er meer dan één eindgebruiker betrokken zijn bij het tellen van de verbindingen.
422 Het aantal verbindingen van het huidige IP-adres van de client naar de server overschrijdt het maximum dat door de server is toegestaan. Het IP-adres verwijst hier meestal naar het adres van de client gezien vanaf de server (bijvoorbeeld het gateway- of proxyserveradres van de gebruiker). In dit geval kan er meer dan één eindgebruiker betrokken zijn bij het tellen van de verbinding.
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) 423 Vergrendeld
424 Het huidige verzoek is mislukt door een fout 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 onvoorziene omstandigheid gestuit waardoor de verwerking van de aanvraag niet kon worden voltooid. Dit probleem doet zich meestal voor bij een fout in de programmacode van de server.
501 De server ondersteunt een functie die vereist is door 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 aanvraag probeert uit te voeren.
503 De server kan de aanvraag momenteel niet verwerken door tijdelijk onderhoud of overbelasting van de server. Deze toestand is tijdelijk en wordt na een bepaalde tijd 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 gewoon een verbinding weigeren.
504 Een server die als gateway of proxy fungeert en een verzoek probeert uit te voeren, krijgt geen tijdig 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 Transparent Content Negotiation 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 aan het verzoek te voldoen. Deze toestand 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 is niet voldaan aan het beleid dat nodig is om de bron te verkrijgen. (RFC 2774)
Toegang tot dossiers: