HTTP-statuscodes: elke mogelijke code vermeld

Openbaarmaking: Uw steun helpt de site draaiende te houden! We verdienen een verwijzingsvergoeding voor sommige van de services die we op deze pagina aanbevelen.


Contents

Basisprincipes van HTTP-statuscodes

De meeste mensen denken niet al te goed na over wat er werkelijk gebeurt wanneer ze naar een webpagina navigeren. Ze openen gewoon hun browser, klikken op iets en daar staat het op mijn scherm!

Op zoek naar specifieke code? Bekijk de inhoudsopgave rechts!

We denken liever niet na over de complexe dans van verzoeken en reacties die plaatsvinden tussen de webbrowser van onze computer en een server ver weg, in een datacenter, ongezien (meestal) zelfs door de systeembeheerder van de website en IT-personeel.

Maar dan komen we af en toe een fout tegen. We krijgen een slimme 404 Not Found-pagina met een grappige foto erop. Of we krijgen een lege pagina met een notitie van onze eigen browser die ons vertelt over een onbekende 501-fout.

Als informele websitebezoeker is dit alleen maar vervelend. We proberen het meestal opnieuw: vernieuwen, teruggaan en opnieuw klikken. Soms werkt het – we noemen dat een storing en vergeten het meteen. Soms werkt het niet – we noemen dat ‘een slechte website’ en vergeten dat meestal ook meteen.

Maar als u daadwerkelijk een website beheert, verandert dat alles. De HTTP-fouten zijn niet vervelend. Ze zijn gek. Ze zijn beschamend.

Als u bijzonder technisch onderlegd bent of als u een goed IT-team heeft, is dit misschien niet zo’n groot probleem. De meeste van dit soort problemen zijn eenvoudig op te lossen. Maar als u een kleine ondernemer bent, kunt u gek worden door uw eigen website, HTTP-status en foutcodes te runnen.

Hoe los je HTTP-fouten op? Hoe vermijd je HTTP-fouten? Wat betekenen al deze HTTP-statuscodes eigenlijk??

Dat is wat deze gids behandelt, samen met informatie over:

  • goede HTTP-statuscodes (degene die u normaal niet ziet)
  • nuttige HTTP-statuscodes
  • wat voor soort omleidingen u zou moeten gebruiken (en waarom).

Maar eerst, om HTTP-statuscodes te begrijpen, moet u begrijpen hoe HTTP in de eerste plaats werkt.

HTTP-verzoeken en -antwoorden

HTTP staat voor “HyperText Transfer Protocol.”

Wat is een protocol?

Wanneer u aan boord van een marineschip gaat, is er een bepaalde manier om dingen te doen. Eerst groet je de vlag, dan groet je de dienstdoende officier en vraag je toestemming om aan boord te gaan.

Dat is een protocol.

Een protocol is een set regels voor een bepaald type interactie.

Soms is een protocol erg rigide en gedefinieerd:

  • Om aan boord van een schip te gaan:
    • Salute vlag
    • Salute officier van dienst
    • Vraag toestemming om aan boord te gaan.

Soms zijn protocollen wat losser en ongeschreven, maar nog steeds bekend:

  • Wanneer je verjaardagstaart arriveert:
    • Wacht tot iedereen klaar is met zingen
    • Doe een Wens
    • Blaas de kaarsen uit, bij voorkeur in één adem.

Bij computerinteracties draait alles om protocollen. Wanneer twee computers (of een netwerk van computers) met elkaar praten, moeten ze een reeks welomschreven regels hebben om te communiceren.

De regels voor hoe de webbrowser van uw lokale computer communiceert met de webserver die de site host waarnaar u probeert te kijken, is HTTP (HyperText Transfer Protocol).

Waarom zetten we HyperText over?

Oorspronkelijk waren webpagina’s voornamelijk documenten. Een ‘webpagina’ werd gezien als een echte ‘pagina’. Een site was een verzameling documenten. De hoofdpagina van een site was een ‘index’ van de beschikbare documenten.

Welk type documenten? Hypertextdocumenten.

Hypertext betekent alleen dat de documenten naar elkaar linken met “hyperlinks”. Vandaag noemen we ze gewoon oude ‘links’ – ze zijn zo gewoon nu dat we ze niet meer ‘hyper’ noemen.

Klikbare “hyper” -links in tekst – dat idee, dat nu zo gewoon is, was zo revolutionair toen het internet voor het eerst werd gemaakt dat alles er naar werd vernoemd.

De taal voor het schrijven van deze documenten? Hypertext Markup Language (HTML). En het protocol voor het aanvragen en ontvangen van deze documenten? HTTP.

Dus HTTP is …

HTTP is de set regels en procedures voor hoe een webbrowser (of andere “client”) bronnen van een andere computer (de “server”) opvraagt ​​en hoe die andere computer op die verzoeken reageert.

HTTP-verzoek

Dus wanneer u een adres typt, op een link klikt of anderszins een webpagina opent, verzendt uw browser een verzoek naar een andere server.

Het doel van de aanvraag wordt bepaald door de URL en het DNS-systeem. Het DNS-systeem is een onderwerp voor een andere dag, maar in feite is het DNS een adresboek dat domeinnamen koppelt aan specifieke computer IP-adressen.

Het doel van het verzoek wordt gedefinieerd door de domeinnaam en de volledige URL is het belangrijkste onderdeel van het verzoek: alles achter de domeinnaam vertelt de server de specifieke bron die wordt aangevraagd. Het verzoek bevat ook andere informatie zoals:

  • Het verzoektype. De twee meest voorkomende zijn:
    • GET – “Stuur me alstublieft deze bron.”
    • POST – “Hier zijn wat gegevens om te verwerken.”
  • Koptekstvelden – Optionele metagegevensvelden die worden gebruikt om de server over de client te vertellen (bijvoorbeeld welk type browser).
  • Body – De gegevens die door de klant zijn verzonden (voor gebruik met POST).

