| HTTP statuscode | Betekenis van statuscode |
|---|
| 100 | De clientzijde moet blijven verzenden van verzoeken. Dit tijdelijke antwoord wordt gebruikt om de clientzijde te informeren dat sommige van zijn verzoeken zijn ontvangen door de server en niet zijn afgewezen. De clientzijde moet blijven verzenden van de rest van het verzoek, of het antwoord negeren als het verzoek is voltooid. De server moet een laatste antwoord naar de clientzijde sturen nadat het verzoek is voltooid. |
| 101 | De server heeft het verzoek van de client begrepen en zal de client-side informeren via de Upgrade-header om een ander protocol te gebruiken om het verzoek te voltooien. Na het sturen van de laatste lege regel in de respons, zal de server overschakelen naar die protocollen die zijn gedefinieerd in de Upgrade-header. Dergelijke maatregelen zouden alleen moeten worden genomen wanneer het overschakelen naar een nieuw protocol meer voordelen biedt. Bijvoorbeeld, het overschakelen naar een nieuwe HTTP-versie heeft voordelen ten opzichte van een oude versie, of het overschakelen naar een écht-tijd- en synchrone protocol om bronnen te leveren die gebruik maken van dergelijke functies. |
| 102 | De statuscode die is uitgebreid door WebDAV (RFC 2518) geeft aan dat de verwerking zal worden voortgezet. |
| 200. | Het verzoek was succesvol, en de gewenste response headers of data bodies worden geretourneerd met de respons. |
| 201 | Het verzoek is vervuld, en een nieuwe bron is gecreëerd op basis van de vereisten van het verzoek, en zijn URI is geretourneerd met de Location-header. Als de vereiste bron niet op tijd kan worden gecreëerd, '202 Geaccepteerd' zou moeten worden geretourneerd. |
| 202 | De server heeft het verzoek geaccepteerd, maar heeft het 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 geen handiger manier om dit te doen dan deze statuscode te sturen. Het doel van het retourneren van een 202 statuscode-reactie om de server toe te staan verzoeken van andere processen (zoals een batch) te accepteren.-eenmalige uitvoering die alleen eenmaal per dag wordt uitgevoerd) zonder dat de client-side verbonden hoeft te blijven met de server totdat de batch-uitvoering is voltooid. Als reactie op het accepteren van een verzoek voor verwerking en het retourneren van een 202 statuscode, de geretourneerde entiteit zou enige informatie moeten bevatten die de huidige staat van het proces aangeeft, evenals een verwijzing naar de processtatusmonitor of statusvoorspelling, zodat de gebruiker kan inschatten of de operatie is voltooid. |
| 203 | De server heeft de aanvraag succesvol verwerkt, maar de geretourneerde entiteitkop metainformatie is niet een geldige deterministische set op de oorspronkelijke server, maar een lokale of derde-partijkopie. De huidige informatie kan een subset of superset zijn van de oorspronkelijke versie. Bijvoorbeeld, metadata die bronnen bevat, kan ervoor zorgen dat de oorspronkelijke server de meta-super kent. Het gebruik van deze statuscode is niet vereist en is alleen geschikt als het antwoord 200 OK zonder deze statuscode. |
| 204 | De server heeft de aanvraag succesvol verwerkt, maar hoeft geen fysieke inhoud te retourneren en wil bijgewerkte metainformatie retourneren. Het antwoord kan de vorm van een entiteitkop zijn, die nieuwe of bijgewerkte metainformatie retourneert. Als deze headerinformatie bestaat, moet deze overeenkomen met de aangevraagde variabele. Als de clientkant een browser is, dan moet de gebruikersbrowser de pagina die de aanvraag verzond onveranderd behouden zonder enige wijzigingen in de documentweergave, zelfs als de nieuwe of bijgewerkte metainformatie volgens de specificatie zou moeten worden toegepast op het document in de actieve weergave van de gebruikersbrowser. Omdat de 204 antwoord is verboden om enige berichtkop te bevatten, het eindigt altijd met de eerste lege regel na de header. |
| 205 | De server heeft de aanvraag succesvol verwerkt en niets geretourneerd. Maar in tegenstelling tot de 204 Antwoord, het antwoord dat deze statuscode retourneert, vereist dat de aanvrager het documentweergave opnieuw instelt. Dit antwoord wordt voornamelijk gebruikt om het formulier onmiddellijk na het accepteren van gebruikersinput opnieuw in te stellen, zodat de gebruiker gemakkelijk een nieuwe input kan starten. Net zoals de 204 reactie bevatten, deze reactie is ook verboden om een berichtlichaam op te nemen en eindigt met de eerste lege regel na de header. |
| 206 | De server heeft succesvol een deel van de GET-verzoek verwerkt. HTTP download tools zoals FlashGet of Xunlei gebruiken dit type reactie om een onderbreking voortzetting of om een groot document in meerdere downloadsegmenten op te splitsen om tegelijkertijd te downloaden. Het verzoek moet een Range header bevatten om het bereik van de inhoud aan te geven dat de clientkant wilt, en mag If-Range als een verzoeksvoorwaarde. De reactie moet de volgende headervelden bevatten: Content-Range om het bereik van de inhoud die in deze reactie wordt geretourneerd aan te geven; als het een multi-segment download met Content-Type multipart/byteranges bevat, moet elk onderdeel van de multipart een Content-Range veld om het inhoudsgebied van dit segment aan te geven. Als de reactie Content-Lengte gebruikt, dan moet zijn waarde overeenkomen met het daadwerkelijke aantal bytes in het inhoudsgebied dat het retourneert. Datum ETag en/of Content-Location, als dezelfde verzoek zou moeten terugkeren met een 200 antwoord. Expires, Cache-Control, en/of Vary gebruikt, als zijn waarde mogelijk anders kan zijn dan de waarde die corresponds met andere reacties op dezelfde variabele voordien. Als deze reactieverzoek If-Range sterke cache validatie, dan zou deze reactie geen andere entiteit headers moeten bevatten; als deze reactieverzoek If-Range zwakke cache validatie, dan zou deze reactie geen andere entiteit headers moeten bevatten; dit voorkomt inconsistenties tussen gecachte entiteit inhoud en bijgewerkte entiteit headerinformatie. Anders zou deze reactie alle entiteit headervelden moeten bevatten die zouden moeten worden geretourneerd in een 200 reactie verbieden. Als de ETag of Last-Modified headers ondersteunt en die niet exact overeenkomen, moet de client-side cache het combineren van de inhoud geretourneerd in de 206 reactie op te slaan in een cache met eerdere gecachte inhoud. Elke cache die geen Range en de Content-Het Range header is verboden om de inhoud die wordt geretourneerd door de 206 reactie. |
| 207 | Een statuscode uitgebreid door WebDAV (RFC 2518) vertegenwoordigt dat het lichaam van het volgende bericht een XML-bericht zal zijn, en kan een reeks onafhankelijke responscodes bevatten afhankelijk van het aantal vorige sub-verzoeken. |
| 300 | Het opgevraagde bron heeft een reeks feedbackopties, elk met zijn eigen specifieke adres en browser-ge drive onderhandeling informatie. De gebruiker of browser kan een voorkeursadres voor omleiding kiezen. Tenzij dit een HEAD-verzoek is, moet de respons een entiteit bevatten met een lijst van resource-eigenschappen en adressen uit waaruit de gebruiker of browser de meest geschikte omleidingsadres kan kiezen. Het formaat van deze entiteit wordt bepaald door het formaat dat is gedefinieerd door Content-Type. De browser kan automatisch de meest geschikte keuze maken op basis van het formaat van de respons en de eigen capaciteiten van de browser. Natuurlijk, de RFC 2616 specificatie geeft niet aan hoe dergelijke automatische selectie moet worden uitgevoerd. Als de server zelf al een voorkeurskeuze voor feedback heeft, moet de URI van de feedback worden gespecificeerd in het Locatieveld; browsers kunnen deze Locatie-waarde gebruiken als adres voor automatische omleiding. Bovendien is de respons ook cachebaar, tenzij anders aangegeven. |
| 301 | Het opgevraagde bron is permanent verplaatst naar een nieuwe locatie, en alle toekomstige verwijzingen naar deze bron moeten gebruik maken van een van de meerdere URI's die door deze respons worden geretourneerd. Indien mogelijk, moet de clientkant met linkeditiercapaciteiten automatisch het opgevraagde adres wijzigen naar het adres dat van de server wordt geretourneerd. Tenzij anders aangegeven, is deze respons ook cachebaar. De nieuwe permanente URI moet worden geretourneerd in het Locatieveld van de respons. Tenzij dit een HEAD-verzoek is, moet de responsentiteit een hyperlink bevatten naar de nieuwe URI en een korte beschrijving bevatten. Als dit geen GET- of HEAD-verzoek is, is de browser verboden om automatisch om te leiden tenzij dit door de gebruiker wordt bevestigd, omdat de voorwaarden van het verzoek kunnen veranderen als gevolg hiervan. Opmerking: Voor sommige browsers die de HTTP-specificatie gebruiken/1.0 protocol, wanneer ze een POST-verzoek sturen en krijgen een 301 reactie, de volgende doorgaan-verzoek zal GET zijn. |
| 302 | De vereiste bron reageert nu tijdelijk op het verzoek van een andere URI. Aangezien dergelijke doorgaan naar een andere URI tijdelijk zijn, zou de klantzijde in de toekomstige verzoeken moeten blijven sturen naar het oorspronkelijke adres. Deze reactie is alleen opslaan in de cache mogelijk als dit is gespecificeerd in Cache-Control of Expires. De nieuwe tijdelijke URI moet worden geretourneerd in het Locatieveld van de reactie. tenzij dit een HEAD-verzoek is, moet de reactieentiteit een hyperlink bevatten naar de nieuwe URI en een korte beschrijving. Als dit geen GET- of HEAD-verzoek is, verbiedt de browser automatisch doorgaan tenzij bevestigd door de gebruiker, omdat de voorwaarden van het verzoek kunnen veranderen als gevolg hiervan. Opmerking: Hoewel de RFC 1945 en RFC 2068 specificaties laten niet toe dat de klantzijde de methode van het verzoek wijzigt bij het doorgaan, veel bestaande browsers behandelen de 302 reactie als een 303 reactie en gebruik GET om toegang te krijgen tot de URI die in de Location is gespecificeerd, de oorspronkelijke verzoekmethode negerend. Statuscodes 303 en 307 toegevoegd om te verduidelijken wat de server van de klantzijde verwacht. |
| 303 | de reactie op het huidige verzoek kan worden gevonden op een andere URI, en de klantzijde moet toegang krijgen tot die bron via GET. Deze methode bestaat voornamelijk om script-geactiveerde POST-verzoekuitvoer wordt doorgestuurd naar een nieuwe bron. Deze nieuwe URI is geen vervanging van de referentie naar de oorspronkelijke bron. Ook, 303 responses are prohibited from being cached. Of course, a second request (redirect) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlinke to the new URI and a brief description. Note: Many browsers prior to HTTP/1.1 reacties zijn verboden om opgeslagen te worden. Natuurlijk kan een tweede verzoek (herleiden) opgeslagen worden. De nieuwe URI moet worden geretourneerd in het Location-veld van de reactie. tenzij dit een HEAD-verzoek is, moet de reactieentiteit een hyperlink naar de nieuwe URI en een korte beschrijving bevatten. Opmerking: Veel browsers voor HTTP 303 die niet begrijpen 302 statuscode voldoende moet zijn, omdat de meeste browsers de status correct afhandelen. Als je interactie met deze browsers moet overwegen, de 302 reacties precies op dezelfde manier afhandelen zoals de hierboven vermelde specificatie vereist dat de clientkant dit doet 303 reacties. |
| 304 | Als de clientkant een conditie GET-verzoek verzendt en het verzoek is toegestaan, en de inhoud van het document niet is veranderd (sinds de laatste bezoek of volgens de voorwaarden van het verzoek), dan moet de server deze statuscode terugsturen. 304 reacties zijn verboden om berichtlichamen op te nemen, dus ze moeten altijd eindigen met de eerste lege regel na de kop. De reactie moet de volgende kopinformatie bevatten: Date, tenzij deze server geen klok heeft.
Als de server zonder klok ook deze regels volgt, kunnen de proxyserver en de clientkant zelf het Date-veld toevoegen aan de ontvangen antwoordkop (zoals opgegeven in RFC 2068), en het cachingmechanisme zal goed werken. ETag en/of Content-Location, als dezelfde verzoek zou moeten terugkeren met een 200 antwoord. Expires, Cache-Control, en/of Vary, als zijn waarde mogelijk afwijkt van de waarde die overeenkomt met andere reacties op dezelfde variabele ervoor.
Als deze antwoordverzoek een sterke cachevalidatie gebruikt, dan mag deze antwoord geen andere entiteitkoppen bevatten; anders (bijvoorbeeld, een conditie GET-verzoek gebruikt zwakke cachevalidatie), is het niet toegestaan om andere entiteitkoppen op te nemen in deze antwoord; dit voorkomt inconsistenties tussen de gecachte entiteitinhoud en de bijgewerkte entiteitkopinformatie. Als een 304 reactie aangeeft dat een entiteit momenteel niet opgeslagen is, moet het opslagcircuit de reactie negeren en herhaaldelijk verzoeken sturen zonder beperkingen.
Als een 304 reactie ontvangen om een opgeslagen item bij te werken, moet het opslagcircuit het hele item bijwerken om de waarden van alle velden weer te geven die zijn bijgewerkt in de reactie. |
| 305 | De gevraagde bron moet worden bereikt via de opgegeven proxy. De URI-informatie van de opgegeven proxy wordt gegeven in het Location-veld. De ontvanger moet herhaaldelijk een afzonderlijk verzoek sturen om toegang te krijgen tot de bijbehorende bron via deze proxy. Alleen de oorspronkelijke server kan een 305 reactie. Opmerking: Er is geen expliciete 305 reactie in RFC 2068 om een enkel verzoek om te herleiden, en kan alleen worden ingesteld door de oorspronkelijke server. Het negeren van deze beperkingen kan leiden tot ernstige beveiligingsgevolgen. |
| 306 | In de nieuwste versie van de specificatie, de 306 statuscode niet langer wordt gebruikt. |
| 307 | De gevraagde bron reageert nu tijdelijk op het verzoek van een andere URI. Omdat dergelijke herleidingen tijdelijk zijn, moet de clientkant toekomstige verzoeken blijven sturen naar het oorspronkelijke adres. Deze reactie is alleen opslaan in de cache toegestaan als gespecificeerd in Cache-Control of Expires. De nieuwe tijdelijke URI moet worden geretourneerd in het Location-veld van de reactie. tenzij dit een HEAD-verzoek is, moet de reacterende entiteit een hyperlink bevatten die verwijst naar de nieuwe URI en een korte beschrijving. Omdat sommige browsers de 307 reactie, moet deze informatie worden toegevoegd zodat de gebruiker deze kan begrijpen en toegang kan vragen tot de nieuwe URI.
Als dit geen GET of HEAD-verzoek is, verbiedt de browser automatisch om te herleiden tenzij bevestigd door de gebruiker, omdat de voorwaarden van het verzoek kunnen veranderen als gevolg hiervan. |
| 400 | 1. De semantiek is onjuist en de huidige aanvraag kan niet worden begrepen door de server. Tenzij aangepast, mag de clientkant de aanvraag niet herhaald indienen. 2. De aanvraagparameters zijn onjuist. |
| 401 | De huidige aanvraag vereist gebruikersauthenticatie. De reactie moet een WWW-Authenticate-header voor het gevraagde bronbestand om de gebruiker om informatie te vragen. De clientkant kan een aanvraag opnieuw indienen met de juiste Authorization-headerinformatie. Als de huidige aanvraag al Authorization-certificaten bevat, dan 401 reactie betekent dat de server die certificaat heeft afgewezen. Als de 401 reactie bevat dezelfde authenticatiequery als de vorige reactie en de browser heeft ten minste een keer authenticatie geprobeerd, dan moet de browser de entiteitinformatie in de reactie aan de gebruiker tonen, omdat deze entiteitinformatie relevante diagnostische informatie kan bevatten. Zie RFC 2617. |
| 402 | Deze statuscode is gereserveerd voor mogelijke toekomstige vereisten. |
| 403 | De server heeft de aanvraag begrepen, maar heeft het weigerd uit te voeren. In tegenstelling tot een 401 reactie, authenticatie helpt niet en de aanvraag mag niet worden herhaald. Als dit geen HEAD-aanvraag is en de server wil kunnen uitleggen waarom de aanvraag niet kan worden uitgevoerd, dan moet de reden voor de afwijzing binnen de entiteit worden beschreven. Natuurlijk kan de server ook een 404 reactie als de server niet wil dat de clientkant enige informatie krijgt. |
| 404 | De aanvraag is mislukt en het gewenste bronbestand 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 de situatie kent, de 410 status code moet worden gebruikt om het oude bronbestand te informeren dat het permanent niet beschikbaar is vanwege een interne configuratiemechanisme en geen adres heeft om naar te springen. De 404 status code wordt veel gebruikt wanneer de server niet wil onthullen waarom de aanvraag is afgewezen of geen andere geschikte reactie beschikbaar is. |
| 405 | Het opgegeven verzoekschrift in de verzoekregel kan niet worden gebruikt om de bijbehorende bron aan te vragen. De respons moet een Allow-header retourneren die een lijst van verzoekschriftmethoden bevat die door de huidige bron kunnen worden geaccepteerd. Aangezien PUT en DELETE-methoden schrijven naar bronnen op de server, ondersteunen de meeste web servers deze bovenstaande verzoekschriftmethoden niet standaard of staan ze deze standaard niet toe, en zullen ze een}} retourneren. 405 fout voor dergelijke verzoeken. |
| 406 | De inhoudskenmerken van de aangevraagde bron voldoen niet aan de voorwaarden in de verzoekhoofding, zodat een responsentiteit niet kan worden gegenereerd. tenzij dit een HEAD-verzoek is, moet de respons een entiteit retourneren die de gebruiker of browser in staat stelt om de meest geschikte entiteitkenmerken en adreslijst te kiezen. Het formaat van de entiteit wordt bepaald door het media-type dat is gedefinieerd in de Content-Typehoofding. De browser kan de beste keuze maken op basis van het formaat en zijn eigen mogelijkheden. Echter, de specificatie definieert geen criteria voor het maken van dergelijke automatische selecties. |
| 407 | Soortgelijk aan de 401 respons retourneren, behalve dat de klantzijde moet authenticeren op de proxyserver. De proxyserver moet een Proxy-Authenticeer voor authenticatie. De klantzijde kan een Proxy-Autorisatiehoofding voor authenticatie. Zie RFC 2617. |
| 408 | Verzoek is verlopen. De klantzijde heeft het verzenden van het verzoek niet binnen de tijd voltooid waarin de server klaar was om te wachten. De klantzijde kan het verzoek op elk moment opnieuw indienen zonder enige wijzigingen. |
| 409 | De verzoek kan niet worden voltooid vanwege een conflict met de huidige toestand van de aangevraagde bron. Deze code mag alleen worden gebruikt als wordt aangenomen dat de gebruiker het conflict kan oplossen en een nieuwe verzoek zal herindienen. De respons moet voldoende informatie bevatten om de gebruiker te helpen de bron van het conflict te ontdekken. Conflicten komen meestal voor in het verwerken van PUT-verzoeken. Bijvoorbeeld, in een versie-gecontroleerde omgeving, als de versieinformatie die aan een PUT is gekoppeld-ingediende wijzigingsrequest voor een bepaalde bron conflicteert met een eerdere (derde-partij) request, de server moet een 409 foutmelding aan de gebruiker dat de request niet kon worden voltooid.
Op dit moment bevat de responsentiteit waarschijnlijk een vergelijking van de verschillen tussen de twee conflicterende versies, zodat de gebruiker de samengevoegde versie opnieuw kan indienen. |
| 410 | De gevraagde bron is niet meer beschikbaar op de server en heeft geen bekende doorverwijzingsadres. Deze toestand moet permanent worden beschouwd. Indien mogelijk, moet de client met linkeditiecapaciteiten 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, dan een 404 statuscode moet worden gebruikt. Tenzij anders aangegeven, is deze reactie opslaan in de cache mogelijk. Het doel van de 410 reactie wordt voornamelijk gebruikt om de webmaster te helpen de website te onderhouden, de gebruiker te informeren dat de bron niet meer beschikbaar is, en dat de servereigenaar alle externe verbindingen naar deze bron wilt verwijderen.
Dit type gebeurtenis komt vaak voor in de tijd-beperkte, waarde-toegevoegde diensten. Evenzo, de 410 reactie wordt gebruikt om de client te informeren dat bronnen die oorspronkelijk aan een individu behoorden, niet meer beschikbaar zijn op de huidige serversite. Natuurlijk is het geheel aan de servereigenaar om te beslissen of alle permanent niet-beschikbare bronnen als' te markeren 410 Verloren ', en hoe lang deze markering moet worden behouden. |
| 411 | De server weigert de request te accepteren zonder een Content te definiëren-Lengteheader. Na het toevoegen van een geldige Content-Lengteheader die aangeeft hoe lang de requestbody is, de client kan de request opnieuw indienen. |
| 412 | De server heeft niet voldaan aan een of meer van de voorwaarden bij het verifiëren dat deze zijn verstrekt in het headerveld van het verzoek. Deze statuscode staat de clientkant toe om voorwaarden in de aangevraagde metadata (verzoek header field data) in te stellen bij het ophalen van bronnen, waardoor de verzoekmethode wordt voorkomen van toepassing te worden op bronnen die het niet wil. |
| 413 | De server weigert om het huidige verzoek te verwerken omdat het verzoek meer entiteitgegevens indient dan de server bereid of in staat is om te verwerken. In dit geval kan de server de verbinding sluiten om te voorkomen dat de clientkant verder de verzoek indient. Als deze situatie tijdelijk is, zou de server een Retry moeten terugsturen-Na de response header om de clientkant te informeren hoeveel tijd deze opnieuw kan proberen. |
| 414 | De aangevraagde URI is langer dan wat de server kan interpreteren, dus de server weigert om de verzoek te bedienen. Dit komt zelden voor en gemeenschappelijke gevallen zijn: Een formulierindienen dat zou moeten zijn gebruikt met de POST-methode wordt een GET-methode, waardoor de query string (Query String) te lang wordt. Redirect URI "black holes", zoals elke redirect waarbij de oude URI deel uitmaakt van de nieuwe URI, waardoor de URI te lang wordt na meerdere redirects. De client probeert de server aan tevallen met beveiligingsproblemen die op sommige servers bestaan.
Dit type server gebruikt een vaste-lengte buffer om de aangevraagde URI te lezen of te manipuleren. Wanneer de parameters na GET een bepaalde waarde overschrijden, kan een buffer overflow optreden, wat leidt tot uitvoering van willekeurige code [1]. Servers zonder dergelijke kwetsbaarheden moeten een 414 status code. |
| 415 | Voor de methode van het huidige verzoek en de aangevraagde bron, is het entiteit dat in het verzoek is ingediend niet in een formaat ondersteund door de server, dus wordt het verzoek afgewezen. |
| 416 | Als de verzoek een Range header bevat, en geen van de opgegeven data ranges in de Range overeenkomt met het beschikbare bereik van de huidige bron, en de If-De range header is niet gedefinieerd in de verzoek, de server moet een 416 status code. Als de Range een byte range gebruikt, betekent deze situatie dat de eerste bytepositie van alle door het verzoek gespecificeerde datarangen de lengte van de huidige bron overschrijdt. De server zou ook een Content moeten opnemen-Range entiteit header samen met de 416 status code om de lengte van de huidige bron aan te geven. Deze reactie is ook verboden om multipart te gebruiken/byteranges als zijn Content-Type. |
| 417 | Het verwachte inhoud gespecificeerd in de verzoekheader Expect kan niet worden voldaan door de server, of de server is een proxyserver die duidelijk bewijs heeft dat het verwachte inhoud niet kan worden voldaan op de volgende knoop van de huidige route. |
| 421 | Het aantal verbindingen naar de server van het Internet Protocol Adres waar de huidige clientkant zich bevindt, overschrijdt het maximum toegestaan door de server. Typisch verwijst het Internet Protocol Adres hier naar het adres van de clientkant zoals gezien door de server (zoals de gebruikersgateway of proxyserveradres). In dit geval kan het verbindingsaantal betrekking hebben op meer dan één eindgebruiker. |
| 422 | Het aantal verbindingen naar de server van het Internet Protocol Adres waar de huidige clientkant zich bevindt, overschrijdt het maximum toegestaan door de server. Typisch verwijst het Internet Protocol Adres hier naar het adres van de clientkant zoals gezien door de server (zoals de gebruikersgateway of proxyserveradres). In dit geval kan het verbindingsaantal betrekking hebben op meer dan één eindgebruiker. |
| 422 | Het verzoek was correct geformatteerd, maar kon vanwege een semantische fout niet beantwoord worden. (RFC 4918 WebDAV) 423 Geblokkeerd De huidige bron is geblokkeerd. (RFC 4918 WebDAV) |
| 424 | Het huidige verzoek is mislukt vanwege een fout in een eerdere verzoek, zoals PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Gedefinieerd in de WebDav Advanced Collections ontwerp, maar niet in het WebDAV Sequential Set Protocol (RFC 3658). |
| 426 | De clientkant moet overschakelen naar TLS/1.0. (RFC 2817) |
| 449 | Uitgebreid door Microsoft, moeten verzoeken na het uitvoeren van de juiste actie opnieuw worden geprobeerd. |
| 500 | De server kwam onverwacht in een situatie terecht die het verhinderde het verzoek te voltooien. Over het algemeen treedt dit probleem op wanneer de servercode faalt. |
| 501 | De server ondersteunt geen vereiste functie van het huidige verzoek. Wanneer de server de verzochte methode niet kan herkennen en geen verzoek voor elke resource kan ondersteunen. |
| 502 | Wanneer een server die als gateway of proxy werkt, een verzoek probeert uit te voeren, ontvangt het een ongeldig antwoord van een upstream server. |
| 503 | De server kan momenteel geen aanvragen verwerken vanwege tijdelijke serveronderhoud of overbelasting. Deze toestand is tijdelijk en zal na enige tijd worden hersteld. Als de vertragingstijd kan worden voorspeld, kan de respons een Retry bevatten.-Na header om de vertragingstijd aan te geven. Als deze Retry-Na informatie wordt niet verstrekt, moet de clientkant het als een 500-reactie. Opmerking: Het bestaan van een 503 statuscode betekent niet dat de server deze moet gebruiken bij overbelasting. Sommige servers willen eenvoudigweg de verbinding van de klant weigeren. |
| 504 | Wanneer een server die fungeert als gateway of proxy probeert een aanvraag uit te voeren, mislukt hij om op tijd een reactie te ontvangen van een upstream-server (geïdentificeerd door de URI, zoals HTTP, FTP, LDAP) of een secundaire server (zoals DNS). Opmerking: Sommige proxy-servers returneren een 400 of 500-fout wanneer de DNS-query time-outt |
| 505 | De server ondersteunt de versie van HTTP die in de aanvraag wordt gebruikt, niet of weigert om deze te ondersteunen. Dit impliceert dat de server dezelfde versie niet kan of niet zal gebruiken als de clientkant. De respons zou een entiteit moeten bevatten die uitlegt waarom de versie niet wordt ondersteund en welke protocollen de server ondersteunt. |
| 506 | Uitgebreid door het Transparent Content Negotiation Protocol (RFC 2295), dit represents een interne configuratiefout op de server: de gevraagde onderhandelingsvariabelebron is geconfigureerd om zichzelf te gebruiken in een transparante inhoudsonderhandeling en is daarom niet een geschikte focus in een onderhandelingproces. |
| 507 | De server kan de inhoud die nodig is om de aanvraag te voltooien, niet opslaan. Deze toestand wordt als tijdelijk beschouwd. WebDAV (RFC 4918) |
| 509 | De server heeft de bandbreedtegrens bereikt. Dit is geen officiële statuscode, maar het wordt nog steeds veel gebruikt. |
| 510 | De beleidsregels om middelen te verkrijgen zijn niet voldaan. (RFC 2774) |
