| HTTP Statuscode |
Betekenis van de Statuscode |
| 100 |
De client moet de aanvraag voortzetten. Dit tijdelijke antwoord is bedoeld om de client te laten weten dat een deel van de aanvraag door de server is ontvangen en nog niet is afgewezen. De client moet de resterende delen van de aanvraag blijven verzenden, of, indien de aanvraag al is voltooid, dit antwoord negeren. De server moet na voltooiing van de aanvraag een definitief antwoord naar de client sturen. |
| 101 |
De server heeft de aanvraag van de client begrepen en zal de client via de Upgrade-header informeren om een ander protocol te gebruiken voor het voltooien van deze aanvraag. Na het verzenden van deze reactie, zal de server overschakelen naar die protocollen die in de Upgrade-header zijn gedefinieerd. Dit moet alleen worden gedaan als het overschakelen naar een nieuw protocol voordelig is. Bijvoorbeeld, overschakelen naar een nieuwe HTTP-versie kan voordeliger zijn dan de oude versie, of overschakelen naar een realtime en synchrone protocol voor het verzenden van bronnen die gebruik kunnen maken van dergelijke kenmerken. |
| 102 |
Een statuscode die is uitgebreid door WebDAV (RFC 2518) en aangeeft dat de verwerking zal worden voortgezet. |
| 200 |
De aanvraag is succesvol, de gewenste responsheaders of gegevens worden met deze respons teruggegeven. |
| 201 |
De aanvraag is uitgevoerd, en er is een nieuwe bron gecreëerd op basis van de behoefte van de aanvraag, wiens URI is geretourneerd met de Location-header. Als de nodige bron niet onmiddellijk kan worden gemaakt, moet '202 Geaccepteerd' worden geretourneerd. |
| 202 |
De server heeft de aanvraag geaccepteerd, maar heeft deze nog niet verwerkt. Net zoals deze kan worden afgewezen, kan de uiteindelijke aanvraag ook worden uitgevoerd of niet. In het geval van asynchrone operaties is er niets handiger dan het verzenden van deze statuscode. Het doel van een respons die de statuscode 202 teruggeeft is om de server in staat te stellen aanvragen voor andere processen te accepteren (bijvoorbeeld een dagelijkse batchverwerking), zonder dat de client de verbinding met de server open hoeft te houden totdat de batchverwerking volledig is. De respons die de aanvraag heeft geaccepteerd en de statuscode 202 retourneert, moet enkele indicaties bevatten over de huidige status van de verwerking, evenals aanwijzingen naar de statusmonitor of de statusvoorspelling, zodat gebruikers kunnen inschatten of de operatie is voltooid. |
| 203 |
De server heeft de aanvraag succesvol verwerkt, maar de metadata van de teruggegeven entiteit is geen definitieve set die geldig is op de oorspronkelijke server, maar is een kopie van lokaal of van derden. De huidige informatie kan een subset of superset van de oorspronkelijke versie zijn. Bijvoorbeeld, de metadata van de ingesloten bron kan ertoe leiden dat de oorspronkelijke server weet dat de metadata superieur is. Het gebruik van deze statuscode is niet verplicht en alleen passend als de respons zonder deze statuscode 200 OK zou retourneren. |
| 204 |
De server heeft de aanvraag succesvol verwerkt, maar hoeft geen enkele inhoud van de entiteit terug te geven, en wenst bijgewerkte metadata terug te geven. De respons kan nieuwe of bijgewerkte metadata in de vorm van een entiteithoofd teruggeven. Als deze kopinformatie aanwezig is, moet deze aansluiten bij de gevraagde variabelen. Als de client een browser is, moet de browser van de gebruiker de pagina behouden die de aanvraag heeft verzonden, zonder enige verandering in de documentweergave, zelfs als de norm voorschrijft dat nieuwe of bijgewerkte metadata moet worden toegepast op de documentweergave in de actieve browser van de gebruiker. Omdat de 204-respons het opnemen van een berichtlichaam verbiedt, eindigt deze altijd met de eerste lege regel na het berichtkopgebied. |
| 205 |
De server heeft de aanvraag succesvol verwerkt, maar heeft geen inhoud teruggegeven. In tegenstelling tot de 204-respons vereist de respons die deze statuscode retourneert dat de aanvrager de documentweergave opnieuw instelt. Dit antwoord wordt voornamelijk gebruikt om formulieren onmiddellijk na het accepteren van gebruikersinvoer opnieuw te zetten, zodat gebruikers gemakkelijk opnieuw kunnen beginnen met invoeren. Net als bij de 204-respons is dit antwoord ook verboden om enige berichtlichamen op te nemen en eindigt het met de eerste lege regel na het berichtkopgebied. |
| 206 |
De server heeft een deel van de GET-aanvraag succesvol verwerkt. HTTP-downloadtools zoals FlashGet of Thunder gebruiken deze respons om resume of meerdere downloadsegmenten tegelijkertijd te implementeren. De aanvraag moet een Range-header bevatten om de client te laten weten welk bereik van inhoud gewenst is, en kan If-Range bevatten als voorwaarde voor de aanvraag. De respons moet de volgende kopvelden bevatten: Content-Range om het bereik van inhoud dat met deze respons wordt teruggegeven aan te geven; als het een multipart-onderdeel downloadtype van Content-Type is, moet elk multipart-exemplaar de Content-Range-veld bevatten om het inhoudsbereik van dat gedeelte aan te geven. Als de respons een Content-Length bevat, moet de waarde overeenkomen met het werkelijke aantal bytes van het inhoudsbereik dat is geretourneerd. Date ETag en/of Content-Location, als hetzelfde verzoek 200-respons zou moeten retourneren. Expires, Cache-Control, en/of Vary, als de waarden kunnen verschillen van die van eerdere corresponderende waarden. Als dit respons verzoek gebruik maakt van If-Range sterke cachevalidatie, mag deze respons geen andere entiteitskoppen bevatten; als dit respons verzoek gebruik heeft gemaakt van If-Range zwakke cachevalidatie, dan mag deze respons geen andere entiteitskoppen bevatten; dit voorkomt inconsistenties tussen de gecachte entiteitsinhoud en bijgewerkte entiteitskopinformatie. Anders moet deze respons alle entiteitskoppen bevatten die zouden worden teruggegeven in een 200-respons. Als de ETag of Last-Modified koppen niet precies overeenkomen, moet de clientcache het samenvoegen van de inhoud van de 206-respons met enige eerder gecachte inhoud verbieden. Elke cache die geen ondersteuning biedt voor Range en Content-Range koppen, mag de inhoud die door de 206-respons is teruggegeven niet cachen. |
| 207 |
Een statuscode die is uitgebreid door WebDAV (RFC 2518) en aangeeft dat de volgende berichtlichaam een XML-bericht zal zijn en mogelijk afhankelijk is van het aantal eerdere subaanvragen, verschillende onafhankelijke responscodes zal bevatten. |
| 300 |
De aangevraagde bron heeft een reeks beschikbare responsinformatie, elk met zijn eigen specifieke adres en browsergestuurde commerciële informatie. De gebruiker of browser kan een voorkeursadres kiezen om naar te verwijzen. Tenzij dit een HEAD-aanvraag is, moet de respons een entiteit bevatten met een lijst van de eigenschappen en adressen van de bronnen, zodat de gebruiker of browser de meest geschikte omleidingsadres kan kiezen. Het formaat van deze entiteit hangt af van het formaat dat door de Content-Type is gedefinieerd. Browsers kunnen mogelijk automatisch een geschikte keuze maken op basis van het formaat van de respons en hun eigen mogelijkheden. Natuurlijk geeft de RFC 2616-regelgeving geen richtlijnen over hoe deze automatische selectie moet worden uitgevoerd. Als de server zelf een voorkeursrespons heeft, moet de URI van deze respons in de Location worden vermeld; de browser kan deze Location-waarde gebruiken als het adres voor automatische omleiding. Bovendien, tenzij anders gespecificeerd, is deze respons ook cacheerbaar. |
| 301 |
De aangevraagde bron is permanent verhuisd naar een nieuwe locatie, en alle toekomstige referenties naar deze bron moeten een van de URI's gebruiken die in deze respons zijn teruggegeven. Indien mogelijk moet de client die linkbewerkingsrechten heeft automatisch het aangevraagde adres wijzigen naar het adres dat door de server is geretourneerd. Tenzij anders gespecificeerd, is deze respons ook cacheerbaar. De nieuwe permanente URI moet in het Location-veld van de respons worden geretourneerd. Tenzij dit een HEAD-aanvraag is, moet de entiteit van de respons een hyperlink naar de nieuwe URI bevatten en een korte verklaring. Als dit geen GET- of HEAD-aanvraag is, mag de browser geen automatische omleiding uitvoeren, tenzij deze wordt bevestigd door de gebruiker, omdat de voorwaarden van de aanvraag hierdoor kunnen veranderen. Opmerking: voor sommige browsers die de HTTP/1.0-protocol gebruiken, wanneer een POST-aanvraag een 301-respons heeft ontvangen, zal de volgende omleidingsaanvraag veranderen in GET. |
| 302 |
De aangevraagde bron wordt nu tijdelijk vanuit een andere URI geretourneerd. Aangezien deze omleiding tijdelijk is, moet de client de volgende aanvragen naar het oorspronkelijke adres blijven sturen. Deze respons is alleen cacheerbaar als dit is gespecificeerd in Cache-Control of Expires. De nieuwe tijdelijke URI moet in het Location-veld van de respons worden geretourneerd. Tenzij dit een HEAD-aanvraag is, moet de entiteit van de respons een hyperlink naar de nieuwe URI bevatten en een korte verklaring. Als dit geen GET- of HEAD-aanvraag is, mag de browser geen automatische omleiding uitvoeren, tenzij deze wordt bevestigd door de gebruiker, omdat de voorwaarden van de aanvraag hierdoor kunnen veranderen. Opmerking: hoewel de standaardregelingen van RFC 1945 en RFC 2068 het de client niet toestaan om de aanvraagmethoden te veranderen tijdens omleidingen, beschouwen veel bestaande browsers 302-respons zoals een 303-respons, en gebruiken ze de GET-methode om de URI in de Location te benaderen, negerend hoe de oorspronkelijke aanvraag was gedaan. De statuscodes 303 en 307 zijn toegevoegd om expliciet aan te geven welke reactie de server van de client verwacht. |
| 303 |
De respons op de huidige aanvraag is te vinden op een andere URI, en de client zou de GET-methode moeten gebruiken om die bron te bezoeken. Dit doel is voornamelijk bedoeld om te protocoleren dat door scripts geactiveerde POST-aanvragen worden omgeleid naar een nieuwe bron. Deze nieuwe URI is geen vervanger voor de oorspronkelijke bron. Bovendien moet de 303-respons niet worden gecached. Natuurlijk kan de tweede aanvraag (omleiding) worden gecached. De nieuwe URI moet in het Location-veld van de respons worden geretourneerd. Tenzij dit een HEAD-aanvraag is, moet de respons een hyperlink naar de nieuwe URI bevatten en een korte verklaring. Opmerking: veel browsers vóór HTTP/1.1 begrijpen de 303-statuscode niet goed. Als men met deze browsers rekening moet houden, dan zou de 302-statuscode moeten volstaan, omdat de meeste browsers de behandeling van 302-responsen volgen zoals hierboven vereist voor 303-responsen. |
| 304 |
Als de client een voorwaardelijke GET-aanvraag heeft verzonden en deze is geaccepteerd, en de inhoud van het document (sinds het laatste bezoek of volgens de voorwaarden van de aanvraag) niet is veranderd, dan moet de server deze statuscode retourneren. De 304-respons mag geen berichtlichaam bevatten, zodat deze altijd eindigt met de eerste lege regel na het berichtkopgebied. Deze respons moet de volgende kopinformatie bevatten: Date, tenzij de server geen klok heeft. Als de server zonder klok deze regels volgt, kunnen zowel de proxyserver als de client de Date-veld aan de ontvangen responskoppen toevoegen (zoals vermeld in RFC 2068), zodat de caching mechanisme normaal kan functioneren. ETag en/of Content-Location, als dezelfde aanvraag een 200-respons zou moeten retourneren. Expires, Cache-Control, en/of Vary, als de waarden kunnen verschillen van die van eerdere corresponderende waarden. Als deze respons gebruik maakt van sterke cachevalidatie, mag deze respons geen andere entiteitskoppen bevatten; anders, bijvoorbeeld, als een voorwaardelijke GET-aanvraag gebruik maakt van zwakke cachevalidatie, mag deze respons geen andere entiteitskoppen bevatten om inconsistenties tussen de gecachte entiteit en de bijgewerkte entiteitskoppen te vermijden. Als een 304-respons aangeeft dat een entiteit momenteel niet gecached is, moet het caching systeem deze respons negeren en opnieuw een aanvraag zonder beperkingen verzenden. Als er een 304-respons is ontvangen die een verzoek om een aanpassing van een gecachte invoer betreft, moet het caching systeem die invoer volledig bijwerken om de waarde van alle in de respons bijgewerkte velden weer te geven. |
| 305 |
De aangevraagde bron moet toegankelijk zijn via de opgegeven proxy. De Location-veld van de respons zal URI-informatie geven over de opgegeven proxy, de ontvanger moet een aparte aanvraag indienen om via deze proxy als gevolg van deze bron te kunnen krijgen. Alleen de oorspronkelijke server kan de 305-respons genereren. Opmerking: RFC 2068 geeft niet expliciet aan dat de 305-respons bedoeld is om een enkele aanvraag om te leiden en alleen door de oorspronkelijke server kan worden gegenereerd. Het negeren van deze beperkingen kan ernstige veiligheidsgevolgen hebben. |
| 306 |
In de recente specificatie wordt de statuscode 306 niet meer gebruikt. |
| 307 |
De aangevraagde bron wordt nu tijdelijk vanuit een andere URI geretourneerd. Aangezien deze omleiding tijdelijk is, moet de client de volgende aanvragen naar het oorspronkelijke adres blijven sturen. Deze respons is alleen cacheerbaar als dit gespecificeerd is in Cache-Control of Expires. De nieuwe tijdelijke URI moet in het Location-veld van de respons worden geretourneerd. Tenzij dit een HEAD-aanvraag is, moet de entiteit van de respons een hyperlink naar de nieuwe URI bevatten en een korte verklaring. Omdat sommige browsers de 307-respons niet herkennen, zijn er verdere nodige informatie toegevoegd zodat gebruikers begrijpen en aanvragen kunnen indienen naar de nieuwe URI. Als dit geen GET- of HEAD-aanvraag is, mag de browser geen automatische omleiding uitvoeren, tenzij deze wordt bevestigd door de gebruiker, omdat de voorwaarden van de aanvraag hierdoor kunnen veranderen. |
| 400 |
1. Semantische fout, de huidige aanvraag kan niet door de server worden begrepen. Tenzij gewijzigd, moet de client deze aanvraag niet opnieuw indienen. 2. Invoeringsparameters zijn onjuist. |
| 401 |
De huidige aanvraag vereist gebruikersverificatie. De respons moet een WWW-Authenticate-informatiekop bevatten die van toepassing is op de aangevraagde bron om om gebruikersinformatie te vragen. De client kan een aanvraag indienen die een correct Authorization-hoofdinformatie bevat. Als de huidige aanvraag al de Authorization-verklaring bevatte, vertegenwoordigt de 401-respons dat de server verificatie van die verklaringen heeft afgewezen. Als de 401-respons dezelfde autorisatie-aanvraag bevat als de vorige respons en de browser heeft geprobeerd ten minste één verificatie, moet de browser de entiteit van de respons tonen, omdat deze mogelijk relevante diagnostische informatie bevat. Zie RFC 2617. |
| 402 |
Deze statuscode is gereserveerd voor een toekomstige mogelijke behoefte. |
| 403 |
De server heeft de aanvraag begrepen, maar weigert deze uit te voeren. In tegenstelling tot de 401-respons biedt authenticatie geen hulp en deze aanvraag moet niet worden herhaald. Indien dit geen HEAD-aanvraag is, en de server wil uitleggen waarom de aanvraag niet kan worden uitgevoerd, moet de reden in de entiteit worden beschreven. Natuurlijk kan de server ook een 404-respons retourneren als deze niet wil dat de client enige informatie krijgt. |
| 404 |
De aanvraag is mislukt, het verzoek om de gewenste resources is niet op de server gevonden. Er is geen informatie die de gebruiker kan vertellen of deze situatie tijdelijk of permanent is. Als de server op de hoogte is, dient zij de statuscode 410 te gebruiken om aan te geven dat de oude gevolgen door bepaalde interne configuratieproblemen permanent niet beschikbaar zijn, en er geen verwijzing mogelijk is. Deze 404-statuscode wordt veel gebruikt wanneer een server geen aanwijzingen wil geven over waarom een aanvraag is afgewezen of als er geen andere geschikte respons beschikbaar is. |
| 405 |
De aangevraagde methode in de aanvraag kan niet worden gebruikt om de betreffende bron aan te vragen. De respons moet een Allow-hoofdinformatie retourneren die een lijst weergeeft van de aanvraagmethoden die momenteel door de bron kunnen worden geaccepteerd. Gezien het feit dat PUT en DELETE-methoden schrijfbewerkingen op resources op de server uitvoeren, ondersteunen de meeste webservers standaard deze methoden niet of staat deze niet toe in hun standaardconfiguratie, en daarom zal 405-fouten worden geretourneerd voor dergelijke aanvragen. |
| 406 |
De inhoudseigenschappen van de aangevraagde bron kunnen niet voldoen aan de voorwaarden in de aanvraagheaders, zodat er geen responsinhoud kan worden gegenereerd. Tenzij dit een HEAD-aanvraag is, zou de respons een entiteit moeten retourneren die een lijst van de beschikbare eigenschappen en adressen bevat waaruit de gebruiker of browser de meest geschikte eigenschap kan kiezen. Het formaat van de entiteit wordt bepaald door het media type dat in de Content-Type-header is gedefinieerd. Browsers kunnen op basis van het formaat en hun mogelijkheden zelf de beste keuze maken. Echter, de speci<|disc_score|>1 |