De server krijgt dit verzoek en stuurt (na enige verwerking) een antwoord.

HTTP-reactie

De allereerste regel van een antwoord is de HTTP-status.

De statusregel bestaat uit twee delen, een cijfercode (zoals 200) en een tekstuitleg (zoals Succes).

Als alles goed werkt, krijg je de 200: Successtatus (die je als menselijke gebruiker nooit ziet), dan wat headergegevens (die je ook niet ziet) en dan de bron die je hebt aangevraagd (wat je wel ziet) ).

De bron kan een hele webpagina zijn, een afbeelding, een video, een geluidsbestand. Het kan ook iets zijn dat u niet ziet, zoals een JavaScript-bestand of een stylesheet.

Als het niet zo goed gaat, zie je mogelijk een bericht over de status. Meestal gebeurt dat wanneer u zoiets als een 404- of 501-code krijgt. Dat zijn foutcodes. Er is iets fout gegaan.

Antwoorden met 404- of 501-foutcodes komen niet terug met de door u gevraagde bron. Soms komen ze terug met een andere bron (zoals de slimme 404-pagina). Soms is er helemaal geen bron (dat is wanneer u de blanco pagina en het standaard foutbericht van de browser krijgt).

Er zijn ook statuscodes die de browser vertellen ergens anders te zoeken, zoals de 301-omleiding. Deze reacties zijn ook niet de gevraagde bron.

In plaats daarvan vertellen de koptekstgegevens de browser om een ​​nieuw verzoek te doen met een andere URL. Je merkt meestal niet wanneer dat gebeurt, omdat je browser gewoon doet wat hem wordt opgedragen en het tweede verzoek doet.

Vervolgens toont het u de bron van het tweede antwoord, zonder u te vertellen dat er iets is gebeurd. Omleidingscodes zijn meestal niet belangrijk voor eindgebruikers, maar voor websitebeheerders zouden ze veel moeten uitmaken.

Statuscode klassen

Je hebt waarschijnlijk gemerkt dat alle statuscodes uit drie cijfers bestaan. Is het je opgevallen dat het eerste cijfer altijd tussen 1 en 5 ligt?

Statuscodes zijn gegroepeerd in vijf “klassen” codes. De 404: Not Found-fout maakt deel uit van de 400 (of soms 4xx) klasse statuscodes. Elke klasse omvat een bepaald aantal problemen of toestanden.

  • 1xx – Informatief – Dit zijn voorlopige antwoorden die bedoeld zijn om te worden gebruikt terwijl de server het verzoek blijft verwerken. Ze worden zelden gebruikt.
  • 2xx – Succes – Codes die worden gebruikt wanneer dingen werken zoals ze zouden moeten. Er worden verschillende succescodes geretourneerd op basis van wat het verzoek specifiek probeerde te doen.
  • 3xx – Redirection – Codes die de cliënt vertellen om ergens anders naar de gevraagde bron te zoeken.
  • 4xx – Clientfout – Deze codes vertellen de client dat hij iets verkeerd heeft gedaan.
  • 5xx – Serverfout – Code voor wanneer iets op de server niet werkt zoals verwacht.

We gaan dieper in op de specifieke codes van elke klasse in hun eigen secties.

Omgaan met HTTP-status (en fout) codes

Deze gids behandelt alle mogelijke HTTP-status en HTTP-foutcodes – van algemeen tot nooit gebruikt. We leggen uit wat elke code betekent, waarom ze worden gegenereerd, wanneer de code een probleem kan zijn en hoe we met de problemen kunnen omgaan.

HTTP-statuscode 1xx – informatief

Kennis is macht. Informatie is bevrijdend.

—Kofi Annan

HTTP-statuscodes in de 1xx-klasse zijn bedoeld als voorlopig, verzonden door de server voordat een volledig en voltooid tweede antwoord wordt verzonden.

Ze werden geïntroduceerd in HTTP / 1.1, dus vroege browsers die HTTP / 1.0 implementeren, kunnen ze niet aan en servers mogen in die gevallen geen 1xx-codes beëindigen.

HTTP 100 Doorgaan

Meestal is een verzoek-antwoordsequentie eenvoudig. Er wordt één verzoek ingediend, ontvangen en beantwoord.

Maar soms moet een verzoek in delen worden opgedeeld. Dit kan voorkomen als het verzoek te groot is. Dit kan gebeuren als de aanvrager moet controleren of de koptekst correct is opgemaakt of als de server daadwerkelijk klaar is om het verzoek te ontvangen.

In deze gevallen kan de client (browser) het eerste verzoek verzenden met een koptekst die Expect: 100-continue bevat.

Wanneer dat gebeurt, zal de server het eerste verzoek ontvangen en – als alles in orde is – reageren met de 100: Doorgaan-status. Dit signaleert de klant om het verzoek te voltooien.

Als alles niet goed gaat, stuurt de server een 417 Expectation Failed terug.

HTTP 101-schakelprotocollen

Een client kan een server vragen om van protocol te wisselen, bijvoorbeeld van HTTP / 1.1 naar HTTP / 2.0.

Als de server bereid is om aan dat verzoek te voldoen, stuurt hij het antwoord 101: Switching Protocols terug, samen met headergegevens die de naam bevatten van het nieuwe protocol dat wordt gebruikt.

HTTP 102-verwerking

