HTTP 422 Nicht verarbeitbarer Inhalt: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Monitoringdienst oder Website-Checker erhält eine HTTP 422 Unprocessable Content-Antwort.
• Der Server gibt eine HTTP-Antwort zurück. Die Anfrage hat also einen HTTP-fähigen Endpunkt erreicht; DNS-Auflösung und TLS-Aushandlung können dennoch normal funktionieren.
• Der Fehler betrifft eine bestimmte URL, HTTP-Methode, Formulareinsendung, API-Nutzlast oder Benutzeraktion und nicht die gesamte Website.
• Die Antwort kann einen Fehler-Body enthalten, der ein ungültiges Feld, einen ungültigen Wert, einen ungültigen Zustand oder eine Validierungsregel nennt.
• Response-Header können Informationen zu Caching, Authentifizierung, Proxy, Rate-Limiting, Request-Tracking oder dem Server enthalten, die dabei helfen, die Ursache zu lokalisieren.

Hauptursachen nach Wahrscheinlichkeit

Die wahrscheinlichsten Ursachen sind:

1. Fehler bei der Anwendungsvalidierung. Ein Pflichtfeld kann fehlen, ein Wert außerhalb des zulässigen Bereichs liegen oder eine Kombination ansonsten gültiger Felder für den Vorgang nicht zulässig sein.
2. Die Anfrage entspricht nicht der von der Route erwarteten Methode oder Repräsentation. URL, HTTP-Methode, Content-Type, Body-Struktur oder codierte Daten entsprechen möglicherweise nicht dem, was der Endpunkt verarbeiten soll.
3. Ungültiger Ressourcenstatus oder Geschäftsregel. Die Anfrage kann syntaktisch gültig, im aktuellen Zustand jedoch nicht ausführbar sein, etwa weil der Vorgang gegen Regeln der Anwendung verstößt.
4. Eine Regel auf dem Server, Reverse Proxy, CDN oder WAF. Ein Vermittler kann die Anfrage validieren oder umwandeln und 422 zurückgeben, bevor die Anwendung sie erhält.
5. Kürzliche Änderungen an Routing oder Deployment. Ein geändertes Schema, ein anderer Serializer, eine neue Middleware-Regel oder eine Upstream-Integration kann dazu führen, dass zuvor akzeptierte Anfragen fehlschlagen.
6. Authentifizierungs- oder Autorisierungskontext. Diese können eine Rolle spielen, wenn die Anwendung einen authentifizierten Vorgang oder Anfragezustand validiert. Eine einfache 422-Antwort sollte jedoch nicht automatisch als Login- oder Berechtigungsfehler diagnostiziert werden. Prüfen Sie Antwort und Logs, um sie von 401 oder 403 zu unterscheiden.

So behebst du den Fehler

Wenn Sie die Website besuchen

1. Einmal erneut versuchen und die Anfrage prüfen. Kontrollieren Sie die URL, ausgewählte Formularwerte, hochgeladene Daten und alle Pflichtfelder. Senden Sie dieselbe Aktion nicht wiederholt ab, wenn sie einen Datensatz anlegen oder ein Limit auslösen könnte.
2. Den normalen Kontozugriff verwenden. Wenn die Aktion ein Konto erfordert, melden Sie sich über die übliche Oberfläche der Website an und versuchen Sie es erneut. Fügen Sie Passwörter, Cookies oder Tokens niemals in Supportanfragen ein.
3. Prüfen, ob der Fehler auf eine Aktion beschränkt ist. Wenn normale Seiten funktionieren, aber ein bestimmtes Formular, ein Upload oder ein Checkout-Vorgang 422 zurückgibt, notieren Sie die Aktion, den ungefähren Zeitpunkt und die sichtbare Fehlermeldung.
4. Nur einen geeigneten alternativen Client verwenden. Wenn der Websitebetreiber dies zulässt, kann ein privates Fenster oder ein anderer unterstützter Browser dabei helfen, ein lokales Formular- oder Sitzungsproblem von einer serverseitigen Antwort zu unterscheiden. Umgehen Sie keine Sicherheitskontrollen.
5. Bei anhaltendem Fehler den Websitebetreiber kontaktieren. Geben Sie die betroffene URL, den bekannten Anfragetyp, den Zeitpunkt des Fehlers und bereinigte Fehlerdetails an. Senden Sie keine Zugangsdaten, Sitzungscookies, Zahlungsdaten oder API-Geheimnisse.

