Sommige HTTP-fouten zijn helder. Een 404 betekent dat iets niet bestaat. Een 403 zegt dat je ergens niet bij mag. Maar een 412 status code? Die komt minder vaak voor, en roept daardoor des te meer vragen op.
Toch is het technisch gezien een logische foutmelding. Geen kapotte URL, geen syntaxfout. Gewoon: een voorwaarde die niet klopt. Of beter gezegd: een voorwaarde die jij als client stelde, maar waar de server zich niet in kan vinden.
Wat doet een 412 precies?
De 412 Precondition Failed fout ontstaat wanneer je een verzoek doet met een bepaalde voorwaarde, en die voorwaarde niet meer geldig blijkt.
Vaak gaat het om headers als If-Match of If-Unmodified-Since. Daarmee zeg je in feite: “ik wil deze update alleen uitvoeren als de versie van het bestand nog precies zo is als toen ik ‘m laatst ophaalde.”
Als die toestand inmiddels is veranderd, omdat een ander systeem of gebruiker het bestand al heeft aangepast, dan verbreekt de server de transactie. En stuurt terug: 412.
Je vroeg iets, maar met een bijsluiter. En de server zegt: dat klopt niet meer. We gaan het niet doen.
Wanneer kom je deze fout tegen?
Vrijwel altijd in API’s of applicaties waar versies of synchronisatie een rol spelen. Bijvoorbeeld:
- Een frontend die een document probeert te updaten via een PUT-verzoek, mét ETag.
- Een integratie die gebruik maakt van versiecontrole via headers.
- Een client die probeert een object te wijzigen dat intussen al aangepast is.
In zulke situaties wil je niet dat een verouderde versie zomaar iets overschrijft. En dus worden precondities gebruikt als controlemechanisme.
Je ziet een 412 status code niet snel in de browser. Maar tools als curl, Postman of je serverlogs geven ‘m duidelijk weer.
Voorbeeld met curl:
curl -X PUT https://api.site.nl/item/42 -H ‘If-Match: “v3.4.1″‘
Als die versie inmiddels v3.4.2 is geworden, dan krijg je terug:
HTTP/1.1 412 Precondition Failed
Wat betekent dat in de praktijk?
De server zegt eigenlijk: je werkt met verouderde informatie. De bron die je probeert te wijzigen is niet meer wat je denkt dat het is. Dus stoppen we het proces.
En dat is precies wat je wílt in dit soort systemen. Je wilt geen race conditions. Je wilt geen gebruikers die elkaars wijzigingen overschrijven. Je wilt controle.
Soms zie je 412’s in logs van frameworks die versiebeheer afdwingen via ETags. Ook integraties tussen verschillende systemen kunnen ze teruggeven bij ongeldige bewerkingsvoorwaarden.
Hoe los je het op?
Krijg je een 412? Dan is het slim om eerst de actuele versie van de resource opnieuw op te halen. Bekijk wat er veranderd is en beslis of je de wijziging alsnog wilt uitvoeren, maar dan op basis van de laatste staat.
In REST API’s doe je dat vaak door eerst een GET te doen, de nieuwe ETag op te halen, en daarna een nieuwe PUT of PATCH met een correcte If-Match.
Soms is het slimmer om zonder voorwaarde te updaten, maar dat hangt af van de context. Bij concurrentie op één resource kan dat tot dataverlies leiden, en daar is de 412 nou juist voor bedoeld.
Tot slot
De 412 status code is technisch, maar niet onlogisch. Hij is er om je te beschermen tegen foutieve updates, niet om je te dwarsbomen.
Je krijgt ‘m alleen als je zelf een voorwaarde hebt gesteld, en die niet meer klopt. En dat is goed. Want je wil niet blind iets overschrijven waarvan je dacht dat het nog hetzelfde was.
Werk je met veel integraties, webshops of content-API’s? Dan is het slim om te investeren in betrouwbare WordPress Hosting, schaalbare Cloud Hosting of gespecialiseerde WooCommerce Hosting om dit soort afhankelijkheidsfouten te voorkomen.