Deze code wordt alleen gebruikt met WebDAV, een extensie van HTTP die mogelijkheden biedt voor bestandsmanipulatie, enigszins vergelijkbaar met FTP (hoewel zeer verschillend in daadwerkelijke implementatie).

Een WebDAV-verzoek kan veel subaanvragen bevatten. De 102: Processing-status laat de client weten dat de server het verzoek heeft ontvangen en eraan werkt, maar dat er nog werk aan de winkel is. Dit voorkomt dat de klant ervan uitgaat dat het verzoek verloren is gegaan en dat er een time-out optreedt.

HTTP-statuscode 2xx – geslaagd

Alles wat je nodig hebt in dit leven is onwetendheid en vertrouwen, en dan is succes zeker.

-Mark Twain

HTTP-statuscodes in de klasse 2xx zijn bedoeld om te worden gebruikt wanneer een verzoek is voltooid zoals bedoeld.

Veel van deze codes worden nooit of zelden daadwerkelijk gebruikt of zelfs geïmplementeerd.

HTTP 200 OK

Dit is de standaardreactie voor succesvolle verzoeken – het is de statuscode die u normaal gesproken wilt en verwacht.

Als het verzoek GET is (om een ​​bron vragen), zal de reactie de bron bevatten. Als het verzoek een POST (of een ander type) is, bevat het antwoord een bron die het resultaat van de actie beschrijft of bevat.

HTTP 201 gemaakt

Sommige verzoeken zijn bedoeld om een ​​nieuwe bron te maken. Wanneer deze met succes zijn voltooid, wordt de status 201 verzonden om aan te geven dat de nieuwe bron is gemaakt. Dit wordt meestal gebruikt in combinatie met het PUT-verzoektype.

HTTP 202 geaccepteerd

Het verzoek is geaccepteerd, maar er is geen gevolg aan gegeven. Aan het verzoek kan al dan niet gevolg worden gegeven.

HTTP 203 Niet-gezaghebbende informatie

Het antwoord bevat de gevraagde bron, maar de bron is mogelijk afkomstig van een andere bron en is daarom mogelijk onbetrouwbaar – de server staat niet in voor de geldigheid of authenticiteit van de bron.

HTTP 204 Geen inhoud

Dit wordt verzonden wanneer de server het verzoek met succes heeft verwerkt, maar hoeft geen inhoud te retourneren. Meestal gebeurt dit als gevolg van een VERWIJDER-verzoek.

Wanneer een 204-verzoek wordt verzonden, is het niet de bedoeling dat de user-agent (de client of webbrowser) van mening verandert.

Als het verzoek bijvoorbeeld via een formulier op een pagina is verzonden, mag het antwoord er niet voor zorgen dat het formulier wordt vernieuwd of dat de browser een andere pagina bezoekt – er is geen nieuwe inhoud in het verzoek om de bestaande inhoud in de gebruiker te vervangen visie.

HTTP 205 Inhoud resetten

Het 205-antwoord is vergelijkbaar met een 204, maar de user-agent zou hun weergave moeten verversen naar de standaardstatus van het huidige document.

HTTP 206 Gedeeltelijke inhoud

Dit wordt gebruikt wanneer de server slechts een deel van de aangevraagde bron verzendt, omdat de gebruiker heeft verzocht om slechts een deel van de bron te ontvangen.

Dit gebeurt wanneer een bron groot genoeg is, of de verbinding onbetrouwbaar genoeg is, dat de user-agent de bron wil opsplitsen in een reeks “opgedeelde” verzoeken, zoals geïllustreerd:

  • Cliënt: Geef me de eerste 1/4.
    • Server: 206 gedeeltelijke inhoud
  • Cliënt: Geef me de tweede

    1/4.

    • Server: 206 gedeeltelijke inhoud.
  • Enzovoorts…
    • …enzovoorts.

Deze gedeeltelijke verzoeken worden door de klant gedaan met behulp van de bereikkop. Ze kunnen achter elkaar voorkomen (om te voorkomen dat de download mislukt), of allemaal tegelijk in meerdere threads (om het downloaden te versnellen).

HTTP 207 Multi-Status

Net als 103 wordt dit alleen gebruikt met WebDAV.

Een WebDAV-verzoek kan meerdere subverzoeken hebben, elk met zijn eigen status en respons. De 207-status geeft aan dat de hoofdtekst van het antwoord een XML-document zal bevatten met de status en de antwoorden van elk subverzoek.

HTTP 208 Reeds gerapporteerd

Een andere statuscode die alleen voor WebDAV geldt. Dit betekent dat de leden van een DAV-binding al zijn opgesomd in een eerder antwoord op het huidige verzoek en niet opnieuw worden opgenomen.

HTTP 226 IM gebruikt

De server heeft aan een verzoek voor de bron voldaan en het antwoord is een weergave van het resultaat van een of meer exemplaarmanipulaties die op het huidige exemplaar zijn toegepast.

HTTP-statuscode 3xx – omleiding

Telkens wanneer u iets opgeeft, moet u het door iets vervangen.

– Lou Holtz

Statussen in de 3xx-klasse worden verzonden wanneer aanvullende actie van de kant van de klant vereist is om het verzoek te voltooien. Dit wordt meestal gebruikt bij het omleiden van de ene URL naar de andere, maar niet altijd.

In het geval van GET-verzoeken zal de browser in het algemeen het tweede verzoek uitvoeren zonder enige invoer of aanvullende interactie van de gebruiker. In andere gevallen is extra tussenkomst van de gebruiker vereist.