Wenn Sie Entwickler oder Websitebetreiber sind

1. Die genaue Anfrage und Antwort erfassen. Notieren Sie HTTP-Methode, URL, Query-Parameter, Content-Type, relevante Body-Felder, Status, Response-Body und Response-Header. Schwärzen Sie Geheimnisse und personenbezogene Daten.
2. Bestätigen, dass 422 die endgültige Antwort ist. Prüfen Sie Weiterleitungen, gecachte Antworten oder einen Vermittler, der die Antwort der Anwendung verdecken könnte. Vergleichen Sie das Ergebnis mit einer bekannten gültigen Anfrage für dieselbe Route.
3. Die Anfrage gegen den Endpunktvertrag validieren. Prüfen Sie Pflichtfelder, Datentypen, zulässige Werte, Codierung, Content-Type, Ressourcen-IDs sowie erforderliche Reihenfolgen oder Zustände. Unterscheiden Sie semantische Validierung von fehlerhafter Syntax, die je nach Dienst einen anderen Status ergeben kann.
4. Die erzeugende Schicht ermitteln. Nutzen Sie charakteristische Response-Header, Request-IDs, Access-Logs, Anwendungslogs, Reverse-Proxy-Logs, CDN-Datensätze oder WAF-Ereignisse, um festzustellen, ob 422 von der Anwendung oder einem Vermittler stammt.
5. Eine fehlschlagende und eine erfolgreiche Anfrage vergleichen. Ändern Sie jeweils nur ein relevantes Detail, etwa Methode, Feldwert, Content-Type, Authentifizierungsstatus oder Zielressource. Halten Sie die Reproduktion so minimal wie möglich, damit die eigentliche Validierungsregel sichtbar wird.
6. Kürzliche Änderungen prüfen. Kontrollieren Sie Deployments, Routendefinitionen, Schemas, Serializer, Middleware, Authentifizierungsrichtlinien, Proxy-Regeln, Caching-Verhalten und Upstream-Integrationen rund um den ersten Fehler.
7. Die kleinste autorisierte Korrektur vornehmen. Beheben Sie den Request-Vertrag, die Validierungsregel, die Route oder die Vermittlerkonfiguration, die die vorliegenden Hinweise erklärt. Vermeiden Sie umfassende Änderungen an Berechtigungen, Sicherheit, Cache oder Proxy ohne getesteten Rollback-Plan.
8. Sicher erneut testen und angrenzendes Verhalten prüfen. Wiederholen Sie dieselbe Anfrage nach Möglichkeit in einer kontrollierten Umgebung und bestätigen Sie anschließend, dass zugehörige Methoden und Routen weiterhin die vorgesehenen Statuscodes zurückgeben. Wenn die Änderung die Produktion betrifft, befolgen Sie die Change-Management- und Freigabeverfahren des Dienstes.

Vorbeugung und Überprüfung der Lösung

• Dokumentieren Sie für jeden Endpunkt die akzeptierten Methoden, Content-Types, Pflichtfelder, zulässigen Werte und erwarteten Validierungsantworten.
• Validieren Sie Anfragedaten konsistent an der geeigneten Anwendungsschnittstelle und geben Sie einen hilfreichen, nicht sensiblen Fehler-Body zurück.
• Ergänzen Sie Tests für Pflichtfelder, ungültige Werte, Konflikte beim Ressourcenstatus und repräsentative Client-Anfragen.
• Überwachen Sie 422-Raten nach Route, Methode, Client und Deployment, damit eine Regression von normalem Validierungsverkehr unterschieden werden kann.
• Halten Sie Routing-, Schema-, Proxy-, Authentifizierungs-, CDN- und WAF-Konfigurationen in einer überprüfbaren Versionsverwaltung.
• Bewahren Sie Request-IDs und relevante Logs lange genug auf, um eine HTTP-Antwort der erzeugenden Komponente zuordnen zu können. Schwärzen Sie dabei Geheimnisse und sensible Daten.
• Testen Sie wichtige Formulare und API-Methoden nach Releases, Schemaänderungen und Aktualisierungen der Vermittlerkonfiguration.

Häufig gestellte Fragen