Om oneindige omleidingslussen te voorkomen, volgen browsers doorgaans niet meer dan vijf opeenvolgende omleidingen van hetzelfde verzoek.

HTTP 300 meerdere keuzes

De 300-status wordt door browsers geretourneerd wanneer het verzoek resulteert in meerdere opties voor de bron. In theorie zou dit kunnen worden gebruikt om verschillende opties voor bestandsindelingen, verschillende mediapresentaties van dezelfde inhoud of zelfs ondubbelzinnig woordgebruik te presenteren.

De 300 Multiple Choice-status heeft veel potentieel, maar wordt niet vaak gebruikt.

HTTP 301 permanent verplaatst

Deze status geeft aan dat de bron permanent van URL is veranderd.

Zoekmachines werken hun index op basis hiervan bij, waarbij ze gewoonlijk elke rangorde van de oorspronkelijke URL aan de nieuwe URL toewijzen.

Browsers en andere soorten clients cachen vaak de nieuwe URL en volgen automatisch de omleidings-URL zonder het origineel direct te controleren op volgende verzoeken, zelfs als de originele URL handmatig wordt opgegeven. Opgeslagen bladwijzers worden doorgaans ook bijgewerkt.

Als u omleidingen instelt vanwege een wijziging in de domeinnaam of de URL-structuur, moet u in het algemeen 301: Moved Permanent redirects gebruiken.

Deze kunnen worden ingesteld in het .htaccess- of httpd.conf-bestand op uw server of vaak in uw contentbeheersysteem. (Er zijn bijvoorbeeld verschillende WordPress-plug-ins voor het beheren van 301-omleidingen.)

Wanneer een website opnieuw wordt ontworpen en een URL-structuur wordt gewijzigd, is het erg belangrijk om een ​​301-omleiding in te stellen voor elke URL vanaf de oorspronkelijke site. Als u dit niet doet, leidt dit tot verbroken links en teleurgestelde bezoekers.

HTTP 302 gevonden

De 302-statuscode wordt vaak gebruikt voor tijdelijke omleidingen. De industriële praktijk met 301-omleidingen wijkt af van de oorspronkelijke specificatie en de specificatie is geëvolueerd om te voldoen aan de industriële praktijk.

Oorspronkelijk stond er in de specificatie dat een 302-status ervoor moet zorgen dat de browser een tweede, identiek verzoek doet aan de nieuwe URL. Veel webbrowsers van de eerste generatie hebben het echter zodanig geïmplementeerd dat POST-verzoeken opnieuw werden geschreven als GET-verzoeken.

Om de situatie te verhelderen, heeft de bijgewerkte specificatie HTTP / 1.1 twee extra statuscodes toegevoegd, 303 en 307.

302 Found was bedoeld om het “omschakelen naar GET” -gedrag na te bootsen dat was geïmplementeerd, terwijl 307 Temporary Redirect bedoeld was om het oorspronkelijke 302 verwachte gedrag te vervangen.

De meeste servers en webframeworks bleven echter gewoon 302 gebruiken voor achterwaartse compatibiliteit met browsers die de nieuwere normen niet implementeren.

Latere HTTP-specificaties voldeden aan de standaardpraktijk, waardoor browsers POST-verzoeken konden herschrijven naar GET-verzoeken.

Het gevolg van dit alles is dat als u een 302-omleiding gebruikt op een URL die POST-gegevens zou accepteren, deze gegevens waarschijnlijk niet worden opgenomen in het tweede verzoek.

Om deze reden mag 302 alleen worden gebruikt op URL’s die POST-gegevens (webformulieren) accepteren als de server de ingediende gegevens daadwerkelijk kan accepteren op de oorspronkelijke URL, en de omleiding gebruiken om een ​​pagina af te leveren nadat de gegevens zijn geaccepteerd.

Dit alles maakt de 303 in de praktijk overbodig.

Over het algemeen mag een 302-omleiding niet worden gebruikt

HTTP 303 Zie Overige

In de praktijk is dit identiek aan een 302-status. Het betekent dat het antwoord of de bron kan worden gevonden op een andere URL met behulp van de GET-methode. Bij ontvangst als antwoord op een POST-verzoek moet de browser ervan uitgaan dat de gegevens zijn ontvangen.

HTTP 304 niet gewijzigd

Webbrowsers kunnen een verzoek verzenden met een koptekst waarin wordt gevraagd of een bron is gewijzigd sinds een bepaalde data en tijd. Dit wordt gedaan als de browser de bron al eerder heeft gedownload en opgeslagen.

Als het sinds die tijd is gewijzigd, zal de server reageren met de bron en een 200 successtatus.

Als de bron echter niet is gewijzigd, stuurt de server de status 304 Niet gewijzigd en niet ook de bron. De browser moet dan de opgeslagen versie van de bron weergeven, omdat deze niet is gewijzigd.

HTTP 305 Proxy gebruiken

De gevraagde bron is alleen beschikbaar via een proxy. Het adres van de proxy wordt vermeld in het antwoord. De webbrowser probeert het verzoek opnieuw te doen via de proxy. Vanwege veiligheidsredenen implementeren niet alle klanten dit volgens de norm.

HTTP 306-switchproxy

De 306-status betekende oorspronkelijk “Vervolgverzoeken moeten de opgegeven proxy gebruiken.” Hij wordt niet meer gebruikt.

HTTP 307 tijdelijke omleiding

Deze status is gemaakt om de oorspronkelijke bedoeling van de 302-status te repliceren (zie hierboven).

De 307: Tijdelijke omleidingsstatus betekent dat het verzoek deze keer moet worden herhaald met een andere URL, maar dat in de toekomst verzoeken echter nog steeds de oorspronkelijke URL moeten gebruiken.

In tegenstelling tot hoe 302 in het verleden door klanten is geïmplementeerd, mag de verzoekmethode niet worden gewijzigd bij het verzenden van het tweede verzoek. Een POST-verzoek moet bijvoorbeeld worden herhaald met een ander POST-verzoek en met alle originele POST-gegevens.

HTTP 308 Permanente omleiding

Het huidige verzoek moet worden herhaald met een andere URL en alle toekomstige verzoeken moeten ook naar die URL worden verzonden.

Net als 307 en 302, dupliceert deze status de functionaliteit die is gespecificeerd in de oorspronkelijke specificatie van 301. Bij 308 zou echter (net als bij 307) het tweede verzoek identiek moeten zijn aan het oorspronkelijke verzoek – met dezelfde methode en met dezelfde gegevens.

HTTP 308 Hervatten onvolledig

Deze statuscode is gemaakt en wordt gebruikt door Google. Het maakt deel uit van het voorstel voor hervattbare HTTP-verzoeken en wordt gebruikt om afgebroken PUT- of POST-verzoeken te hervatten.

HTTP-statuscode 4xx – Clientfout

Iedereen kan fouten maken, maar alleen een idioot blijft fout.

—Marcus Tullius Cicero

Van de vijf klassen van HTTP-statuscodes zijn er slechts twee echt “Foutcodes”, de 4xx- en 5xx-klassen.

De 4xx-reeks HTTP-fouten is bedoeld om te worden gebruikt wanneer de fout van de client lijkt te komen – dat wil zeggen dat er iets mis is met het verzoek.

Samen met de foutstatus en andere koptekstinformatie bieden servers vaak een volledig antwoord (een “entiteit” genoemd in plaats van “bron”, maar verder hetzelfde) dat aan de gebruiker moet worden getoond.

Dit is bedoeld om de gebruiker een manier te bieden om te herstellen wat de clientfout ook was. De meest voorkomende vorm van deze entiteiten is de 404-pagina, die hieronder wordt besproken.

HTTP 400 ongeldig verzoek

Dit is een algemeen antwoord op een verzoek met een probleem. Het probleem kan een misvormde syntaxis, ongeldige opmaak of misleidende verzoekroutering zijn. Servers zullen vaak aanvullende informatie geven over wat er specifiek mis is gegaan met het verzoek.

HTTP 401 Niet geautoriseerd

Dit wordt gebruikt wanneer de bron beperkt is tot bepaalde geverifieerde gebruikers. De status betekent dat er geen authenticatie is of dat de authenticatie is mislukt. Volgens de norm zou een antwoord met deze code een authenticatiemiddel moeten bevatten.

HTTP 402 Betaling vereist

Wordt niet vaak gebruikt, omdat de specificatie onvoldoende informatie biedt voor een huidige implementatie (deze is genoemd en gereserveerd voor toekomstig gebruik, maar er is geen volledige specificatie aangenomen).

Het is de bedoeling om deze code te gebruiken als onderdeel van een soort digitaal contant of microbetalingssysteem.

YouTube gebruikt deze status als ze te veel verzoeken ontvangen van één IP-adres. Het antwoord vereist een CAPTCHA om te verifiëren dat de gebruiker een mens is.

HTTP 403 verboden

Net als bij 401 betekent dit dat het verzoek geldig was, maar de server zal er niet op reageren omdat de gebruiker geen toestemming heeft om de bron te bekijken. In tegenstelling tot een 401: niet-geautoriseerde fout, maakt authenticatie geen verschil.

HTTP 404 niet gevonden

Dit is de meest voorkomende klassefout in 4xx en misschien wel de meest voorkomende HTTP-status voor de gemiddelde gebruiker.

404 wordt geretourneerd als het verzoek geldig is, maar de gevraagde bron kan eenvoudigweg niet op de server worden gevonden.

De meeste webframeworks geven de websitebeheerder de mogelijkheid om een ​​”404-pagina” te maken. Dit is een pagina die de gebruiker ziet wanneer er een 404-fout optreedt.

Dit informeert de gebruiker doorgaans over het probleem, verontschuldigt zich voor het ongemak en biedt alternatieve manieren om de inhoud te vinden waarnaar de gebruiker op zoek is, zoals zoeken.

Sommige websites kijken naar eventuele trefwoorden in de verzoek-URL en proberen te bepalen naar welke pagina of bron de gebruiker mogelijk op zoek was, en bieden een of meer opties voor alternatieve pagina’s.

Hoewel 4xx-fouten technisch gezien ‘clientfouten’ zijn, is de 404-fout vaak het resultaat van dode links – URL’s die eerder inhoud hadden maar die nu zijn gewijzigd.

Om deze reden kan het leveren van een 404-pagina een beetje gênant zijn voor websites, omdat dit vaak betekent dat de URL niet correct wordt omgeleid. De implicatie is niet ‘je hebt je verzoek verprutst’, maar ‘we zijn het ding dat je zoekt kwijt’.

Daarom is het heel gebruikelijk dat websites hun 404 pagina’s veranderen in een plek voor humor.

HTTP 405-methode niet toegestaan

Dit wordt gebruikt wanneer het verzoek goed is gevormd en de bron waarom het vraagt ​​bestaat, maar de aanvraagmethode (zoals GET of POST) niet geschikt is voor de bron.

Een URL die formuliergegevens heeft ontvangen, moet bijvoorbeeld worden benaderd met een POST-verzoek. Een GET-verzoek kan resulteren in een 405: Methode niet toegestaan ​​antwoord. Het gebruik van PUT op een alleen-lezen bron kan ook zo’n reactie veroorzaken.

HTTP 406 niet acceptabel

Verzoeken kunnen, en vaak doen ze, het type inhoud specificeren waarnaar ze op zoek zijn, met behulp van MIME-typen.

Als de aangevraagde bron van een type is dat niet overeenkomt met het type of de typen die worden vermeld in de Accept-header van het verzoek, retourneert de server de 406: Not Acceptable-fout.

HTTP 407-proxyverificatie vereist

Voordat de cliënt toegang krijgt tot de gevraagde bron, moet hij zich eerst verifiëren met de proxy die in het antwoord is gespecificeerd.

Time-out voor HTTP 408-aanvraag

Deze fout treedt op wanneer de server een time-out krijgt tijdens het wachten op het verzoek.

Van de specificatie:

De client heeft geen verzoek ingediend binnen de tijd dat de server bereid was te wachten. De klant KAN het verzoek op een later tijdstip zonder wijzigingen herhalen.

HTTP 409-conflict

Geeft aan dat het verzoek niet kan worden verwerkt omdat het in strijd is met zichzelf. Dit kan bijvoorbeeld gebeuren in het geval van meerdere updates die bewerkingsconflicten met elkaar veroorzaken.

HTTP 410 verdwenen

Deze fout is vergelijkbaar met de 404-fout, maar is bedoeld om aan te geven dat de gevraagde bron opzettelijk is verwijderd en niet langer beschikbaar is op een URL.

Klanten moeten op deze reactie reageren door de bron te verwijderen – bladwijzers moeten worden verwijderd en zoekmachines moeten de bron uit hun indexen verwijderen.

De meeste gebruikssituaties vereisen dit niet en de 404 is meestal een geschiktere fout.

HTTP 411-lengte vereist

De aangevraagde bron vereist dat verzoeken hun lengte specificeren, en de aanvraag heeft dit niet gedaan.

HTTP 412-voorwaarde mislukt

De aanvrager heeft de voorwaarden of vereisten in de koptekst van het verzoek geplaatst en de server kan niet aan een of meer van die vereisten voldoen.

HTTP 413 Request Entity Too Large

De aanvraag is groter dan de server kan verwerken.

HTTP 414 Request-URI te lang

De opgegeven URI (URL) was te lang om door de server te worden verwerkt.

Dit wordt vaak veroorzaakt wanneer een onjuiste hoeveelheid gegevens binnen de URL wordt overgebracht als een queryreeks in een GET-verzoek. De gebruikelijke oplossing is om het verzoek om te zetten in een POST en de gegevens in de hoofdtekst van het verzoek te plaatsen.

HTTP 415 Niet-ondersteund mediatype

Dit wordt over het algemeen gebruikt voor het uploaden van bestanden, wanneer de verzoekentiteit (het bestand dat wordt geüpload) van een type is dat niet wordt ondersteund door de server.

HTTP 416 Aangevraagd bereik niet tevreden

Dit wordt geretourneerd wanneer het verzoek om een ​​deel van het bestand vraagt, met behulp van de bereikkop, maar het gevraagde deel bestaat niet. Als de aanvraag bijvoorbeeld om een ​​deel van het bestand vraagt ​​dat buiten het einde van het bestand valt.

HTTP 417-verwachting mislukt

Deze status wordt geretourneerd door een server als deze niet kan voldoen aan de verwachting die is ingesteld door de verwachte header in de aanvraag.

De verwachte koptekst wordt meestal gebruikt om de server om een ​​100 Doorgaan-status te vragen.

HTTP 418 Ik ben een theepot

Deze foutcode wordt geretourneerd door met internet verbonden theepotten, voor het geval ze een verzoek om koffie krijgen.

Time-out voor HTTP 419-verificatie

Dit maakt eigenlijk geen deel uit van de HHTP-standaard, maar sommige clients en servers gebruiken het. Het wordt geretourneerd wanneer een verzoek waarvoor een geverifieerde gebruiker is vereist, wordt verzonden door een aanvrager wiens authenticatie is verlopen.

HTTP 420 Method Failure (Spring Framework)

Geen onderdeel van de HTTP-standaard, maar gedefinieerd door Spring in hun webframework, voor gebruik wanneer een methode is mislukt. Het is verouderd.

HTTP 420 Verbeter je rust (Twitter)

Geen onderdeel van de HTTP-standaard, maar geïntroduceerd door Twitter. Dit werd gebruikt door versie 1 van hun API wanneer verzoeken van een bepaalde klant werden beperkt.

De meer standaardstatus voor een dergelijke situatie is 429: Te veel verzoeken.

HTTP 421 verkeerd gericht verzoek

Deze status is geïntroduceerd in HTTP / 2. Het wordt gebruikt wanneer het verzoek was gericht aan een server die momenteel geen antwoord kan produceren.

HTTP 422 Onverwerkbare entiteit

Dit is gerelateerd aan de WedDAV-extensie. Het wordt geretourneerd wanneer semantische fouten de aanvraag onbewerkbaar maken.

HTTP 423 vergrendeld

Gebruikt met WedDAV. Dit betekent dat de aangevraagde bron is vergrendeld.

HTTP 424 is afhankelijkheid mislukt

Gebruikt met WebDav. Het verzoek is mislukt omdat een eerder verzoek, waarvan het huidige verzoek afhankelijk is, is mislukt.

HTTP 426-upgrade vereist

De client moet overschakelen naar een ander protocol, zoals gespecificeerd in de upgrade-header.

HTTP 428 Voorwaarde vereist

Dit wordt gebruikt wanneer de server vereist dat het verzoek voorwaardelijk is.

De server kan bijvoorbeeld eisen dat het verzoek een voorwaarde bevat dat het verzoek alleen mag worden verwerkt als de bron niet is bijgewerkt sinds een bepaalde datum en tijd. Als er geen voorwaarde is opgegeven, mislukt het verzoek en wordt deze status geretourneerd.

Volgens de specificatie was deze status bedoeld om “het ‘verloren update’-probleem te voorkomen, waarbij een client de status van een bron ophaalt, deze wijzigt en terugzet naar de server, terwijl ondertussen een derde de status op de server heeft gewijzigd , wat leidt tot een conflict. ‘

HTTP 429 Te veel verzoeken

De client (meestal zoals gedefinieerd door IP-adres) heeft te veel verzoeken verzonden binnen een bepaalde periode.

HTTP 431 Verzoek headervelden te groot

Dit wordt geretourneerd wanneer een enkel koptekstveld, of allemaal gezamenlijk, te groot is om door de server te worden verwerkt.

HTTP 440 Login Timeout (Microsoft)

Geen onderdeel van de standaard, maar gebruikt door Microsoft. Geeft aan dat de sessie is verlopen.

HTTP 444 Geen reactie (Nginx)

Geen onderdeel van de standaard. Niet echt een responsstatus zoals gebruikt.

Dit werd door Nginx geïntroduceerd voor hun serverlogboeken, om aan te geven wanneer de server eenvoudigweg geen antwoord stuurde en de verbinding verbrak, meestal in het geval van een vermoedelijke malware-aanval.

HTTP 449 Opnieuw proberen met (Microsoft)

Geen onderdeel van de standaard, maar gebruikt door Microsoft.

Het verzoek moet opnieuw worden geprobeerd nadat de in het antwoord beschreven actie is uitgevoerd.

HTTP 450 geblokkeerd door ouderlijk toezicht van Windows (Microsoft)

Geen onderdeel van de standaard, maar gebruikt door Microsoft.

Deze fout wordt weergegeven wanneer Windows Ouderlijk toezicht is ingeschakeld en de toegang tot de opgegeven webpagina blokkeert. De fout is afkomstig van de WPC-applicatie, niet van de server.

HTTP 451 niet beschikbaar vanwege juridische redenen (concept)

Deze status maakt nog geen deel uit van de standaard, maar is beschikbaar in conceptvorm.

Het beoogde gebruik is voor wanneer een hulpmiddel niet kan worden verstrekt vanwege censuur of andere juridische redenen. Het codenummer is een verwijzing naar het boek Farenheit 451.

HTTP 451-omleiding (Microsoft)

Geen onderdeel van de standaard, maar gebruikt door Microsoft. Komt voor in Exchange ActiveSync als er een efficiëntere server is om te gebruiken of als de server geen toegang heeft tot de mailbox van de gebruikers.

HTTP 494 Request Header Too Large (Nginx)

Geen onderdeel van de standaard, maar werd gebruikt door Nginx. Nu verouderd.

Dit had dezelfde betekenis als 431, maar werd geïntroduceerd voordat die status deel uitmaakte van de HTTP-standaard.

HTTP 495 Cert-fout (Nginx)

Geen onderdeel van de standaard. Niet echt een responsstatus zoals gebruikt, maar verschijnt in Nginx-logboeken wanneer een SSL-clientcertificaatfout optreedt.

HTTP 496 No Cert (Nginx)

Geen onderdeel van de standaard. Niet echt een responsstatus zoals gebruikt, maar verschijnt in Nginx-logboeken wanneer de klant geen certificaat heeft verstrekt.

HTTP 497 HTTP naar HTTPS (Nginx)

Geen onderdeel van de standaard. Niet echt een responsstatus zoals gebruikt, maar verschijnt in Nginx-logs wanneer gewone HTTP-verzoeken naar de HTTPS-poort worden verzonden.

HTTP 498 Token verlopen / ongeldig (Esri)

Geretourneerd door ArcGIS for Server. Een code van 498 geeft een verlopen of anderszins ongeldige token aan.

HTTP 499 Client Closed Request (Nginx)

Geen onderdeel van de standaard. Niet echt een responsstatus zoals gebruikt, maar verschijnt in Nginx-logboeken wanneer de verbinding door de client is verbroken terwijl de server zijn verzoek nog steeds verwerkt, waardoor de server geen statuscode kan terugsturen.

HTTP 499-token vereist (Esri)

Geretourneerd door ArcGIS for Server. Een code van 499 geeft aan dat een token vereist is (als er geen token is ingediend).

HTTP-statuscode 5xx – Serverfout

Ik ben inderdaad verbaasd als ik bedenk hoe zwak mijn geest is en hoe foutgevoelig ik ben.

-Rene Descartes

Samen met de 4xx-serie zijn de 5xx-klasse van HTTP-statuscodes foutcodes die worden uitgegeven wanneer er iets misgaat. De 5xx-foutcodes zijn serverfoutcodes, wat betekent dat ze worden geretourneerd wanneer het probleem op de server zit, in plaats van bij de client.

Waar mogelijk moet de server een antwoordentiteit retourneren die de fout beschrijft aan de klant. User agents (webbrowsers) moeten deze informatie aan de gebruiker tonen.

HTTP 500 interne serverfout

Dit is de meest algemene serverfout en wordt uitgegeven door webservers wanneer er iets onbepaalds is misgegaan.

Over het algemeen moet elke wijziging in een website of serverconfiguratie worden gevolgd door grondige tests om er zeker van te zijn dat er geen 500: Internal Server Error wordt geproduceerd.

Wanneer een 500-fout wordt geproduceerd, kan het kijken naar de serverlogboeken vaak helpen bepalen waar de fout vandaan komt. Het kan vaak zo simpel zijn als typografische fouten in het .htaccess-bestand.

HTTP 501 niet geïmplementeerd

Dit wordt geretourneerd wanneer de HTTP-aanvraagmethode (zoals PUT of DELETE), de API-methode in sommige gevallen, nog niet is geïmplementeerd. Dit wordt gebruikt voor webservice-API’s. Meestal is de implicatie van een 501-fout dat de aanvraagmethode is gepland voor toekomstige implementatie.

HTTP 502 Slechte gateway

Dit gebeurt wanneer de server als proxy of gateway fungeert en een ongeldige reactie van de upstream-server ontvangt.

HTTP 503-service niet beschikbaar

De server is momenteel niet beschikbaar. Bijvoorbeeld omdat het overbelast is of uitvalt voor onderhoud.

De implicatie van een 503-fout is dat de storing tijdelijk is.

Time-out voor HTTP 504-gateway

Deze fout wordt geretourneerd wanneer de server als proxy of gateway fungeerde en ontvangt geen antwoord van de upstream-server binnen de toegewezen tijd.

HTTP 505 HTTP-versie niet ondersteund

Deze fout betekent dat de server de in het verzoek gebruikte HTTP-protocolversie niet ondersteunt.

HTTP 506-variant onderhandelt ook

Om de 506-fout te begrijpen, moet u transparante onderhandeling over inhoud begrijpen.

Bij contentonderhandeling kan één enkele URL dezelfde bron of informatie in meerdere indelingen leveren. Dezelfde afbeelding kan bijvoorbeeld zijn gecodeerd als JPEG en als GIF.

De 506-fout treedt op wanneer deze inhoudsonderhandeling een lus veroorzaakt. Bijvoorbeeld: De aangevraagde bron A heeft twee varianten – B en C. Beide hebben A als variant.

Om dat in meer technische taal te zeggen, beschrijft de specificatie de 506-fout met:

Transparante contentonderhandeling voor het verzoek resulteert in een circulaire referentie.

HTTP 507 onvoldoende opslag (WebDAV; RFC 4918)

Deze status wordt gebruikt het WebDAV-protocol. Het wordt geretourneerd wanneer de server de representatie die nodig is om het verzoek te voltooien niet kan opslaan.

HTTP 508-lus gedetecteerd

De server heeft een oneindige lus aangetroffen tijdens een poging om de gevraagde bron te bedienen.

HTTP 509-bandbreedtelimiet overschreden (Apache)

Geen onderdeel van de HTTP-standaard, maar geïntroduceerd en gebruikt door Apache. Het wordt uitgegeven wanneer de bandbreedtelimieten van de server zijn overschreden.

HTTP 510 niet uitgebreid

Deze fout betekent dat de server verdere uitbreidingen van het verzoek nodig heeft om aan het verzoek te voldoen.

HTTP 511-netwerkverificatie vereist

De 511-fout wordt geretourneerd wanneer de client zich moet verifiëren om netwerktoegang te krijgen.

Deze status is bedoeld voor gebruik bij het onderscheppen van proxy’s die worden gebruikt om de toegang tot het netwerk te controleren – dat wil zeggen “Captive Portals” die werden gebruikt om inlog- of servicevoorwaardenovereenkomst te vereisen voordat toegang tot internet werd verleend via een WiFi-portaal.

(Als je ooit hebt geprobeerd online te gaan op een luchthaven of hotel, ben je waarschijnlijk de 511-fout tegengekomen.)

HTTP 520 onbekende fout

Deze foutcode maakt geen deel uit van de HTTP-standaard, maar wordt gebruikt door verschillende grote aanbieders van serverinfrastructuur-als-een-service, zoals een CloudFlare. Het wordt gebruikt als een algemene catch-all-fout voor niet-geïdentificeerde problemen die ertoe leiden dat een verzoek niet wordt vervuld.

HTTP 598 Network Read Timeout Error (Microsoft)

Deze foutcode maakt geen deel uit van de HTTP-standaard, maar wordt gebruikt door Microsoft HTTP-proxy’s om een ​​time-out voor het lezen van het netwerk achter de proxy te signaleren aan een client vóór de proxy.

Time-outfout HTTP 599-netwerkverbinding (Microsoft)

Deze foutcode maakt geen deel uit van de HTTP-standaard, maar wordt gebruikt door Microsoft HTTP-proxy’s om een ​​time-out voor netwerkverbinding achter de proxy aan te geven aan een client vóór de proxy.

Middelen

  • IANA: de website van de Internet Assigned Numbers Authority.
  • HTTP Status Code Registry: de officiële IANA-pagina met links naar RFC’s voor elke code.

Verder lezen

We hebben meer handleidingen, tutorials en infographics met betrekking tot webontwikkeling:

  • Ik zit? Statuspagina’s voor 50 beste hostingproviders: zelfs de beste servers gaan van tijd tot tijd onderuit. Dit artikel biedt een lijst met statuspagina’s voor 50 van de beste hostingbedrijven.
  • Netwerkprogrammering met internetsockets: als u hard core-netwerken wilt leren, is dit het artikel om u op weg te helpen.
  • De ultieme lijst met webmastertools A-Z: van codering tot hosting tot marketing, dit artikel heeft het allemaal.

Ultieme gids voor webhosting

Bekijk onze Ultimate Guide to Web Hosting. Er wordt alles uitgelegd wat u moet weten om een ​​weloverwogen keuze te maken.

Ultieme gids voor webhosting
Ultieme gids voor webhosting

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map